目录
②kube-controller-manager（负责维护集群的状态）
⑥Cloud-controller-manager（云控制器管理器）
②Kube-proxy（负责提供集群内部的服务发现和负载均衡）
一、Kubernetes（K8s）概述
1、K8s是什么？
kubernetes是一个可移植，可扩展的开源平台，用于管理容器化工作负载和服务，有助于声明式配置和自动化。它拥有庞大且快速发展的生态系统。kubernetes服务，支持和工具随处可见。
作用：用于自动部署，扩展和管理"容器化应用程序"的开源系统。
可以理解成k8s是负责自动化运维管理多个容器化程序（比如docker）的集群，是一个生态及其丰富的容器编排框架工具。
由来：k8s由google的Borg系统(博格系统，google内部使用的大规模容器编排工具)作为原型，后经GO语言延用Borg的思路重写并捐献给CNCF基金会开源。
含义：来源于希腊语中的舵手，飞行员
官网：Kubernetes
GitHub：GitHub - kubernetes/kubernetes: Production-Grade Container Scheduling and Management
2、k8s的作用
传统的后端部署是把程序包放到服务器上，接着运行启动脚本把程序跑起来，同时启动守护脚本定期检查程序运行状态，必要的话重新拉起程序。
①案例：如果服务器的请求量上来了，已经部署的服务响应不过来怎么办？
传统的做法是，如果请求量，内存，cpu超过了阈值做了警告，运维人员就会马上增加服务器，部署好服务之后接入负载均衡来分担已有服务的压力。
这样做的弊端就是，需要人力的介入，而k8s要做的事情就是：自动化运维管理容器化的程序。
②k8s的目的就是让部署容器化应用简单高效。
k8s解决了裸跑docker的若干痛点：
单机使用，无法有效集群
随着容器数量的上升，管理成本攀升
没有有效的容灾，自愈的机制
没有预设编排模板，无法实现快速，大规模容器的调度
没有统一的配置管理中心工具
没有容器生命周期的管理工具
没有图形化运维管理工具
3、k8s的功能
k8s是google开源的容器集群管理系统，在docker等容器技术的基础上，为容器化的应用提供部署运行资源调度，服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。其主要功能如下。
①使用docker等容器技术对应用程序包装（package），实例化（instantiate），运行（run）。
②以集群的方式运行，管理跨机器的容器。
③解决docker跨机器容器之间的通讯问题
④k8s的自我修复机制使得容器集群总是运行在用户期望的状态。
二、k8s的特性
①弹性伸缩：
使用命令，UI或者基于cpu使用情况自动快速扩容和缩容应用程序实例，保证应用业务高峰并发时的高可用性；业务低峰时回收资源，以最小成本运行服务。
②自我修复：
在节点故障时重新启动失败的容器，替换和重新部署，保证预期的副本数量；杀死健康检查失败的容器，并且在未准备好之前都不会处理客户端请求，确保线上服务不中断。
③服务发现和负载均衡：
k8s为多个容器提供一个统一访问入口（内部ip地址和一个dns名称），并且负载均衡关联的所有容器，使得用户无需考虑容器的ip问题。
④自动发布（默认滚动发布模式）和回滚：
k8s采用滚动策略更新应用，一个更新一个pod，而不是同时删除所有的pod，如果更新过程中出现问题，将回滚更改，确保升级不受业务影响。
⑤集中化配置管理和密钥管理：
管理机密数据和应用程序配置，而不是需要把敏感数据暴露在镜像里，提高敏感数据的安全性，并可以将一些常用的配置存储在k8s中，方便应用程序使用。
⑥存储编排：
支持外挂存储并对外挂存储资源进行编排，挂载外部存储系统，无论是来自本地存储，共有云（如：AWS），还是网络存储（如：NFS,Glusters，Ceph）都作为集群资源的一部分使用，极大提高存储使用灵活性。
⑦任务批量处理运行：
提供一次性任务，定时任务，满足批量数据处理和分析的场景。
三、kubernetes的集群架构与组件
1、k8s架构
k8s是属于主从设备模型（Master-Slave架构），即有Master节点负载集群的调度，管理和运维，Slave节点是集群中的运算工作负载节点。
在k8s中主节点一般被称为Master节点，而从节点则被称为worker node节点，每个node都会被master分配一些工作负载。
master组件可以在集群中的任何计算机上运行，但建议master节点占据一个独立的服务器。因为master是整个集群的大脑，如果master所在节点宕机或不可用，那么所有的控制命令都将失效。除了master，在k8s集群中的其他机器被称为work node节点，当某个node宕机时，它的工作负载都会被master自动转移到其他节点上去。
四、k8s的核心组件
1、master组件：
master：集群的控制平面，负责集群的决策（管理）
①kube-apiserver（资源操作的唯一入口）
用于暴露kubernetes api，任何资源请求或调用操作都是通过kube-apiserver提供的接口进行。以http restful api提供接口服务，所有对象资源的增删改查和监听操作都交给api server 处理后再提交给Etcd进行存储。（相当于分布式数据库，以键值对方式存储）
可以理解成api server是k8s的请求入口服务。api server负责接收k8s所有请求（来自UI界面或者CLI命令行工具），然后根据用户的具体请求，去通知其他组件干活。可以说api server是k8s集群架构的大脑。
②kube-controller-manager（负责维护集群的状态）
运行管理控制，是k8s集群中处理常规任务的后台线程，是k8s集群里所有资源对象的自动化控制中心。
在k8s集群中一个资源对应一个控制器，而controller manager就是负责管理这些控制器的。
由一系列控制器组成，通过api server监控整个集群的状态，并确保集群处于预期的工作状态，比比如当某个node意外宕机时，controller manager会及时发现并执行自动化修复流程，确保集群始终处于预期的工作状态。
这些控制器包括：
|---------------------------------------------------|-------------------------------------------------------------------------------------------------------|
| 控制器 | 功能 |
| Node Controller（节点控制器） | 负责在节点出现故障时发现和响应 |
| Replication Conteoller（副本控制器） | 负责保证集群中的一个RC（资源对象ReplicationController）所关联的Pod副本数始终保持预设值。可以理解成确保集群中有仅有N个Pod实例，N是RC中定义的Pod副本数量。 |
| Endpoints Controller (端点控制器) | 填充端点对象(即连接Services 和Pods) ，负责监听Service 和对应的Pod 副本的变化。可以理解端点是一个服务暴露出来的访问点， 如果需要访问一个服务，则必须知道它的 endpoint |
| Service Account & Token Controllers (服务帐户和令牌控制器) | 为新的命名空间创建默认帐户和API访问令牌 |
| ResourceQuotaController(资源配额控制器) | 确保指定的资源对象在任何时候都不会超量占用系统物理资源 |
| Namespace Controller (命名空间控制器) | 管理namespace的生命周期 |
| Service Controller (服务控制器) | 属于k8s集群与外部的云平台之间的接口控制器 |
③kube-scheduler（负责集群资源调度）
是负责资源调度的进程，根据调度算法为新创建的pod选择一个合适的node节点。
可以理解成k8s所有node节点的调度器，当用户要部署服务时，scheduler会根据调度算法选择最合适的node节点来部署pod
预选策略：（predicate）
优选策略：（priorities）
API Server 接收到请求创建一批 Pod ，API Server 会让 Controller-manager 按照所预设的模板去创建 Pod，Controller-manager 会通过 API Server 去找 Scheduler 为新创建的 Pod 选择最适合的 Node 节点。比如运行这个 Pod 需要 2C4G 的资源，Scheduler 会通过预选策略过滤掉不满足策略的 Node 节点。Node 节点中还剩多少资源是通过汇报给 API Server 存储在 etcd 里，API Server 会调用一个方法找到 etcd 里所有 Node 节点的剩余资源，再对比 Pod 所需要的资源，如果某个 Node 节点的资源不足或者不满足 预选策略的条件则无法通过预选。预选阶段筛选出的节点，在优选阶段会根据优先策略为通过预选的 Node 节点进行打分排名， 选择得分最高的 Node。例如，资源越富裕、负载越小的 Node 可能具有越高的排名。
④Etcd（配置存储中心）
k8s的存储服务。etcd是分布式键值存储系统，存储了k8s的关键配置和用户配置，k8s中仅api server才具备读写权限，其他组件必须通过api server的接口才能读写数据。
v2版本：数据保存在内存中
v3版本：引入本地volume卷的持久化（可根据磁盘进行恢复），服务发现，分布式（方便扩容，缩容）
etcd是一种定时全量备份+持续增量备份的持久化方式，最后存储在磁盘中。
kubernetes 1.11版本前不支持v3
ETCD一般会作为3副本机制（奇数方式），分布在三台master上，也有的公司单独用服务器部署ETCD
master：奇数的方式部署（多节点的时候）
⑤AUTH（认证模块）
k8s内部支持使用RBAC认证的方式进行认证
Kubernetes使用了认证，鉴权，准入控制三步来保证api server的安全
认证是对客户端的认证，通俗点就是用户名密码验证，用于确认请求访问kubernetes api 用户是否为合法用户，如果认证模块认证请求不通过，服务器将以http状态码401拒绝该请求。
反之，该用户被认证为特定的username，并且该用户名可用于后续步骤以在决策中使用。认证策略有以下方式
X509客户证书（kubeconfig）
服务账号令牌（token）
静态令牌文件（设置apiserver启动参数--token-auth-file）
启动引导令牌（kubeadm token create）
OpenID Connect（OIDC）(一种OAuth2认证方式)
Webhook令牌身份认证(设置apiserver启动参数--authentication-token-webhook-config-file)
身份认证代理
匿名请求
用户伪装
⑥Cloud-controller-manager（云控制器管理器）
云控制器管理器是指嵌入特定云的控制逻辑的 控制平面组件。 云控制器管理器允许您链接集群到云提供商的应用编程接口中， 并把和该云平台交互的组件与只和您的集群交互的组件分离开。
cloud-controller-manager 仅运行特定于云平台的控制回路。 如果你在自己的环境中运行 Kubernetes，或者在本地计算机中运行学习环境， 所部署的环境中不需要云控制器管理器。
与 kube-controller-manager 类似，cloud-controller-manager 将若干逻辑上独立的 控制回路组合到同一个可执行文件中，供你以同一进程的方式运行。 你可以对其执行水平扩容（运行不止一个副本）以提升性能或者增强容错能力
下面的控制器都包含对云平台驱动的依赖：
节点控制器（Node Controller）: 用于在节点终止响应后检查云提供商以确定节点是否已被删除
路由控制器（Route Controller）: 用于在底层云基础架构中设置路由
服务控制器（Service Controller）: 用于创建、更新和删除云提供商负载均衡器
2、Node组件
①Kubelet（负责维护容器的生命周期）
Node节点的监视器，以及与master节点的通讯器。Kubelet是master节点安插在node节点上的"眼线"，它会定时向api server汇报自己的node节点上运行的服务的状态，并接受来自master节点的指示采取调整措施。
从master节点获取自己节点上pod的期望状态（比如运行什么容器，运行的副本的数量，网络或者存储如何配置等），直接跟容器引擎交互实现容器的生命周期管理，如果自己节点上的pod的状态与期望的状态不一样，则调用对应的容器平台接口（即docker的接口）达到这个状态。
管理镜像和容器的清理工作，保证节点上镜像不会沾满磁盘空间，退出的容器不会占用太多资源。
总结：就是kubernetes集群中，在每个node上都会启动一个kubelet服务进程。该进程用于处理master下发到本节点的任务，管理pod及pod中的容器。每个kubelet进程都会在api server上注册节点自身的信息，定期向master汇报节点资源的使用情况，并通过cadvisor监控容器和节点资源
②Kube-proxy（负责提供集群内部的服务发现和负载均衡）
在每个node节点上实现pod网络代理，是Kubernetes service资源的载体，负责维护网络规则和四层负载均衡工作，负责写入规则至iptables，ipvs实现服务映射访问的。
kube-proxy本身不是直接给pod提供网络，pod的网络是由kubelet提供的，kube-proxy实际上维护的是虚拟的pod集群网络
kube-apiserver通过监控kube-proxy进行对kubernetes service的更新和端点的维护
在k8s集群中微服务的负载均衡室友kube-proxy实现的。kube-proxy是k8s集群内部的负载均衡器。他是一个分布式代理服务器，在k8s的每个节点上都会运行一个kube-proxy组件。
1.kube-proxy的三种模式：
userspace代理模式
iptables代理模式
IPVS代理模式
2.ipvs和iptables的异同：
iptables与IPVS都是基于Netfilter实现的，但因为定位不同，二者有着本质的差别：iptables是为防火墙而设计的；IPVS则专门用于高性能负载均衡，并使用更高效的数据结构(Hash表)，允许几乎无限的规模扩张。
与iptables相比，IPVS拥有以下明显优势：
为大型集群提供了更好的可扩展性和性能；
支持比iptables更复杂的复制均衡算法(最小负载、最少连接、加权等)；
支持服务器健康检查和连接重试等功能；
可以动态修改ipset的集合，即使iptables的规则正在使用这个集合。
三种网络模型
node ip
pod ip
cluster ip
③docker/rocket（容器引擎）
容器引擎，运行容器，负责本机的容器创建和管理工作。现在基本上都是用的docker
3、组件总结：
Kubernetes Master是集群的主要控制单元，用于管理其工作负载并指导整个系统的通信。Kubernetes控制平面由各自的进程组成，每个组件都可以在单个主节点上运行，也可以在支持high-availability clusters的多个主节点上运行。
|-----------|----------------------------------------|
| 组件名称 | 作用 |
| etcd | 保存整个集群的状态 |
| apiserver | 提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制 |
|--------------------|--------------------------------|
| controller manager | 负责维护集群的状态，比如故障检测、自动扩展、滚动更新等 |
| scheduler | 负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上 |
|-------------------|-----------------------------------------|
| kubelet | 负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理 |
| Container runtime | 负责镜像管理以及Pod和容器的真正运行(CRI) |
| kube-proxy | 负责为Service提供cluster内部的服务发现和负载均衡 |
其他组件：
|--------------------|----------------|
| 组件名称 | 作用 |
| kube-dns | 负责为整个集群提供DNS服务 |
| Ingress Controller | 为服务提供外网入口 |
| Heapster | 提供资源监控 |
|-----------------------|----------------|
| Dashboard | 提供GUI |
| Federation | 提供跨可用区的集群 |
| Fluentd-elasticsearch | 提供集群日志采集、存储与查询 |
4、k8s的工作流程
①首先管理员操作kubectl命令向api server发送任务请求，先到auth中进行鉴权认证，然后进入到api server中，api server会将数据存储到Etcd中。
②然后api server会根据etcd中用户执行的操作调用conteoller manager对应的控制器进行操作
③controller manager会通过调用创建控制器到api server创建replication副本，apiserver将操作存储到etcd中，apiserver再调用scheduler进行算法选择为pod选择最合适的节点创建，scheduler需要通过api server在node节点上的kubelet进行预选策略和优选策略来选择最优的node节点，api server将动作保存到etcd中
④scheduler选择完节点之后通过api server的kubelet在对应的node节点上创建pod，并通知对应的node节点的docker在pod中创建容器。
⑤容器需要对外提供服务的时候，通过node节点的kube-proxy代理对外映射端口信息，kube-proxy进来之后通过service负载均衡器分发到容器上，访问容器根据label标签访问的。