了解Kubernetes部署功能

时间：2022-01-23 09:13:46

原文http://qinghua.github.io/kubernetes-deployment/?utm_source=tuicool&utm_medium=referral


Kubernetes简称k8s，是谷歌于2014年开始主导的开源项目，提供了以容器为中心的部署、伸缩和运维平台。

截止目前它的最新版本为1.2。搭建环境之前建议先了解一下kubernetes的相关知识，可以参考《如果有10000台机器，你想怎么玩？》系列文章。本文介绍kubernetes的基本部署功能。

部署1.3.1参考:

http://blog.csdn.net/s1234567_89/article/details/53740632


部署Deplayment

启动一个容器最简单的方法应该就是使用以下命令了：

kubectl run my-nginx --image=nginx --replicas=2 --port=80
replicationcontroller "my-nginx" created

Deployment是kubernetes 1.2的一个新引入的概念，它包含着对Pod和将要代替Replication Controller的Replica Set的描述。

使用以下命令可以看到目前集群里的信息：

master 
1
2
3
4
5
6
 
kubectl get po                          # 查看目前所有的pod
kubectl get rs                          # 查看目前所有的replica set
kubectl get deployment                  # 查看目前所有的deployment
kubectl describe po my-nginx            # 查看my-nginx pod的详细状态
kubectl describe rs my-nginx            # 查看my-nginx replica set的详细状态
kubectl describe deployment my-nginx    # 查看my-nginx deployment的详细状态

了解Kubernetes部署功能

describe可以查看到那台虚拟机在哪个node上，并有一些详细的事件描述

了解Kubernetes部署功能

了解Kubernetes部署功能

删除deployment，

[root@master ~]# kubectl delete deployment my-centos7 
deployment "my-centos7" deleted
[root@master ~]# kubectl get pods
NAME                        READY     STATUS    RESTARTS   AGE
my-nginx-2494149703-5bego   1/1       Running   0          1h
my-nginx-2494149703-vulls   1/1       Running   0          1h

修改deployment

kubectl edit deployment/my-nginx

把nginx:1.7.9修改为nginx:1.9.11，保存退出。Kubernetes就会自动帮我们升级镜像。通过kubectl get deployment nginx的Events里可以看到升级的事件。不管是哪一种方法，升级的过程都是这样的：

  • 启动一个新容器
  • 停止两个旧容器
  • 启动一个新容器
    启动一个新的容器，然后停止一个旧的，重复这个过程直到旧的容器全部停止为止。这样可以保证

第二种是修改yaml文件，然后apply：

master 
1
2
 
sed -i "s/nginx:1.7.9/nginx:1.91/g" nginx.yaml
kubectl apply -f nginx.yaml

细心的你可能已经发现我在上面的命令里把nginx:1.9.1打成nginx:1.91了。如果此时用kubectl describe po nginx命令，就能看到Error syncing pod, skipping: failed to “StartContainer” for “nginx” with ErrImagePull: “Tag 1.91 not found in repository docker.io/library/nginx”的错误。现在我需要停止这次升级。我们可以用这条命令来查看升级历史：

master 
1
 
kubectl rollout history deployment/nginx-deployment

由于kubectl create的时候用了--record的标志，我们能够直接看到命令，方便定位到上一次正确的升级2 kubectl -s 192.168.33.17:8080 edit deployment/nginx-deployment，查看详细的deployment内容：

master 
1
 
kubectl rollout history deployment/nginx-deployment --revision=2

有两种方法可以回退到这个版本：

master 
1
2
 
kubectl rollout undo deployment/nginx-deployment
kubectl rollout undo deployment/nginx-deployment --to-revision=2

服务

前面创建了nginx的部署对象，那么别人如何使用nginx这个服务呢？首先要确定的是，这个nginx服务，是给内部使用的，还是外部。如果是内部使用，那就可以不用设置服务的类型（默认为ClusterIP），否则，可以将服务类型设置为NodePort，通过node的端口暴露出来给外部使用；或者是LoadBalancer，由云服务商提供一个负载均衡直接挂在服务上。这里我们使用NodePort，暴露出30088端口给外部使用。如果不指定nodePort，那么kubernetes会随机生成一个。下面让我们来启动服务：

cat << EOF >nginx-svc.yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  type: NodePort
  selector:
    app: nginx
  ports:
  - port: 80
    targetPort: 80
    nodePort: 30088
EOF

kubectl create -f nginx-svc.yaml


[root@node ~]# docker inspect k8s_my-nginx.a65fe6c_my-nginx-2494149703-vulls_default_80767066-c737-11e6-8f27-000c29f6c564_b38cdc1c |grep 30088
[root@node ~]# netstat -tulnp|grep 30088
tcp6       0      0 :::30088                :::*                    LISTEN      1503/kube-proxy  

这个端口映射不是docker原生的，而是kube-proxy做的。

一次性任务（job）

Kubernetes 1.1版时将Job还是Beta版，1.2之后已经可用于生产环境。Job是包含着若干pod的一次性任务。它与Replication Controller和Replica Set最大的区别就是当容器正常停止后，不会再次重启以维持一定数量的pod提供服务。下面我们用busybox运行一个耗时30s的任务：

master 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
cat << EOF >busybox.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: busybox
spec:
  template:
    metadata:
      name: busybox
    spec:
      containers:
      - name: busybox
        image: busybox:1.24.1
        command:
          - sleep
          - "30"
      restartPolicy: Never
EOF

kubectl create -f busybox.yaml

可以使用以下命令来取得目前的job：

master 
1
 
kubectl get jobs

可以看到，30s之后，SUCCESSFUL从0变为1了，说明这个job已经顺利完成了。可以使用以下命令来查看所有的pod，包含在busybox的job里正常结束的pod：

master 
1
 
kubectl get pods --show-all

Job完成之后仍然会在那里。如果需要删除，运行以下两条命令之一：

master 
1
2
 
kubectl delete job busybox
kubectl delete -f busybox.yaml

相关的pod也会一并被删除。不过容器仍然会留在运行过这个pod的node上。这可以通过设置kubelet的--maximum-dead-containers和--maximum-dead-containers-per-container参数来解决。

Daemon Sets

有时候需要每个node上都运行一个pod，比如监控或是日志收集等。这时候使用Daemon Sets就非常方便。我们用一个tomcat容器来做例子：

master 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
cat << EOF >tomcat.yaml
apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: tomcat-ds
spec:
  template:
    metadata:
      labels:
        app: tomcat
    spec:
      containers:
      - name: tomcat
        image: tomcat:8.0.30-jre8
        ports:
        - containerPort: 8080
EOF

kubectl create -f tomcat.yaml

运行完毕后，通过以下命令来取得运行结果：

master 
1
2
 
kubectl get ds
kubectl get pods

这个yaml文件和一开始的deployment的yaml文件格式很像，虽然我们没有指定replicas，但还是起了两个pod（因为我们有两个node）。可以ssh到这两个node上看看是不是每一个node上都启动了一个tomcat容器。




标签：

相关文章