了解Kubernetes部署功能

原文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的详细状态

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

删除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容器。