【无废话】K8s(kubernetes)应知应会
简介
单机的 Docker 引擎和单一的容器镜像只能解决单一服务的打包和测试问题。而要运行生产级的企业级应用，就需要容器调度管理系统。Kubernetes作为容器调度管理可以做到：
- 自动部署容器，并按照规定完成容器的复制
- 保障容器的服务能力，若某一节点出现问题，则用新的节点取代之
- 在服务运行过程中实现扩、缩容
- 通过服务的概念组织容器并提供负载均衡额服务
- 可以快速发布新的服务版本
Kubernetes集群架构
一个典型的Kubernetes集群架构如下图所示：
-
Pods
Pods是Kubernetes最小的调度单元。一个Pod可以有多个Container，这些容器共享网络，相互之间可以通过localhost来发现和通信。Pod的设计理念是支持多个容器在一个Pod中共享网络地址和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。另外，Pod是一个短暂存在的，这表现在：当Pod重启后，IP可能会改变（通过Service解决），且数据可能会消失（通过Volume解决）。 -
Labels
Label是一个附在Pod上的key/value的键值对(一个Pod上可以有多个label)，用户通过label定义了Pod的属性。Label作为pod的筛选器，service或replication controller通过通过label过滤到对应的Pods。
- Replication Controllers
Replication Controllers确保Pod根据所设定Pod的数量，保障Pod正常运行。例如：当设定了pod的replica数据为3时，RC会自动创建3个Pod并监控Pod的状态 。若其中一个Pod异常，则RC将创建新的Pod取代异常的Pod，以保障有3个正常的Pod在提供服务。如果异常的Pod恢复正常，则Pod的总数量为4，这时RC将终止其中一个Pod。另外，Replica Set，RS是新一代 RC，提供同样的高可用能力，区别主要在于 RS 后来居上，能支持更多中的匹配模式。副本集对象一般不单独使用，而是作为部署的理想状态参数使用。部署是一个比RS应用模式更广的API对象，可以是创建一个新的服务，更新一个新的服务，也可以是滚动升级一个服务。滚动升级一个服务，实际是创建一个新的RS，然后逐渐将新RS中副本数增加到理想状态，将旧RS中的副本数减小到0的复合操作；这样一个复合操作用一个RS是不太好描述的，所以用一个更通用的Deployment来描述。
-
Service
要稳定地提供服务需要服务发现和负载均衡能力。服务发现完成的工作，是针对客户端访问的服务，找到对应的的后端服务实例。在Kubernetes集群中，客户端需要访问的服务就是Service对象。Service是一个抽象的概念，定义了Pod的逻辑集合和访问这个Pod集合的策略。Service将代理Pod对外表现为一个访问接口，外部访问这接口就可以了，不需要了解后端Pod如何运行。由于Pod的运行状态可动态变化(比如切换机器了、缩容过程中被终止了等)，所以访问端不能以写死IP的方式去访问该pod提供的服务。Service的引入旨在保证pod的动态变化对访问端透明，访问端只需要知道service的地址，由service来提供代理。每个 Service 会对应一个集群内部有效的虚拟IP，集群内部通过虚拟IP访问一个服务。在Kubernetes集群中微服务的负载均衡是由Kube-proxy实现的。Kube-proxy是Kubernetes集群内部的负载均衡器。 -
Nodes
Nodes是Kubernetes的工作节点，nodes可以是物理/虚拟机。每个Node上有以下服务：- Kubelet: 负责管控容器。Kubelet从API Server接收Pod的创建请求，启动和停止容器，监控容器原型状态并汇报给API Server
- kube-proxy: 负责为Pod创建代理服务。Proxy从API Server获取Service并根据Service创建代理服务，实现Service到Pod的请求路由和转发从而实现Kubernetes层级的虚拟转发网络
- Kubernetes Master
Kubernetes集群有一个Master服务作为整个集群的调度、控制节点。Master有以下服务：- API Server: 用于暴露 Kubernetes API，以RESTful API接口方式提供给外部客户和内部组件调用。并将REST对象将持久化到etcd
- Scheduler: 负责集群的调度资源，为新建的Pod分配机器
- Controller Manager: 负责执行各种控制器
容器设计模式
容器的设计模式主要分为三大类：单容器管理模式、单节点多容器模式、多节点多容器模式。这里主要讨论单节点多容器的集中模式。
-
挎斗模式（Sidecar pattern）
第一种单节点多容器模式是挎斗模式。这种模式主要是利用在同一Pod中的容器可以共享存储空间的能力。一个典型的挎斗应用场景：一个工具容器写文件到共享的文件目录，应用主容器从共享的文件目录读文件。例如，我们可以用 Nginx构建一个代码发布仓库，简单的将代码放到某个本地目录即可。为了保持同步，我们同时用一个装有 it客户端的容器定时到原始代码仓库同步下拉最新的代码。这种模式的好处是，工具容器的镜像，也就是打包有Git客户端的镜像可以重用，而不需要跟应用的容器打包在一起。同样的应用，应用主容器不用Nginx也可以用Apache Httpd，都可以跟工具容器组合起来形成微服务。 -
外交官模式 (Ambassador pattern)
第二种单节点多容器模式是外交官模式。这种模式主要利用同一Pod中的容器可以共享网络地址空间的特性。在一个Pod中给应用容器搭配一个工具容器作为代理服务器。工具容器帮助应用容器访问外部服务，使得应用容器访问服务时不需要使用外网的IP地址，而只需要用localhost访问本地服务。在这种模式下，作为代理服务器的工具容器好像外部服务派驻在Pod中的“外交官”，使得应用容器办理业务时只需要跟本 Pod 的外交官打交道，而不需要出国了，因此而得名。 -
适配器模式（Adapter pattern）
第三种单节点多容器模式是适配器模式。这种模式对于监控和管理分布式系统尤为重要。对分布式系统的一种理想设计目标，就是能够实现“分布地执行和存储，统一的监控和管理”。要想实现“统一的监控和管理”，应用和监控管理交互的接口需要是统一的，而且其接口是依照“统一的监控服务”的接口模式来实现。这和面向对象设计模式中的“适配器模式”也非常相似。
参考文献
- Kubernetes Official - https://kubernetes.io/docs/home/
- Learn the Kubernetes Key Concepts in 10 Minutes - http://omerio.com/2015/12/18/learn-the-kubernetes-key-concepts-in-10-minutes/
pstrike 2019.02.01 于深圳
【尊重版权：转载之前请先联系我】
