1. k8s和linux类比

k8s可以理解为容器的操作系统，就像linux操作系统一样。

1.1 内核

linux操作系统内核分为进程管理子系统、内存管理子系统、文件子系统、设备子系统、网络子系统，这些模块通过统一的API，也就是系统调用，对上提供服务。

k8s就是一个数据中心的操作系统，主要管理数据中心的四种硬件资源：CPU、内存、存储、网络。

CPU和内存

对于CPU和内存，这两种计算资源的管理，可以通过docker完成。docker将cpu和内存，通过namespace和cgroup，从大的资源池里隔离出来，并通过镜像技术，实现计算资源在数据中心的拷贝。

linux操作系统上多个进程之间，需要通过文件系统保存持久化数据，并实现共享。

存储

同样，作用于数据中心的k8s也有类似文件系统的基础设施，分为对象存储、分布式文件系统和分布式块存储。

网络
k8s有自己的网络模型：

1. 每个pod有一个独立的ip地址，pod内所有容器共享网络命名空间。
2. 集群内所有pod都可以通过ip直接访问。
   实现这样的网络模型，k8s提供了Calico/Flannel，也可以使用openvswitch或linux bridge。
   linux操作系统一样，提供了一个统一的网络接口，各个网卡厂商可以依照linux操作系统提供的接口编写驱动。
   同样k8s也提供了一个统一的接口，叫做Container Network Interface（CNI），不同的网络模型，只要对接CNI，就可以被k8s管理使用。

1.2 用户态

k8s作为数据中心的操作系统，在工作模式上，也类似与linux操作系统的用户态常用机制。

进程
linux的交互式命令行，在k8s中对应的概念叫做job，job负责处理一次性任务。
linux的后台进程，在k8s对应depoloyment，deployment负责长期运行。
linux的系统服务，在k8s中对应daemonset，daemonset负责部署一些日志、监控类应用。
linux的周期性进程，在k8s中对应cronjob，类似linux中的crontab，负责在指定的时间周期内，运行指定的任务。

存储
类似linux的文件，是对存储设备的抽象。k8s有volume的概念。

网络
类似于域名，k8s有service的概念，每个serviceYou一个名字，k8s会将service名字解析成ip，通过负载均衡转发到pod。
虽然pod的ip会变，但是service名字不变。
还有，对应于linux的iptables，k8s也有一个概念叫做network policy，提供了基于策略的网络控制。

2. k8s术语

2.1 Service

在k8s中，service是分布式集群架构的核心。
一个Service对象的特征包括：

• 唯一指定的名称（比如Mysql-server)
• 一个虚拟IP和端口号，被映射到一组容器应用上（一旦创建不会改变）

一个Service通常由多个相关的服务进程提供服务，每个服务进程都有一个独立的Endpoint(IP+Port)。
k8s通过service(虚拟IP+port)连接到指定的服务，并内建负载均衡和故障服务机制，不管有多少服务进程，都不影响对服务的正常调用。

2.2 Pod

容器提供了强大的隔离功能，所以有必要把一个Service下的多个服务进程，放到容器中进行隔离。
k8s设计Pod对象，将关系紧密的服务进程包装一个Pod中，一个服务进程成为在Pod中运行的一个容器（Container）。
为了建立service和pod之间的联系，k8s给每个pod贴上一个标签（Label)，给相应的service定义标签选择器（Label selector)。
需要注意的是，并不是每个pod和它运行的容器都能被映射到一个service上，只有提供服务的pod才会被映射。

2.3 Node

k8s将一个集群的机器划分为一个Master和一些工作节点（Node）。

Master上运行集群管理相关的一组进程，包括：kube-apiserver, kube-controller-manager和kube-scheduler。
这些进程实现整个集群的资源管理、pod调度、安全控制、系统监控和纠错等管理功能，并且都是自动完成的。

Node作为集群的工作节点，Node可以是一个物理机，也可以是一个虚拟机，通常一个Node上运行几百个pod。
在Node上运行着k8s的kubelet,kube-proxy服务进程，这些服务进程负责pod的创建、启动、监控、重启、销毁和负载均衡。

2.4 RC(Replication Controller)

在K8S集群中，只需要为Service关联的pod创建一个RC，就可以实现Service的扩容和升级。
一个RC包括：

• 目标Pod的定义
• 目标Pod需要运行的副本数（Replicas)
• 要监控的目标Pod的标签

k8s会通过RC中的Label，筛选出对应的Pod示例，并实时监控pod的状态和数量，如果数量少了，会根据RC中的pod模板创建一个新的pod，并将此pod调度到合适的Node上启动运行。
整个过程是完全自动化的。

2.5 在K8s中运行一个容器应用

• (1) 开发者开发一个应用后，打包Docker镜像，上传到Docker registry；然后编写一个yaml部署描述文件，以描述应用的结构和资源需求。开发者通过kubectl（或其它应用），将部署描述文件提交到API server，API server将部署需求更新到etcd。etcd在K8s管理结点中的作用相当于数据库，其它组件提交到API server的数据都存储于etcd。
• (2) API server非常轻量，并不会直接去创建或管理Pod等资源，在多数场景下甚至不会去主动调用其它的K8s组件发出指令。其它组件通过建立和API server的长连接，监视关心的对象，监视到变化后，执行所负责的操作。
• (3-5) Controller Manager中的控制器监视到新的部署描述后，根据部署描述，创建ReplicaSet、Pod等资源。
• (6-7) Scheduler监视到新的Pod资源后，结合集群的资源情况，选定一或多个工作结点运行Pod。
• (8-10) 工作结点上的Kubelet监视到有Pod被计划在自己的结点后，向Docker等Container runtime发出启动容器的指令，Docker engineer将按照指令从Docker registy拉取镜像，然后启动并运行容器。

参考：
https://www.kubernetes.org.cn/k8s

https://time.geekbang.org/column/article/117149