整理中

大概分三部分整合笔记：

docker

k8s

k8s+docker 应用实例

docker 概念

参考文档

docker中文社区  http://www.docker.org.cn/

docker存储分享笔记 https://www.cnblogs.com/sammyliu/p/5931383.html

《docker 技术入门与实践 第二版》

Docker 镜像

Docker 镜像是一个特殊的文件系统,除了提供容器运行时所需的程序、库、资源、配置等文件外,还包含了一些为运行时准备的一些配置参数(如匿名卷、环境变量、用户等)。镜像不包含任何动态数据,其内容在构建之后也不会被改变。

Docker 容器

镜像(Image)和容器(Container)的关系,就像是面向对象程序设计中的类和实例一样,镜像是静态的定义,容器是镜像运行时的实体。容器可以被创建、启动、停止、删除、暂停等。

Docker 仓库

镜像构建完成后,可以很容易的在当前宿主上运行,但是,如果需要在其它服务器上使用这个镜像,我们就需要一个集中的存储、分发镜像的服务,Docker Registry 就是这样的服务。

架构

Docker使用客户端-服务器(client-server)架构模式。Docker客户端会与Docker守护进程进行通信。Docker守护进程会处理复杂繁重的任务，例如建立、运行、发布你的Docker容器。Docker客户端和守护进程可以运行在同一个系统上，当然你也可以使用Docker客户端去连接一个远程的Docker守护进程。Docker客户端和守护进程之间通过socket或者RESTful API进行通信。

Docker 与 VM

--参考  《docker 技术入门与实践 第二版》

传统虚拟机技术是虚拟出一套硬件后,在其上运行一个完整操作系统,在该系统上再运行所需应用进程。而容器内的应用进程直接运行于宿主的内核,而且也没有进行硬件虚拟。因此容器要比传统虚拟机更为轻便。

分层存储 和 隔离

https://www.cnblogs.com/sammyliu/p/5931383.html

http://www.docker.org.cn/article/166.html

在一个Linux 系统之中，

• 所有 Docker 容器都共享主机系统的 bootfs 即 Linux 内核
• 每个容器有自己的 rootfs，它来自不同的 Linux 发行版的基础镜像，包括 Ubuntu，Debian 和 SUSE 等
• 所有基于一种基础镜像的容器都共享这种 rootfs

镜像 和 layer （层）

1. Docker 镜像是 Docker 容器运行时的只读模板，每一个镜像由一系列的层 (layers) 组成。Docker 使用 UnionFS 来将这些层联合到单独的镜像中。UnionFS 允许独立文件系统中的文件和文件夹(称之为分支)被透明覆盖，形成一个单独连贯的文件系统。正因为有了这些层的存在，Docker 是如此的轻量。当你改变了一个 Docker 镜像，比如升级到某个程序到新的版本，一个新的层会被创建。因此，不用替换整个原先的镜像或者重新建立(在使用虚拟机的时候你可能会这么做)，只是一个新 的层被添加或升级了。现在你不用重新发布整个镜像，只需要升级，层使得分发 Docker 镜像变得简单和快速。
2. docker 内部的 image 概念是用来存储一组镜像相关的元数据信息，主要包括镜像的架构(如 amd64)、镜像默认配置信息、构建镜像的容器配置信息、包含所有镜像层信息的 rootfs。docker 利用 rootfs 中的 diff_id 计算出内容寻址的索引(chainID) 来获取 layer 相关信息，进而获取每一个镜像层的文件内容。
3. layer(镜像层) 是 docker 用来管理镜像层的一个中间概念。我们前面提到，镜像是由镜像层组成的，而单个镜像层可能被多个镜像共享，所以 docker 将 layer 与 image 的概念分离。docker 镜像管理中的 layer 主要存放了镜像层的 diff_id、size、cache-id 和 parent 等内容，实际的文件内容则是由存储驱动来管理，并可以通过 cache-id 在本地索引到。

镜像与容器

--分层
docker 镜像是采用分层的方式构建的，每个镜像都由一系列的 "镜像层" 组成。分层结构是 docker 镜像如此轻量的重要原因。当需要修改容器镜像内的某个文件时，只对处于最上方的读写层进行变动，不覆写下层已有文件系统的内容，已有文件在只读层中的原始版本仍然存在，但会被读写层中的新版本所隐藏。当使用 docker commit 提交这个修改过的容器文件系统为一个新的镜像时，保存的内容仅为最上层读写文件系统中被更新过的文件。分层达到了在不的容器同镜像之间共享镜像层的效果。

--写时复制
docker 镜像使用了写时复制(copy-on-write)的策略，在多个容器之间共享镜像，每个容器在启动的时候并不需要单独复制一份镜像文件，而是将所有镜像层以只读的方式挂载到一个挂载点，再在上面覆盖一个可读写的容器层。在未更改文件内容时，所有容器共享同一份数据，只有在 docker 容器运行过程中文件系统发生变化时，才会把变化的文件内容写到可读写层，并隐藏只读层中的老版本文件。写时复制配合分层机制减少了镜像对磁盘空间的占用和容器启动时间。

namespace

docker 镜像的获取

1 . docker 镜像的创建，提交

     Dockerfile脚本创建，通过脚本中的配置来定制全新的docker 镜像

2. docker 镜像的下载，修改，提交

     通过 docker pull 来下载一些镜像源上已有的镜像

     在窗口中安装新的软件，修改新的配置，docker commit 保存修改到本地，docker push 将自己的修改发布，推送到镜像源。

容器的状态

1. 基于镜像创建一个新的容器，docker run -t -i  $images_name /bin/bash

2. 重新启动一个已经停止的容器，docker start

3. 停止一个容器 docker stop

4. 查看 容器 docker ps （默认只show 运行中的，全部加-a）

Docker的常用命令  CLI

https://docs.docker.com/engine/reference/builder/

K8S

Kubernetes

https://kubernetes.io/

Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available.

The name Kubernetes originates from Greek, meaning helmsman or pilot. Google open-sourced the Kubernetes project in 2014. Kubernetes builds upon a decade and a half of experience that Google has with running production workloads at scale, combined with best-of-breed ideas and practices from the community.

   Kubernetes是一个可移植的、可扩展的、用于管理容器化工作负载和服务的开源平台，使声明性的配置与自动化更容易。它有一个庞大的、快速增长的生态系统。Kubernetes的服务、支持和工具随处可见。
Kubernetes一词源于希腊语，意为舵手或飞行员。2014年，谷歌开放了Kubernetes项目的源代码。Kubernetes基于谷歌在大规模运行生产工作负载方面的15年经验，以及来自社区的最佳想法和实践。

回顾部署方式的发展

Traditional deployment era
Virtualized deployment era
Container deployment era

从传统部署到虚拟化部署到容器化部署，以下是来自官网的图示：

https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/

  容器类似于vm，但是它们具有宽松的隔离属性，以便在应用程序之间共享操作系统(OS)。因此，容器被认为是轻量级的。与VM类似，容器有自己的文件系统、CPU、内存、进程空间等等。由于它们与底层基础设施解耦，因此可以跨云和OS发行版进行移植。

容器已经变得流行起来，因为它们提供了额外的好处，比如:

1. 敏捷应用程序的创建和部署:与使用VM镜像相比，容器镜像的创建更加容易和高效。

2. 持续开发、集成和部署:提供可靠且频繁的容器镜像构建和部署，具有快速且轻松的回滚(由于映像不可变性)。

3. 开发和操作关注点分离:在构建/发布时而不是部署时创建应用程序容器镜像，从而将应用程序与基础设施分离。

4. 可观察性不仅能显示操作系统级的信息和度量，还能显示应用程序的健康状况和其他信号。

5. 跨开发、测试和生产的环境一致性:在笔记本电脑上运行与在云中运行相同。

6. 云和操作系统分布的可移植性:运行在Ubuntu, RHEL, CoreOS, on-prem，谷歌Kubernetes引擎，和其他任何地方。

7. 以应用程序为中心的管理:将抽象级别从在虚拟硬件上运行操作系统提高到使用逻辑资源在操作系统上运行应用程序。

8. 松散耦合、分布式、弹性、解耦的微服务:应用程序被分解成更小的独立部分，可以动态地部署和管理，而不是运行在一台大型单用途机器上的单片堆栈。

9. 资源隔离:可预测的应用程序性能。

10. 资源利用:效率高，密度大。

使用k8s 进行容器化部署，它能提供什么:

1. 服务发现和负载平衡
Kubernetes可以使用DNS名称或自己的IP地址公开容器。如果到容器的通信量很高，Kubernetes能够实现负载平衡并分配网络通信量，从而使部署保持稳定。

2. 存储编排
Kubernetes允许您自动挂载您选择的存储系统，如本地存储、公共云提供商等。

3. 自动化的滚转和回滚
您可以使用Kubernetes描述您部署的容器的期望状态，并且它可以以受控的速率将实际状态更改为期望状态。例如，您可以自动化Kubernetes来为您的部署创建新的容器，删除现有的容器，并将它们的所有资源采用到新的容器中。

4. 自动打包二进制
当你为Kubernetes提供了一组节点，它可以使用这些节点来运行容器化的任务。告诉Kubernetes每个容器需要多少CPU和内存(RAM)。Kubernetes可以在节点上放置容器，以充分利用资源。

5. 自我修复
Kubernetes重新启动失败的容器，替换容器，杀死不响应用户定义的健康检查的容器，并且在它们准备好服务之前不会向客户宣传它们。

6. 私密和配置管理
Kubernetes允许您存储和管理敏感信息，比如密码、OAuth令牌和SSH密钥。您可以部署和更新秘密和应用程序配置，而无需重新构建容器映像，也无需在堆栈配置中公开秘密

K8s 不限制和不提供的：

   由于Kubernetes是在容器级别而不是在硬件级别操作的，所以它提供了一些PaaS产品常见的通用特性，例如部署、扩展、负载平衡、日志记录和监视。但是，Kubernetes不是不可变的整体，这些默认的解决方案是可选的和可插拔的。Kubernetes为构建开发人员平台提供了构建块，但是在重要的地方保留了用户的选择和灵活性。

1. 不限制所支持的应用程序类型。 Kubernetes的目标是支持非常多样化的工作负载，包括无状态、有状态和数据处理工作负载。如果一个应用程序可以在容器中运行，那么它应该可以在Kubernetes上运行。

2. 不部署源代码，也不构建应用程序。持续集成、交付和部署(CI/CD)工作流由组织文化和偏好以及技术需求决定。

3. 不提供应用级服务，如中间件(例如消息总线)、数据处理框架(例如Spark)、数据库(例如MySQL)、缓存，也不提供集群存储系统(例如Ceph)作为内置服务。

这些组件可以运行在Kubernetes上，并且/或者可以由运行在Kubernetes上的应用程序通过可移植的机制(如Open Service Broker)访问。

4. 不指定日志记录、监视或警报解决方案。它提供了一些作为概念验证的集成，以及收集和导出指标的机制。

5. 不提供也不强制要求配置语言/系统(例如，Jsonnet)。它提供了一个声明性API，可以被任意形式的声明性规范作为目标。

6. 不提供也不采用任何全面的机器配置、维护、管理或自修复系统。

7. 此外，Kubernetes不仅仅是一个编排系统。事实上，它消除了对编排的需要。业务流程的技术定义是执行一个已定义的工作流:首先执行a，然后执行B，然后执行c。你怎么从A点到c点都不重要。也不需要集中控制。这使得系统更容易使用，更强大、健壮、有弹性和可扩展。

Kubernetes Components （k8s 组件）

k8s 组件， 来自官网的图：

https://kubernetes.io/docs/concepts/overview/components/

可以类比 jenkins 的 Master & Slave(node)的概念。 当你部署了k8s ,你得到了一个集群。

集群是一组机器，它们称为节点，运行着由k8s管理的容器化应用程序。一个集群至少一个工作节点，至少一个主节点。

工作节点（worker-node）承载着pods ,它们是应用程序的组件。主节点(master node)管理着集群中的工作节点和pods。多主节点用于提供故障转移和高效能的集群。

Master Components

主组件提供集群的控制平面。主组件对集群做出全局决策(例如，调度)，它们检测并响应集群事件。

kube-apiserver

etcd

kube-controller-manager

cloud-controller-manager

kube-apiserver

API服务器是公开了K8s API的Kubernetes控制平台的组件。API服务器是Kubernetes控制平面的前端。Kubernetes API服务器的主要实现是kube-apiserver。

kube-apiserver被设计成水平伸缩，也就是说，它通过部署更多实例来伸缩。可以运行kube-apiserver的多个实例，并在这些实例之间平衡流量。

etcd

一致和高可用的键值存储被用作Kubernetes的所有集群数据备份存储。

更多的关于使用etcd 方便做ks8 备份方案的文档信息：https://etcd.io/docs/

kube-scheduler

调度表，主服务器上的组件，它监视没有分配节点的新创建的pod，并为它们选择要运行的节点。调度决策考虑的因素包括个人和集体的资源需求、硬件/软件/策略约束、类比匹配和非匹配规范、数据位置、工作负载间的干扰和最后期限。

kube-controller-manager

kube-controller-manager是Master上运行控制器的组件。从逻辑上讲，每个控制器都是一个单独的进程，但是为了降低复杂性，它们都被编译成一个单一的二进制文件，并在一个进程中运行。这些控制器包括：

1. 节点控制器:负责节点宕机时的通知和响应

2. 同步控制器:负责为系统中的每个同步控制器对象维护正确的pod数量

3. 端点控制器:填充端点对象(即连接服务和pod)

4. 服务帐户/令牌控制器:为新的名称空间创建默认帐户和API访问令牌

cloud-controller-manager

   云控制器-管理器 运行着与底层云提供商交互的控制器。它是由k8s 1.6 版本引入的功能。

   它只运行特定于云提供程序的控制器循环。云控制器-管理器只运行特定于云提供程序的控制器循环。你必须在kube-controller-manager中禁用这些控制器循环。在启动kube-controller-manager时，可以通过将——cloud-provider标志设置为external来禁用控制器循环。（cloud 控制器在 kube 控制器中禁用？）
   云控制-管理器允许云供应商的代码和Kubernetes代码相互独立地发展。在以前的版本中，Kubernetes核心代码的功能依赖于特定于云提供程序的代码。在未来的版本中，云vend应该维护特定于云供应商的代码。cloud 控制器包括：

1. 节点控制器:用于检查云提供商，以确定一个节点在停止响应后是否已被删除

2. 路由控制器:用于在底层云基础设施中设置路由

3. 服务控制器:用于创建、更新和删除云提供商负载平衡器

4. 卷控制器:用于创建、附加和挂载卷，以及与云提供商交互来编排卷

Node Components

节点组件在每个节点上运行，维护运行的pods并提供Kubernetes运行时环境

kubelet

kube-proxy

Container runtime

kubelet

在集群中的每个节点上运行的代理。它确保容器在一个pod中运行。kubelet采用一组通过各种机制提供的PodSpecs，并确保那些PodSpecs中描述的容器运行正常。kubelet不管理不是由Kubernetes创建的容器。

kube-proxy

kube-proxy是运行在集群中每个节点上的网络代理，实现Kubernetes服务概念的一部分。
kube-proxy维护节点上的网络规则。这些网络规则允许从集群内外的网络会话与pod进行网络通信。
如果有可用的操作系统包过滤层，kube-proxy将使用它。否则，kube-proxy将转发流量本身。

Container runtime

容器运行时是负责运行容器的软件。
Kubernetes支持多个容器运行时:Docker、containerd、crio、rktlet和Kubernetes CRI(容器运行时接口)的任何实现。

Addons --(先不展开)

插件

DNS (should be have dns server)
WEB UI
Container Resource Monitoring
Cluster-level Logging

名称

Kubernetes REST API 中的所有对象都由名称和 UID 明确标识。

客户端提供的字符串，引用资源 url 中的对象，如/api/v1/pods/some name。

一次只能有一个给定类型的对象具有给定的名称。但是，如果删除对象，则可以创建同名的新对象。

按照惯例，Kubernetes 资源的名称最大长度应为 253 个字符，由小写字母、数字、-和 . 组成，但某些资源有更具体的限制。

Kubernetes 系统生成的字符串，唯一标识对象。

在 Kubernetes 集群的整个生命周期中创建的每个对象都有一个不同的 uid，它旨在区分类似实体的历史事件

kubernetes 对象

必需字段

在想要创建的 Kubernetes 对象对应的 .yaml 文件中，需要配置如下的字段：

• apiVersion - 创建该对象所使用的 Kubernetes API 的版本
• kind - 想要创建的对象的类型
• metadata - 帮助识别对象唯一性的数据，包括一个 name 字符串、UID 和可选的 namespace

也需要提供对象的 spec 字段。对象 spec 的精确格式对每个 Kubernetes 对象来说是不同的，包含了特定于该对象的嵌套字段。Kubernetes API 参考能够帮助我们找到任何我们想创建的对象的 spec 格式。 例如，可以从 这里 查看 Pod 的 spec 格式， 并且可以从 这里 查看 Deployment 的 spec 格式。

命名空间

Kubernetes 支持多个虚拟集群，它们底层依赖于同一个物理集群。 这些虚拟集群被称为命名空间。

命名空间适用于存在很多跨多个团队或项目的用户的场景。对于只有几到几十个用户的集群，根本不需要创建或考虑命名空间。当需要名称空间提供的功能时，请开始使用它们。

命名空间为名称提供了一个范围。资源的名称需要在命名空间内是唯一的，但不能跨命名空间。命名空间不能相互嵌套，每个 Kubernetes 资源只能在一个命名空间中。

命名空间是在多个用户之间划分集群资源的一种方法（通过资源配额）。

您可以使用以下命令列出集群中现存的命名空间：

kubectl get namespace

NAME          STATUS    AGE
default       Active    1d
kube-system   Active    1d
kube-public   Active    1d

Kubernetes 会创建三个初始命名空间：

* default 没有指明使用其它命名空间的对象所使用的默认命名空间

* kube-system Kubernetes 系统创建对象所使用的命名空间

* kube-public 这个命名空间是自动创建的，所有用户（包括未经过身份验证的用户）都可以读取它。这个命名空间主要用于集群使用，以防某些资源在整个集群中应该是可见和可读的。这个命名空间的公共方面只是一种约定，而不是要求。

大多数 kubernetes 资源（例如 Pod、Service、副本控制器等）都位于某些命名空间中。但是命名空间资源本身并不在命名空间中。而且底层资源，例如 nodes 和持久化卷不属于任何命名空间。

查看哪些 Kubernetes 资源在命名空间中，哪些不在命名空间中：

# In a namespace
kubectl api-resources --namespaced=true

# Not in a namespace
kubectl api-resources --namespaced=false​

Node

https://kubernetes.io/docs/concepts/architecture/nodes/

       节点是Kubernetes中的工作机器，以前称为minion。根据集群的不同，节点可以是VM或物理机器。每个节点都包含运行pods所需的服务，并由主组件管理。节点上的服务包括容器运行时、kubelet和kube-proxy。

Node status

一个节点状态包括以下信息： Addresses , Conditions , Capacity and Allocatable , Info

Addresses

1. HOSTNAME : 节点内核报告的主机名。可以通过kubelet——主机名覆盖参数进行覆盖。
2. ExternalIP : 通常是可在外部路由的节点的IP地址(可从集群外部获得)。
3. InternalIP : 通常是仅在集群内可路由的节点的IP地址。

Conditions

https://kubernetes.io/docs/concepts/architecture/nodes/#condition

Conditions 字段描述所有正在运行节点的状态。条件的例子包括:

        如果就绪条件的状态在更长时间内保持未知或为False，则向kube-controller-manager传递一个参数，节点控制器将调度节点上的所有pod进行删除。默认的清除超时时间是5分钟。
        在某些情况下，当节点不可用时，apiserver无法与节点上的kubelet通信。在与apiserver重新建立通信之前，不能将删除pods的决定传达给kubelet。p这种情况下，原本计划删除的pod可以继续在分区节点上运行。

        在1.5之前的Kubernetes版本中，节点控制器将强制从apiserver中删除这些不可到达的pod。但是，在1.5或更高版本中，节点控制器不会强制删除pod，直到确认它们已停止在集群中运行。您可以看到在一个不可到达的节点上运行的pod处于终止或未知状态。在Kubernetes无法从底层基础设施推断出某个节点是否永久离开了集群的情况下，集群管理员可能需要手工删除节点对象。从Kubernetes中删除节点对象将导致在该节点上运行的所有Pod对象从apiserver中删除，并释放它们的名称。

'''节点生命周期控制器自动创建表示条件的污点。当调度器将一个Pod分配给一个节点时，调度器将考虑节点的污点，但Pod所允许的污点除外
The node lifecycle controller automatically creates taints that represent conditions. When the scheduler is assigning a Pod to a Node, the scheduler takes the Node’s taints into account, except for any taints that the Pod tolerates''

这里的taints 的含义

https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/

这里的tains 应该是指一种特性，到了某个状态的特性， 允许一个节点击退一组pods。（即有这样污点的pods 会被node 清理）

Capacity and Allocatable 能力和可分配

https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable

描述节点上可用的资源:CPU、内存和可以调度到节点上的最大pod 数。

capacity块中的字段表示节点拥有的资源总量。

Allocatable, 可分配块, 表示一个节点上可供普通pod使用的资源数量。

      Node Capacity
---------------------------
|     kube-reserved       |
|-------------------------|
|     system-reserved     |
|-------------------------|
|    eviction-threshold   |
|-------------------------|
|                         |
|      allocatable        |
|   (available for pods)  |
|                         |
|                         |
---------------------------​

Info:

描述关于节点的一般信息，如内核版本、Kubernetes版本(kubelet和kube-proxy版本)、Docker版本(如果使用)和操作系统名称。Kubelet从节点收集这些信息

Management

与pods和服务不同，节点不是由Kubernetes创建的:它是由诸如谷歌计算引擎之类的云提供商在外部创建的，或者它存在于物理或虚拟机池中。因此，当Kubernetes创建一个节点时，它创建一个表示该节点的对象。创建之后，Kubernetes检查节点是否有效。

Kubernetes在内部创建一个节点对象，并通过基于metada .name字段的健康检查来验证节点。如果节点是有效的—也就是说，如果所有必需的服务都在运行—那么它就有资格运行pod。否则，对于任何集群活动都将忽略它，直到它变得有效为止。

k8s 保留所有无效节点，并保持检查节点是否有效，所以，你必须显性地删除节点。

node controller

节点控制器是master上控制节点的组件。节点控制器在整个节点生命周期里扮演了三个角色。

第一个是在节点注册时为其分配CIDR块(如果打开了CIDR分配)。

第二个是使节点控制器的内部节点列表与云提供商的可用机器列表保持最新。在云环境中运行时，每当某个节点不健康时，节点控制器就会询问云提供商该节点的VM是否仍然可用。否则，节点控制器将从节点列表中删除节点。

第三是监控节点的健康状况。当一个节点变成不可到达时, 节点控制器负责更新NodeStatus 的NodeReady 为：ConditionUnknown“值 ， 然后将所有的pod从节点移除，如果节点仍然是遥不可及的。

(默认的超时时间是40秒，从报告状态未知开始。5秒之后开始从节点驱逐pod。) 节点控制器每隔一秒检查每个节点的状态。

heartbeats 心跳机制

kubelet负责创建和更新节点状态和lease 对象。Lease对象更新独立于节点状态更新。

1. 当状态发生更改时，或者在配置的时间间隔内没有更新时，kubelet将更新Node Status。

NodeStatus更新的默认间隔是5分钟(比不可到达节点的40秒默认超时时间长得多)。

2. kubelet每隔10秒(默认更新间隔)创建并更新lease对象。

CCM 功能

云控制器管理器（cloud controller manager，CCM）这个概念 （不要与二进制文件混淆）创建的初衷是为了让特定的云服务供应商代码和 Kubernetes 核心相互独立演化。云控制器管理器与其他主要组件（如 Kubernetes 控制器管理器，API 服务器和调度程序）一起运行。它也可以作为 Kubernetes 的插件启动，在这种情况下，它会运行在 Kubernetes 之上。

云控制器管理器基于插件机制设计，允许新的云服务供应商通过插件轻松地与 Kubernetes 集成。目前已经有在 Kubernetes 上加入新的云服务供应商计划，并为云服务供应商提供从原先的旧模式迁移到新 CCM 模式的方案。

本文讨论了云控制器管理器背后的概念，并提供了相关功能的详细信息。

这是没有云控制器管理器的 Kubernetes 集群的架构：

在上图中，Kubernetes 和云服务供应商通过几个不同的组件进行了集成，分别是：

• Kubelet
• Kubernetes 控制管理器
• Kubernetes API 服务器

CCM 整合了前三个组件中的所有依赖于云的逻辑，以创建与云的单一集成点。CCM 的新架构如下所示：

CCM 的组成部分

CCM 的大多数功能都来自 KCM，如上一节所述，CCM 运行以下控制器。

• 节点控制器
• 路由控制器
• 服务控制器

节点控制器包含 kubelet 中依赖于云的功能，在引入 CCM 之前，kubelet 负责使用特定于云的详细信息（如 IP 地址，域/区标签和实例类型信息）初始化节点。CCM 的引入已将此初始化操作从 kubelet 转移到 CCM 中。

在这个新模型中，kubelet 初始化一个没有特定于云的信息的节点。但是，它会为新创建的节点添加污点，使节点不可调度，直到 CCM 使用特定于云的信息初始化节点后，才会清除这种污点，便得该节点可被调度。

pods

一个pod 是一组容器，共享网络资源和逻辑卷。

这组窗口有一个init container ， 初始化这些共享资源。其他的窗口是实际运行应用的容器。

Pod Templates -- replica controller 用来随时复制新的pod 的模板.replica 监测到一个node 上的pod 未响应， 便即时复制一个nod ，恢复有效的pod 数量，如果响应的node 恢复了，则删除一个，保持在有效数量。删除选择的机制是怎样的，

1.有效数量是在哪设置的？ lable ?

2. 当超出数量时，删掉一个，是选择哪一个删除？ 是恢复的那一个，还是后增的那一个？

pod 在分发调度之前，在哪里被创建并存储，之后再分发到node ?

 交互流向

Cluster to Master

All communication paths from the cluster to the master terminate at the apiserver (none of the other master components are designed to expose remote services).

从集群到主服务器的所有通信路径都终止于apiserver(其他的主组件都不是为了公开远程服务而设计的)。

Master to cluster

from apiserver to  kubelet

from apiserver to node/pod/service

pod preset

1. Retrieve all PodPresets available for use.
2. Check if the label selectors of any PodPreset matches the labels on the pod being created.
3. Attempt to merge the various resources defined by the PodPreset into the Pod being created.
4. On error, throw an event documenting the merge error on the pod, and create the pod without any injected resources from the PodPreset.
5. Annotate the resulting modified Pod spec to indicate that it has been modified by a PodPreset. The annotation is of the form podpreset.admission.kubernetes.io/podpreset-<pod-preset name>: "<resource version>".

Pod Topology Spread Constraints

Pod 拓扑传播限制