K8S教程（1）K8S集群与核心组件介绍

一、什么是K8S

在容器技术诞生初期使用的编排工具主要有Docker Compose和Docker Swarm，容器编排工具主要作用是为了让容器可以在分布式环境中工作，适用于微服务架构，让各个应用以服务的形式运行在各自的容器中。Docker Compose主要面向于单机编排，而Docker Swarm是Docker官方开发的一款多机编排工具，多可以将多个Docker节点放入一个资源池中，再让compose对这个资源池进行编排形成集群管理，但是整体功能依然相对简单。

而K8S的出现对容器编排进行了一个革命，K8S全称Kubernetes，它是由谷歌基于borg开发的一款开源的容器编排工具，它主要有以下特色功能：

· 垂直扩容：新的K8S节点能很容易的进行增减

· 水平扩容：容器实例能通过副本控制器进行扩容、缩容

· 弹性伸缩：可以根据服务器资源自动扩容、缩容

· 自我修复：K8S可以对不符合预期的容器进行自动处理

· 自动部署与回滚：如果应用部署中出现问题可以自动回滚

· 服务发现和负载均衡：K8S为容器提供了负载均衡能力，合理的流量调度可以让集群更稳定

在落地K8S前需要考虑和解决的问题：

· 交付到K8S中的程序或者服务如何对外提供服务

· 容器跨宿主机的通信问题

· K8S监控和日志收集问题

· CI/CD的实现

· 如何平滑迁移服务到K8S集群

二、K8S的工作模式与常用组件

K8S集群系统采用了Master / Node架构，由一个或多个中心节点（Masters）来对多个工作节点（Node）进行择优调度，实现资源整合并提供服务。K8S并不会直接调度容器的运行，而是通过调度POD的方式来管理容器。POD是K8S的最小调度单位，可以把它理解为容器的外壳，POD把容器封装在了里面。而用户通过Service去访问这些资源，Service是K8S中一组提供相同服务的Pod的对外访问接口，有点像负载均衡的VIP。简单来说就是多个容器组成Pod，多个Pod组成Service，用户通过Service访问服务。完整的请求过程是客户端向MASTER端的API SERVER发起请求，API SERVER通过scheduler进行调度，而调度需要的数据是从ETCD数据库中获取，然后再由Node端最终响应。

1、K8S Master节点核心组件

· API Server：整个系统的对外接口，是所有服务访问统一入口

· Controller-Manager：集群大管家，控制器用来管理所有Pod的运行状态，保证它们按照预定的配置去运行，比如Pod占用的资源、运行多长时间等

· ETCD：K8S集群的所有状态信息都存储在ETCD系统中，可以把ETCD理解为K8S的数据库或者注册中心，通常ETCD需要配置高可用并支持https

· Scheduler：负责对集群内部的资源进行调度，根据一个优选策略对Pod的分部进行调度

2、K8S Node节点核心组件

· kubelet：它会与API Server保持通信，获取到Pod对象的配置信息并确保它们处于期望的状态，负责容器生命周期管理。还会定期向Master上报资源情况，并通过cAdvisor监控容器和节点的资源占用情况

· kube-proxy：按需为Service生成ipvs或iptables转发规则，实现服务映射与负载均衡

· Container Runtime：K8S底层调用的是容器，所以需要一个容器运行环境，目前主流使用的是Docker，但是也可以用其他容器来代替

3、K8S名词介绍

· Pod：K8S中的最小部署单元，可以把它当做一个独立虚拟机来理解。Pod由一个或多个容器组成，如果是多个容器的话这些容器应该是关系紧密、需要在一起工作的，比如常见的LNMP架构。把这些容器放在一个Pod中就可以一起部署、一起管理。如果需要扩容缩容，只需要增加或减少Pod。在每个Pod内部都会有一个pause容器用于对Pod中的每个容器的网络和存储资源进行共享，实现容器和容器之间的资源互访。由于单独部署Pod会缺少一些高级特性，所以通常都是使用控制器来管理Pod。

· Service：Service类似一个负载均衡器的角色，可以给提供相同服务的一个或多个Pod提供一个统一的访问入口（Service会有一个Cluster IP作为集群VIP），这样当Pod扩缩容或者节点发生变化的时候入口不会受到影响

· Lable：标签，用于区分Pod、Service等对象，每个Pod可以有多个标签，不同的标签也可以在不同的Pod上。通过标签选择器可以快速选择一个标签下的资源，即使它们没有在同一个Node

· Controller：K8S中的控制器，主要用于控制Pod数量与预期设置能达成一致，所以通常都是创建控制器来实现创建Pod的目的，控制器创建的Pod也都可以通过kubectl get pod命令查看到。控制器根据作用不同又分了好几种，比如ReplicationController、ReplicaSet和Deployment是为了解决无状态服务，当有容器异常退出或者性能不足时能自动创建新的Pod来替代。目前来说ReplicationController已经被ReplicaSet副本集所替代，而Deployment在ReplicaSet的基础上又多了新的特性，比如滚动升级，所以除非明确Pods完全不需要更新，官方也建议使用Deployment。对于有状态服务需要使用StatefulSet控制器，它支持有序部署、有序删除，能提供持久化存储等；还有一种DaemonSet可以确保全部Node上都运行某一个Pod，典型用法就是在每个node上安装日志采集、监控系统

· namespace：名称空间，可以将K8S中不同资源划分到不同的逻辑空间中去，实现环境隔离。比如生产环境和测试环境各自用自己的Namespace、不同业务线有各自的Namespace。需要注意的是并不是所有对象都有namespace，集群级别的资源没有namespace属性，比如node

4、其他组件

· flannel：网络组件，让集群中的不同宿主所创建的容器都有一个全集群唯一的IP地址，实现Pod跨主机通信

· CoreDNS：为集群中的不同Pod提供一个名称并完成解析的服务

· Ingress：通过它可以实现7层代理，而不仅仅只能在4层代理。如果需要某些Pod能提供给外部用户访问，可以通过Ingress把K8S中的服务暴露。Ingress是一组路由规则的集合，这些规则通过Ingress发挥作用，目前可用的项目有Nginx、Haproxy、Traefik等。

5、Pod在生产环境中的访问流程

Pod相当于一个有着独立IP、独立hostname、利用namespace进行资源隔离的独立沙箱环境。Pod内部封装的是一个或多个相关的容器。Pod内部容器之间可以使用localhost访问，而对外提供服务的话由于没有对应的实体（物理机、物理网卡），所以客户端的请求都是先到物理机的某个端口，然后将其请求发送给service，再由service通过iptables规则转发到对应的Pod中，具体需要转发到哪些Pod可以通过标签选择器来完成。