前言

鸽了一个多月，更文虽迟但到

近两个月的打工人时光，让人变秃了，也变鸽了(试图解释)

以及忙着忙着，就模糊了工作和个人生活的界限，不似996，胜似996，有点心累，希望接下来能好好调整

话不多说，进入正题

容器编排

容器本身没有价值，有价值的是“容器编排”

容器编排简介

容器编排，就是对容器的管理，包括：

• 应用部署：将应用装进容器，部署到某一物理节点上

• 水平扩展：可动态调整容器副本数量，业务请求压力大的时候，就可以多开几个应用副本来处理

• 服务发现：一个应用对应一种服务，当你把应用跑起来后，容器编排工具就能发现这一服务，这样其他服务就可以调用当前服务了

• 负载均衡：容器编排工具能将请求调度到一个服务的不同容器副本上，从而降低各容器的压力

• 故障自愈：物理节点宕机后，其上的容器会重新部署到另一个节点

• 滚动更新：对一个服务对应的全部应用进行批量更新

• 版本回退：可以回退应用版本

目前比较主流的容器编排工具之一就是k8s

k8s简介

k8s，全称为Kubernetes，K8s是谷歌和redhat主导开发的容器编排工具。

Kubernetes这个单词源于希腊语，译为“舵手”

下图是个形象的比喻，将k8s类比成舵手，统筹调度着船上的一个个集装箱(容器)：

K8s架构

简单来说就是：master节点管理node节点，node节点上跑着容器

用户通过UI界面或者CLI(命令行)与master节点交互

而不同节点上跑着不同的k8s组件

K8s组件

Master节点上的组件：

• API server：顾名思义，包括了k8s所有的api，是集群的统一入口。Kubernetes 中所有的组件都会和 API Server 进行连接，组件与组件之间一般不进行独立的连接，都依赖于 API Server 进行消息的传送；

• scheduler：调度器，当你用k8s跑一个应用时，它会根据应用对 CPU、memory 的请求大小，找一台合适的节点，进行放置

• etcd：存储系统，保存集群的数据。比如容器部署到了哪些节点上、容器的信息等等

• controller：控制器，可以用来控制应用的副本数量，实现了服务编排里说的故障自愈和水平伸缩的功能

Node节点上的组件：

• kubelet：用来管理Node节点，可以理解为master节点派到Node节点的代表

• kube-proxy：提供网络代理，提供负载均衡等功能

• docker：运行容器

部署应用的过程分解

• 用户可以通过 UI 或者 CLI 提交一个 Pod(简单说就是一组容器，后边会介绍) 给 Kubernetes 进行部署

• 这个 Pod 请求首先会提交给 Kubernetes API Server

• 下一步 API Server 会把这个信息写入到它的存储系统 etcd

• 之后 Scheduler 会通过 API Server 的 watch 或者叫做 notification 机制得到这个信息：有一个 Pod 需要被调度。

• 这个时候 Scheduler 会根据Pod对硬件的要进行一次调度(选出一个合适的节点)，在完成这次调度之后，它会向 API Server 反馈 说：“OK！这个 Pod 需要被调度到xx节点上。”

• 这个时候 API Server 接收到这次操作之后，会把这次的结果再次写到 etcd 中

• 然后 API Server 会通知相应的节点进行这次 Pod 真正的执行启动

• 相应节点的 kubelet 会得到这个通知

• kubelet 就会去调 Container runtime 来真正去启动配置这个容器和这个容器的运行环境，去调度 Storage Plugin 来去配置存储，network Plugin 去配置网络

Pod

Pod，是一组容器。

这一组容器装在一个叫infra的容器里(俄罗斯套娃)，共享同一个 Network Namespace，可以共享同一个Volume(可简单理解为一个文件夹)。

为什么pod要设计成为一组容器呢？其实这个概念是类比进程和进程组的关系。

上一篇文章已经说过，一个容器里边一般只跑一个进程，即应用进程；那么一个pod对应一组容器，自然也就对应一个进程组

Google 公司的工程师们发现，他们部署的应用，往往都存在着类似于“进程和进程组”的关系。更具体地说，就是这些应用之间有着密切的协作关系，使得它们必须部署在同一台机器上。

因此，Pod是 k8s项目中的最小编排单位。

Deployment和Service

在k8s中，我们对一组pod的部署对应着一个Deployment，可以用一个yaml文件来描述：

通过kubectl apply -f xxx.yaml启动deployment，从而来保证pod副本数稳定

一组pod跑起来自然是要对外提供服务的，k8s对此也做了抽象，用一个yaml文件描述Service，eg：

 apiVersion: v1kind: Servicemetadata:  name: demo #服务名  namespace: default  labels:     app: demospec:  ports:    - port: 80      targetPort: http      protocol: TCP      name: http  selector:    app: demo    version: v1  ......

这些yaml文件也被称为资源清单文件，描述的对象被称为资源，比如Deployment、Service，每个资源可以设置对应的label和selector

通过给selector去选择不同的label，来建立deployment和pod、service与deployment的映射关系

蓝绿部署

场景：

版本更新不允许两个版本代码同时运行。

方法：

启动一个新的Deployment,给这个deployment一个新的标签

配置service的selector(service原先选择老的deployment的标签，后来改成选择新deployment的标签)，将流量导向新的Deployment

之前的service.yaml：

 apiVersion: v1kind: Servicemetadata:  name: demo #服务名  namespace: default  labels:     app: demospec:  ports:    - port: 80      targetPort: http      protocol: TCP      name: http  # 当前匹配的是app=demo,version=v1的deployment,切换服务对应的deployment时，我们改变selector的version值  selector:    app: demo    version: v1

v1-deployment.yaml:

 apiVersion: apps/v1kind: Deploymentmetadata:  name: demo1-deployment  namespace: default  labels:    app: demo    version: v1 #deployment的版本:v1........

v2-deployment.yaml：

 apiVersion: apps/v1kind: Deploymentmetadata:  name: demo1-deployment  namespace: default  labels:    app: demo    version: v2 #deployment的版本:v2........

通过命令启动service和两个deployment:

 kubectl apply -f service.yaml -f v1-deployment.yaml -f v2-deployment.yaml

动态修改service的标签选择器，实现流量从v1版本应用切到v2版本应用

 kubectl patch service demo -p '{"spec":{"selector":{"version":"v2"}}}'