Kubernetes架构深入浅出，组件及工作方式详解。

目录

一，kubernetes简介及架构

1，k8s物理架构

2，k8s逻辑架构

二，Kubernetes组件

1，Master node

2，Work node

 三，kubernetes服务部署及实现流程

---

一，kubernetes简介及架构

kubernetes的Logo是一个舵手，意为管理，就是去管理docker，Pod等等，由Goolge公司基于Go语言开发，前身是Borg，是可移植，可扩展，且开源的容器管理里平台简称k8s（因为k和s之间有8个字母），可以实现应用的创建，更新，回滚，扩容，肉茸，实现故障自动恢复

可移植：通过配置管理中心，实现环境的移植

可扩展：可以根据流量的访问情况去实现应用的一个自动扩缩容

开源：源代码公开，免费使用，二次开发

可以实现对容器的自动化部署，自动扩缩容，跨主机管理，且自动收集日志信息，通过日志信息实现容器出现故障的自恢复。

1，k8s物理架构

一个master节点和多个工作节点，

管理节点Mastre node节点就是控制节点，顾名思义就是实现整个集群的管理和控制，用于暴露API，调度部署，对工作节点的管理，可以是一个master节点或多个高可用的master节点，可通过apiserver做高可用，可以用keepalived或者Nginx去实现高可用的部署，同时master节点也可以运行Pod服务，但为了保持服务的稳定性，通常Pod服务在工作节点运行。

工作节点Work node节点就是Pod服务实际运行的节点，一个k8s集群中一般有多个工作节点以实现对外提供服务的稳定性。

2，k8s逻辑架构

k8s的最小资源调度单元是Pod，而Pod中封装的就是容器，在K8s和容器都没有出现的时代，服务的提供会有局限性，服务器的资源得不到充分的利用，而且管理极其不方便，后来有了容器的出现，把服务部署在容器当中不仅方便了服务的管理，而且提高了服务器的资源利用率，再后来有了k8s的出现使容器服务的管理更上一层楼，直入云霄，实现了跨主机的容器管理，管理更自动化，更方便统一，便于维护。

下面是多管理节点架构草图：

二，Kubernetes组件

1，Master node

Kubectl

管理K8s对象的一种命令行工具，通过Kubectl可以实现对K8s资源对象的增删改查，K8s中的所有对象，如Pod，Deployment，Rs，DeamoSet，Job，Service……都是通过kubectl来实现管理的，所以这个组件极其重要。kubectl是通过调用一个config文件去加载k8s中的对应资源从而实现对k8s中资源对象的管理。

apiserver

提供K8s的一个api，是整个系统的数据中心，会和每一个组件交互，实现对资源的认证授权，如，哪些用户可以访问这个k8s集群并且有哪些权限。并可把资源对象的信息传到Etcd中。客户端通过apiserver提供的入口来访问k8s中的资源，可以说，如果没有apiserver，那么你在k8s中部署的所有资源都将无法被外部访问到，

Etcd

key-value键值对的一种数据库，主要存储资源对象的一些状态描述信息网络信息，通过apiserver传入。

scheduler

调度器，在k8s中Pod是最小调度单元，Pod要调度到工作节点中，k8s可有多个工作节点，通过scheduler来控制Pod具体被调度到哪台工作节点，如果scheduler出现故障，Pod将无法被创建成功，scheduler通过和apiserver交互去监听资源对象的信息从而实现按照资源对象的要求（也就是创建者的要求）去实现该Pod将被调用到哪台工作节点上，最终Pod中封装的服务将以容器的方式运行在最佳的工作节点上。

controller-manager

集群内部控制管理中心，k8s的控制器，管理器。管理namespace，endpoints，资源配额，并维护各个组件的正常工作，维护Pod的副本数量始终处于预期的数量，也是通过apiserver获取资源对象的信息，并通过这些信息始终维持用户所预期的状态。

2，Work node

Kubelet

每个工作节点的kubelet和apiserver去交互并报告自身的状态信息，通过apiserver把资源调度的信息更新到Etcd，通过kubelet去启动Pod

Kubeproxy

提供网络代理和负载均衡，实现service通信，通过生成的防火墙规则是流量转发到生成的ip+端口号所对应的Pod上。

coredns

k8s中提供dns服务的组件，通过域名的形式去访问Pod，实现了k8s中的域名解析。

clico

网络插件，还有flanner，每个Pod都会被分配一个唯一的IP，clico就是分配IP的，还提供网络策列，控制访问。

containerd

容器运行时，pod中的服务说到底还是容器的运行，现在用的还是docker，所有还不必考虑这个。

下面是节点组件调用原理草图：

 三，kubernetes服务部署及实现流程

创建者先创建一个容器，容器中提供服务，封装到Pod中使用控制器统一管理运行在节点主机中，多个节点主机通过一个或多个管理节点实现跨主机的，更为方便统一的管理资源，而服务的一切要求都是通过以恶个yaml资源清单文件，其中包含了创建者期望的状态，当服务出现问题时，将自动恢复，同时还可访问流量的突变实现服务的扩容和缩容。