一 K8S 概览
1.1 K8S 是什么?
K8S官网文档:https://kubernetes.io/zh/docs/home/
K8S 是Kubernetes的全称,源于希腊语,意为“舵手”或“飞行员”,官方称其是:用于自动部署、扩展和管理“容器化(containerized)应用程序”的开源系统。翻译成大白话就是:“K8S 是负责自动化运维管理多个跨机器 Docker 程序的集群”。
1.2 K8S核心特性
- 服务发现与负载均衡:无需修改你的应用程序即可使用陌生的服务发现机制。
- 存储编排:自动挂载所选存储系统,包括本地存储。
- Secret和配置管理:部署更新Secrets和应用程序的配置时不必重新构建容器镜像,且不必将软件堆栈配置中的秘密信息暴露出来。
- 批量执行:除了服务之外,Kubernetes还可以管理你的批处理和CI工作负载,在期望时替换掉失效的容器。
- 水平扩缩:使用一个简单的命令、一个UI或基于CPU使用情况自动对应用程序进行扩缩。
- 自动化上线和回滚:Kubernetes会分步骤地将针对应用或其配置的更改上线,同时监视应用程序运行状况以确保你不会同时终止所有实例。
- 自动装箱:根据资源需求和其他约束自动放置容器,同时避免影响可用性。
- 自我修复:重新启动失败的容器,在节点死亡时替换并重新调度容器,杀死不响应用户定义的健康检查的容器。
pod里装的是docker容器,pod是k8s里部署应用的最小单位(容器是docker里部署应用的最小单位);一个node下可以部署很多pod容器
1.3 K8S集群安装
参考后边这篇文章里的第二章 k8s集群部署
二 用K8S部署Nginx
在k8s-master机器上执行
# 创建一次deployment部署,最后nginx可以加版本号,如nginx:2.0,不写版本的话就是使用最新版nginx,最终部署到了node节点了,而不是master
kubectl create deployment nginx --image=nginx
kubectl get all
可以看到,已经部署了一个nginx容器
此时外网还不能访问这个nginx,需要做对外的端口映射
#端口映射,即创建一个nginx可以对外访问的端口,生成的端口是随机的(也可以指定端口) --port是service的虚拟ip对应的端口
kubectl expose deployment nginx --port=80 --type=NodePort
再次执行kubectl get all
命令
# 查看Nginx的pod和service信息
kubectl get pod,svc -o wide
访问Nginx地址:
http://任意从节点的ip:图中Nginx的对外映射端口,http://192.168.65.203:30563
主节点ip:端口也能访问,但是需要做配置,后边会讲;
补充:
如果node节点添加进集群失败,可以删除节点重新添加
要删除 k8snode1 这个节点,首先在 master 节点上依次执行以下两个命令
kubectl drain k8s‐node1 ‐‐delete‐local‐data ‐‐force ‐‐ignore‐daemonsets kubectl delete node k8s‐node1
执行后通过 kubectl get node 命令可以看到 k8snode1 已被成功删除;
接着在 k8snode1 这个 Node 节点上执行如下命令,这样该节点即完全从 k8s 集群中脱离开来,之后就可以重新执行命令添加到集群
kubeadm reset
三 K8S 核心架构原理
我们已经知道了 K8S 的核心功能:自动化运维管理多个容器化程序。那么 K8S 怎么做到的呢?这里,我们从宏观架构上来学习 K8S 的设计思想。首先看下图:
K8S 是属于主从设备模型(Master-Slave 架构),即有 Master 节点负责核心的调度、管理和运维,Slave 节点则执行用户的程序。但是在 K8S 中,主节点一般被称为Master Node 或者 Head Node,而从节点则被称为Worker Node 或者 Node。
注意:Master Node 和 Worker Node 是分别安装了 K8S 的 Master 和 Woker 组件的实体服务器,每个 Node 都对应了一台实体服务器(虽然 Master Node 可以和其中一个 Worker Node 安装在同一台服务器,但是建议 Master Node 单独部署),所有 Master Node 和 Worker Node 组成了 K8S 集群,同一个集群可能存在多个 Master Node 和 Worker Node。
首先来看Master Node都有哪些组件:
- API Server。K8S 的请求入口服务。API Server 负责接收 K8S 所有请求(来自 UI 界面或者 CLI 命令行工具),然后,API Server 根据用户的具体请求,去通知其他组件干活。
- Scheduler。K8S 所有 Worker Node 的调度器。当用户要部署服务时,Scheduler 会选择最合适的 Worker Node(服务器)来部署。
- Controller Manager。K8S 所有 Worker Node 的监控器,解析API Server传过来的命令,解析后存储到下边的etcd库里。Controller Manager 有很多具体的 Controller, Node Controller、Service Controller、Volume Controller 等。Controller 负责监控和调整在 Worker Node 上部署的服务的状态,比如用户要求 A 服务部署 2 个副本,那么当其中一个服务挂了的时候,Controller 会马上调整,让 Scheduler 再选择一个 Worker Node 重新部署服务。
- etcd。K8S 的存储服务。etcd 存储了 K8S 的关键配置和用户配置,K8S 中仅 API Server 才具备读写权限,其他组件必须通过 API Server 的接口才能读写数据。
接着来看Worker Node的组件:
- Kubelet。Worker Node 的监视器,以及与 Master Node 的通讯器。Kubelet 是 Master Node 安插在 Worker Node 上的“眼线”(相当于node的小管家),它会定期向 Master Node 汇报自己 Node 上运行的服务的状态,并接受来自 Master Node 的指示采取调整措施。负责控制所有容器的启动停止,保证节点工作正常。Kubelet上报给msater自己资源的使用情况后,master的调度器Scheduler就能根据每台node机器的实际情况来给各个node分配任务了;
- Kube-Proxy。K8S 的网络代理。Kube-Proxy 负责 Node 在 K8S 的网络通讯、以及对外部网络流量的负载均衡。
- Container Runtime。Worker Node 的运行环境。即安装了容器化所需的软件环境确保容器化程序能够跑起来,比如 Docker Engine运行环境。
在大概理解了上面几个组件的意思后,我们来看下上面用K8S部署Nginx的过程中,K8S内部各组件是如何协同工作的:
我们在master节点执行一条命令,如master部署一个nginx应用(kubectl create deployment nginx --image=nginx:2.0.1),都经历了哪些流程
- 这条命令首先发到master节点的网关api server,这是matser的唯一入口
- api server将命令请求交给controller mannager进行控制(controller mannager解析命令)
- controller mannager 进行应用部署解析
- controller mannager 会生成一次部署信息,并通过api server将信息存入etcd存储中
- scheduler调度器通过api server从etcd存储中,拿到要部署的应用与node节点的信息,开始调度看哪个节点有资源适合部署
- scheduler把计算出来的调度信息通过api server再放到etcd中
- 每一个node节点的监控组件kubelet,随时和master保持联系(给api-server发送请求不断获取最新数据),拿到master节点存储在etcd中的部署信息
- 假设node2的kubelet拿到部署信息,显示他自己节点要部署某某应用
- kubelet就自己run一个应用在当前机器上,并随时给master汇报当前应用的状态信息
- node和master也是通过master的api-server组件联系的
- 每一个机器上的kube-proxy能知道集群的所有网络,只要node访问别人或者别人访问node,node上的kube-proxy网络代理自动计算进行流量转发
四 K8S 快速实战
4.1 kubectl命令使用
kubectl是apiserver的客户端工具,工作在命令行下,能够连接apiserver实现各种增删改查等操作
kubectl官方使用文档:https://kubernetes.io/zh/docs/reference/kubectl/overview/
K8S的各种命令帮助文档做得非常不错,遇到问题可以多查help帮助
4.2 创建一个Tomcat应用程序
使用 kubectl create deployment 命令可以创建一个应用部署deployment与Pod
#my-tomcat表示pod的名称 --image表示镜像的地址
kubectl create deployment my-tomcat --image=tomcat:7.0.75-alpine
查看一下deployment的信息
kubectl get deployment
# 或者查看所有资源
kubectl get all
# 或者查看pod资源
kubectl get pod
获取pod的信息,-o wide 表示更详细的显示信息
kubectl get pod -o wide
查看Pod打印的日志
kubectl logs my-tomcat-685b8fd9c9-rw42d(pod名称)
使用 exec 可以在Pod的容器中执行命令,这里使用 env 命令查看环境变量
kubectl exec my-tomcat-685b8fd9c9-rw42d -- env
kubectl exec my-tomcat-685b8fd9c9-rw42d -- ls / # 查看容器的根目录下面内容
进入Pod容器内部并执行bash命令,如果想退出容器可以使用exit命令
kubectl exec -it my-tomcat-685b8fd9c9-rw42d -- sh
这个ip与docker容器里的ip一样,重启服务器后是会变的,但是对我们没影响,因为这个ip是容器内部用的,我们用不到;
访问一下这个tomcat pod
集群内访问(在集群里任一node节点都可以访问)
curl 10.244.36.69:8080
集群外部访问
当我们在集群之外访问是发现无法访问,那么集群之外的客户端如何才能访问呢?这就需要我们的service服务了,下面我们就创建一个service,使外部客户端可以访问我们的pod;
4.3 创建一个service
# 最后边的--type=NodePort代表映射的外网(宿主机)端口随机,容器内部的端口是8080
kubectl expose deployment my-tomcat --name=tomcat --port=8080 --type=NodePort
#查看service信息,port信息里冒号后面的端口号就是对集群外暴露的访问接口
kubectl get svc -o wide
上边结果里的32224就是对外暴露的端口,即容器内部的8080与宿主机的32224端口对应;
集群外部访问
使用集群worker节点的ip加上暴露的端口就可以访问
service服务有个特点,如果端口暴露类型为NodePort,那么可以通过集群内所有worker主机加暴露的端口进行访问
现在我们来删除刚刚添加的pod,看看会发生什么
#查看pod信息,-w意思是一直等待观察pod信息的变动
kubectl get pod -w
开另外一个命令窗口执行如下命令,同时观察之前命令窗口的变化情况
kubectl delete pod my-tomcat-685b8fd9c9-rw42d
pending:等待中;
我们可以看到之前那个tomcat的pod被销毁,但是又重新启动了一个新的tomcat pod,这是k8s的服务自愈功能,不需要运维人员干预
查看下deployment和service的状态
再一次访问service地址,依然可以访问成功
一个service端口对应多个tomcat,这个service会自动去做负载均衡;
4.4 对my-tomcat这个deployment进行扩缩容
# 扩容到5个pod
kubectl scale --replicas=5 deployment my-tomcat
查看pod信息,发现已经有5个tomcat的pod
kubectl get pod
缩容
# 扩容到3个pod
kubectl scale --replicas=3 deployment my-tomcat
4.5 滚动升级与回滚
对my-tomcat这个deployment进行滚动升级(一台一台升级)和回滚,将tomcat版本由tomcat:7.0.75-alpine升级到tomcat:8.0.41-jre8-alpine,再回滚到tomcat:7.0.75-alpine
滚动升级:
kubectl set image deployment my-tomcat tomcat=tomcat:8.0.41-jre8-alpine
可以执行 kubectl get pod -w 观察pod的变动情况,可以看到有的pod在销毁,有的pod在创建
查看pod信息
kubectl get pod
查看某个pod的详细信息,发现pod里的镜像版本已经升级了
kubectl describe pod my-tomcat-547db86547-4btmd
访问下tomcat,看到版本也已经升级
版本回滚:
查看历史版本
kubectl rollout history deploy my-tomcat
再次访问tomcat,发现版本已经回退
4.6 标签的使用
通过给资源添加Label,可以方便地管理资源(如Deployment、Pod、Service等)。
查看Deployment中所包含的Label
kubectl describe deployment my-tomcat
通过Label查询Pod
kubectl get pods -l app=my-tomcat
通过Label查询Service
kubectl get services -l app=my-tomcat
给Pod添加Label
kubectl label pod version=v1
查看Pod的详细信息,可以查看Label信息:
kubectl describe pods my-tomcat-685b8fd9c9-lrwst
通过Label查询Pod
kubectl get pods -l version=v1
通过Label删除服务
kubectl delete service -l app=test-service
比如新启动了一些pod,想要与之前的pod是一批,那么就可以把这些pod的标签改为一样的就行;
小总结
kubectl create deployment #创建一个deployment来管理创建的容器
kubectl get #显示一个或多个资源,可以使用标签过滤,默认查看当前名称空间的资源
kubectl expose #将一个资源暴露为一个新的kubernetes的service资源,资源包括pod (po), service (svc), replicationcontroller (rc),deployment(deploy), replicaset (rs)
kubectl describe #显示特定资源或资源组的详细信息
kubectl scale #可以对Deployment, ReplicaSet, Replication Controller, 或者StatefulSet设置新的值,可以指定一个或多个先决条件
kubectl set #更改现有的应用程序资源
kubectl rollout #资源回滚管理
以上就是kubectl命令行下一些简单的操作,主要是让我们对kubernetes有一个快速的认识。