理解Kubernetes编排架构

01常见的业务场景

假设有两个服务A和B，他们之间相互调用，且同时对外提供，如下图所示

• 服务A和B之间必须互通
• 服务A和B都需要访问各种需要的基础设施，如数据库、消息队列等
• 服务A和B都对外暴露API
• 服务需要高可用，自动扩缩容

我们暂且不讨论这个架构设计是否合理，假设场景就是如此，正常线上情况往往比这个复杂的多。

»02 回顾一下Docker

这里不再对Docker的内容展开详细介绍，本文默认你已经熟悉Docker相关的知识。

»03 一步一步理解K8S

服务自身所处的环境：Container

服务存在于容器中，容器之间，互相隔离。每个容器分别需要挂载一个磁盘

为了方便管理，我们将多个容器组合在一起，同时为其配套一个相同的环境上下文，就形成了容器的逻辑主机：POD

K8S的逻辑主机：Pod

Pod是K8S的最小管理单位，一个服务的一个副本一般是一个Pod，同个Pod中的所有容器网络互通，有相同的挂载以及Pod IP等。

服务往往需要高可用，就需要扩容成多个副本，并通过负载均衡的方式，让外部流量均匀地流入到每个Pod上，此时K8S的副本管理器承担了这个职责，可以将Pod复制出来，并进行负载均衡。同时可以将Pod创建到指定的物理节点上。

副本控制器：ReplicationController

节点选择器：NodeSelector

副本集：ReplicationSet

此时，我们的服务就有了NodeIP和PodIP。

同时对于一些不同的服务，场景还可能不一样。比如对于MySQL，WebSocket等基于TCP协议长连接的服务，不适合频繁变换PodIP(因为一旦变原本客户端的连接池连接就失效了)。所以对于不同的服务，K8S支持了不同的类型。

有状态容器：StatefulSet

无状态容器：Deployment

守护进程容器：DaemonSet

到目前为止，都是将服务部署起来，都没有说如何访问这些服务。在K8S中，部署和访问是相互独立的，部署我们称之Deployment，而访问需要靠Service来定义。我们称这种由Service转发端口到Pod的方式为NodePort模式

Deployment: 定义如何创建Pod，创建多少个Pod

Service: 定义如何从外部访问服务

Deployment为Pod和ReplicaSet提供了一个声明式定义(declarative)方法，用来替代以前的ReplicationController来方便的管理应用。而Service抽象了对Pod的访问。

现在，可以通过service暴露出来的端口，从集群外部访问Pod了。一般此时外层再对接统一的API网关，绑定域名，即可进行反向代理，通过域名访问相关服务。

以上，就是将一个服务部署在K8S上的全部基本流程了。所以，是不是理解起来K8S其实也挺好理解的呢？当然，本文只是面向K8S小白，从白盒的角度理解K8S，如果从K8S的架构角度上看，实际上K8S的组件和架构比本文描述的要复杂的多。

»04 K8S架构简介

• ETCD：负责维护集群内所有服务的状态信息，也用于服务注册和发现
• ApiServer：提供了资源操作的唯一入口，同时提供鉴权等功能
• Scheduler：负责将Pod调度到某个机器节点上
• ControllerManager：负责将Pod跑起来，同时维护故障检测、滚动更新等
• Kubelet：每个Node上的守护进程，负责维护容器的生命周期
• Kube-Proxy：负责为Service提供cluster内部的服务发现和负载均衡
• kube-DNS：负责为整个集群提供DNS服务
• Ingress Controller为服务提供外网入口