Kubernetes 几大概念的作用

更详细的组件通信流程

Kubernetes 主要由以下几个核心组件组成：

1. etcd 保存了整个集群的状态；

2. API Server 提供了资源操作的唯一入口，并提供认证，授权，访问控制，API 注册和发现等机制；

3. Controller Manager 负责维护集群的状态，比如故障检查，自动扩展，滚动更新等；

4. Scheduler 负责资源的调度，按照预定的调度策略将 Pod 调度到相应的机器上；

5. Kubelet 负责维护容器的生命周期，同时也负责 Volume(CVI) 和网络(CNI)的管理；

6. Container Runtime 负责镜像管理以及 Pod 和容器的真正运行(CRI);

7. Kube-proxy 负责为 Service 提供 cluster 内部的服务发现和负载均衡；

理解 k8s 核心几块资源

k8s 默认的组件很多，每一个 Pod 控制器(工作负载)，以及网络插件组件，没法一个个的去读，前期也都被封装在了底层，也关心不到。

因此，只聊我们能用到的几个组件，如 Pod 创建，需要用到几个组件，需要背一背，以及查看对应的资源，在机器上的容器进程信息。

后续不断的加入新知识，再去理解对应的组件，即可循序渐进的理解 k8s 的复杂知识。

当然，建议也是，平日里看 k8s 官网文档，以及如 k8s 权威指南 v5版本书籍，去阅读理论知识，扩充自己的理论知识，更合适。v1-v5

上课，为了更快速的，理解，操作，k8s 组件该如何玩。

1) .快速学会玩法

2).再去看资料理解本质原理

1. CRI

容器运行时 | Kubernetes

容器运行时，这是 k8s 组件之一，负责容器运行。

默认情况 k8s 使用 CRI 容器运行时接口，和你部署的容器交互。

如果同时检测你部署了 docker engine,containerd 两款容器，优先会选用 docker

2. docker engine

https://kubernetes.io/zh-cn/docs/setup/production-environment/container-runtime/#docker

负责 Node 上容器的管理工作，创建 docker 容器实例。

3. kubelet

安装在 Node 节点上的代理程序，用来管理 Pod, 容器，镜像，Volume等。

4. kube-proxy

安装在 Node 上的网络代理程序，提供网络代理，负载均衡，和 Service 通讯

5. k8s 重要资源(学会用 k8s 就靠这个)

不属于k8s的资源，属于重要概念

一. Node

(不属于k8s的资源，属于重要概念)-ECS机器 k8s 运行的一个环境

Pod等资源，属于 k8s 安装好后的，集群内的一个资源信息。

Node 是 Pod 真正运行的主机，可以是物理机，也可以是虚拟机。

为了管理 Pod,每个 Node 节点上至少要运行 container runtime(比如 docker 或 rkt), kuberlet 和 kube-proxy 服务。

1. k8s 工作节点,node,运行环境可以是：：：vmware 创建的一个虚拟机，k8s-node-11 k8s-node-12

2. node 上具体运行啥呢？运行容器，k8s 部署的应用，都是跑在容器里，node 上还得安装 docker,

3.初始化，运行工作节点，或者主节点，背后的逻辑：

a. 下载 k8s 自身的一些组件的镜像。

b. 运行镜像，创建对应的容器，到对应的目标机器上(k8s-master,k8s-node-11,k8s-node-12)

这就是我们主要部署的架构逻辑

k8s-node 的部署逻辑

# POD(10.10.10.3)	根容器	创建一个隔绝的名称空间	Pause/Infra
Volume   容器1	容器2   容器3
k8s-node-12(阿里云ECS)  先安装好 docker,kubelet组件# POD(10.10.10.2)	根容器	创建一个隔绝的名称空间 Pause/Infra
Volume	 容器1	容器2
k8s-node-11(阿里云ECS)  先安装好 docker,kubelet组件# POD(10.10.10.4)	根容器	创建一个隔绝的名称空间 Pause/Infra
Volume	 容器1	
k8s-node-13(阿里云ECS)  先安装好 docker,kubelet组件# 共享资源  kubelet  Docker  kube-proxy
kubelet 和 master 的 api-server 通信  决定容器创建的信息获取，信息更新。
kube-proxy 在 k8s 里，容器要对外提供网络访问，以及 ip 地址设置等。底层基于 iptables 的规则转发数据包，修改数据包。

二 container

Container(容器) 是一种便携式，轻量级的操作系统级虚拟化技术。

它使用 namespace 隔离不同的软件运行环境，并通过镜像自包含软件的运行环境，从而使得容器可以很方便的在任何地方运行。

由于容器体积小且启动快，因此可以在每个容器镜像中打包一个应用程序，这种一对一的应用镜像关系拥有很多好处，使用容器，不需要与外部的基础架构环境绑定，因为每一个应用程序都不需要外部依赖，更不需要与外部的基础架构环境依赖，完美解决了从开发到生产环境的一致性问题。

容器同样比虚拟机更加透明，这有助于监测和管理。尤其是容器进程的生命周期由基础设施管理，而不是被进程管理隐藏在容器内部，最后，每个应用程序用容器封装，管理容器部署就等同于管理应用程序部署。

其他容器的优点还包括：

敏捷的应用程序创建和部署：与虚拟机镜像相比，容器镜像更易用，更高效。
持续开发，集成和部署：提供可靠与频繁的容器镜像构建，部署和快速简便的回滚(镜像是不可变的)。
开发与运维的关注分离：在构建/发布时及创建容器镜像，从而将应用与基础架构分离。
开发，测试与生产环境的一致性：在笔记本电脑上运行和云中一样。
可观测：不仅显示操作系统的信息和度量，还显示应用自身的信息和度量。
云和操作系统的分发可移植性：可运行在 Ubuntu,RHEL,CoreOS,物理机，GKE以及其他任何地方。
以应用为中心的管理：从传统的硬件上部署操作系统提升到操作系统中部署应用程序。
松耦合，分布式，弹性伸缩，微服务：应用程序被分成更小，更独立的模块，并可以动态管理和部署-而不是运行在专用设备上的大型单体程序。
资源隔离：可预测的应用程序性能。
资源利用：高效率和高密度。

1. Pod

Kubernetes 使用 Pod 来管理容器，每个 Pod 可以包含一个或多个紧密关联的容器。
Pod 是一组紧密关联的容器集合，它们共享进程间通信和 Network namespace, 是 Kubernetes 调度的基本单位。
Pod 内的多个容器共享网络和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。
Pod 的设计理念是支持多个容器在一个 Pod 中共享网络地址和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。
Pod 是 k8s 集群中所有业务类型的基础，可以看作运行在 k8s 集群中的小机器人，不同类型的业务就需要不同类型的小机器人去执行。
目前 k8s 中的业务主要可以分为长期伺服型(long-running), 批处理型 (batch), 节点后台支撑型(node-daemon) 和有状态应用型(stateful application)。
分别对应的小机器人控制器为 Deployment, Job, DaemonSet 和 StatefulSet.

1. Pod 是在 k8s 集群中运行部署应用或服务的最小单元，它是可以支持多容器的，
2. Pod 的 IP 是随机变化的，删除 Pod ，IP 变化
3. Pod 内部有一个根容器
4. 一个 Pod 内可以有一个，多个容器 比如 nginx pod 容器组，mysql pod 容器组 等
5. 一个 Pod 内的所有容器，共享根容器的网络名称空间，文件系统，进程资源
6. 一个 Pod 内的容器网络地址，由根容器提供。比如：pod 部署的多种形态
Pod1 	10.10.10.1   Pod1 这个容器组可以包含一个容器 或者多个容器 根据你的需求而定Pod2	10.10.10.2	 无状态	无需数据卷
可以跑一个 nginx-pod  nginx1.14  nginx-pod 容器也会有自己的 pod id  这是						一个无状态的 nginx-pod 容器Pod3	10.10.10.3	持久化容器内的数据，以卷的形式，放在宿主机上(k8s-node节点了)
可以涉及存储  把它的数据以卷的形式 映射 到宿主机上 
nginx-pod   /var/log/nginx/ 涉及存储卷 卷的数据依然映射到宿主机上 /linux0224/nginx/logsPod4 	10.10.10.4	一个 Pod4 容器组中 运行多个容器共享一个数据卷Pod4 	10.10.10.5	IP address	volume	containerized app# Pod 可以是虚拟机 k8s-node-12 也可以是物理机，或者阿里云服务器
1.下载安装(yum install/rpm -ivh) docker 容器引擎
2. 初始化时，自动生成 kubelet 与 kube-proxy 组件
3.Pod 你部署的一个业务容器组，一个，多个容器，都被 pod 管理了# Pod 部署的多种形态,区分，有无数据要持久化，以及容器有无数据共享
1. 无状态	无需数据卷
2. 持久化容器内的数据，以卷的形式，放在宿主机上(k8s-node节点了)
3. 形态3，一个 Pod 下的多个容器共享一个数据卷 比如 一个 pod 下，运行2个 wordpress 容器，的静态数据，读取 NFS # Pod 就想豌豆一样，里面的豆子就像是一个个容器，共享网络，存储  一个个豆子容器被一个豌豆荚的 pod 管理
即碗豆子容器被管理豌豆荚容器管理着  都来自于豌豆荚设置的一个隔离环境

创建 Pod 请求走向

API Server 负责 etcd 存储的所有操作，且只有 API Server 才直接操作 etcd 集群
API Server 对内 (集群中的其他组件) 和对外 (用户) 提供统一的 REST API,其他组件均通过 API Server 进行通信
- Controller Manager, Scheduler, Kube-proxy 和 Kubelet 等均通过 API Server watch API 监测资源变化情况，并对资源作相应的操作。
- 所有需要更新资源状态的操作均通过 API Server 的 REST API 进行
API Server 也会直接调用 Kubelet API (如 logs,exec,attach等)，默认不校验 Kubelet 证书，但可以通过 --kubelet-certificate-authority 开启(而 GKE 通过 SSH 隧道保护他们之间的通信)

Pod 是如何被创建的

1.运维执行创建 Pod 请求(一个 yaml 文件，记录了业务应用的名字，镜像，如何部署等信息)，提交给 api-server
2.api-server 接收请求后将资源清单的信息写入 etcd
3.etcd 存储好信息后反馈 api-server
4.api-server 告知 scheduler 事件信息，scheduler 发现有一个新 pod ,但是没有绑定 node,通过资源清单信息以及算法选择合适的 node
5.将要 pod 和 node 绑定的信息告诉 api-server
6.api-server 将调度结果写入 etcd
7.etcd 更新好 pod 的信息后继续反馈 api-server 
8.此时 kubelet 组件(目标 node) watch 到有一个新 pod 被分配过来了，获取 pod 信息，根据 pod 描述内容创建对应容器
9.kubelet 反馈 pod 创建结果(docker 信息) 给 api-server,且写入 etcd
10. 最终结束一个 pod 的完整创建流程

架构组件的认识

1.系统各个组件分工明确(APIServer 是所有请求入口，CM 是控制中枢，Scheduler 主管调度，而 Kubelet负责运行)，配合流畅，整个运行机制一气呵成。

2. 除了配置管理和持久化组件 ETCD,其他组件并不保存数据，意味除ETCD外其他组件都是无状态的。

3. 因此，从架构设计上对 kubernetes 系统高可用部署提供了支撑。

4. 同时因为组件无状态，组件的升级，重启，故障等并不影响集群最终状态，只要组件恢复后就可以从中所处继续运行。

5. 各个组件和 kube-apiserver 之间的数据推送都是通过 list-watch 机制来实现。

容器的运行状态

创建 pod 是为了运行容器，容器有运行状态，表现为创建的成功，失败，问题。

https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/kubenetes 会跟踪 Pod 中每个容器的状态，就像它跟踪 Pod 总体上的阶段一样，你可以使用容器生命周期回调 来在容器一旦调度器将 pod 分配给某个节点，kubelet 就通过 容器运行时 开始为 pod 创建容器，容器的状态有三种，waiting要检查 Pod 中容器的状态，你可以使用 kubectl describle pod <pod 名称> 其输出中包含 Pod 中每个容器的状态。每种状态都有特定的意义：Waiting (等待)
如果容器并不在 Running 或者 Terminated 状态之一，他就处在 Waiting 状态，处于 Waiting 状态的容器仍在运行它。。。Running (运行中)
Running 状态表明容器正在执行状态并且没有问题发生，如果配置了 postStart 回调，那么该回调已经执行且已完成，如果。。。Terminated(已终止)
处于 Terminated 状态的容器已经开始执行并且或者正常结束或者或者因为某些原因失败，如果你使用 kubectl 来查询包含 Termnated 如果容器配置了 preStop 回调，则该回调会在容器进入 Terminated 状态之前执行

2. Label

Label 也是面试发问的点

Label 是识别 Kubenetes 对象的标签，以 key/value 的方式附加到对象上 (key最长不能超过63字节，value可以为空，也可以是不超过253字节的字符串)。

Label 不提供唯一性，并且实际上经常是很多对象 (Pods) 都使用相同的 label 来标志具体的应用。

label 定义好后其他对象可以使用 Label Selector 来选择一组相同 label 对象（比如 ReplicaSet 和用 label 来选择一组 Pod)，Label Selector 支持以下几种方式：

等式，如 app=nginx 和 env!=production
集合，如 env in (production, qa)
多个 label (它们之间是 AND 关系)，如 app=nginx,env=test

1. label 就像身份证标签一样，用于标识 k8s 的对象
2. 我们传统的机器上应用查找，那是基于 ip:port,但是在 k8s 里，更多匹配关系，都是通过 label 来查找

3. Namespace

k8s 里可以基于 namespace,管理不同环境下的资源，也是一个重要资源，形成逻辑上的不同的项目组。

Namespace 是对一组资源和对象的抽象集合，比如可以用来将系统内部的对象划分为不同的项目组成用户组。常见的 pods, services,replication controllers 和 deployment 等都是属于某一个 namespace 的 (默认是 default)而 node , persistentVolumes 等 不属于任何 namespace.

4.Controller

k8s 控制器种类有很多，用来在不同的场景，如何更好的管理 Pod

1. 上面于超老师也说了，POD可以理解为 k8s 里面的干活的小机器人，不同的类型都要用不同的机器人去执行，
2. 控制这些小机器人的控制器，就主要分为

Replication Controller

也叫 RC 控制器，副本控制器，控制 pod 的副本数；
RC 是 k8s 集群中最早的保证 Pod 高可用的 API 对象；
通过监控运行中的 Pod 来保证集群中运行指定数目的 Pod 副本；
指定的数目可以是多个也可以是1个；
- 当少于指定数目， RC 就会启动运行新的 Pod 副本；
- 多于指定数目，RC 就会杀死多余的 Pod 副本；
- 严格根据你定义的数量，确保POD数量

即使在指定数目为1的情况下，通过 RC 运行 Pod 也比直接运行 Pod 更明智，因为 RC 也可以发挥它高可用的能力，保证永远有1个 Pod 在运行，(pod 挂了，容器就挂了，机器人也就挂了，有控制在，就不怕应用挂了)

RC 是 k8s 较早期的技术概念，比如控制小机器人提供高可用的 Web 服务，启动如3个 pod 副本，也就是3套应用后端。

Replica Set, RS

RS 是 RC 控制器的下一代，也提供副本数，确保 pod (容器的高可用) ，

RS 控制器一般不会直接用，而是结合另一种控制器 (Deployment) 以及更多参数使用。

Deployment

部署控制器，主要用 k8s 部署应用就是靠这个。

Deployment 表示用户对 k8s 集群的一次更新操作。

部署是一个比 RS 应用模式更广泛的 API 对象，可以是创建一个新的服务，更新一个新的服务，也可以是滚动升级一个服务。

滚动升级一个服务，实际是创建一个新的 RS,然后逐渐将新 RS 中副本数增加到理想状态，将旧 RS 中的副本数减小到0的复合操作；

这样一个复合操作用一个 RS 是不太好描述的，所以用一个更通用的 Deployment 来描述。

以 k8s 的 发展方向，未来对所有长期服务型的业务的管理，都会通过 Deployment 来管理。

(LNMP就是典型代表，需要高可用，负载均衡的应用集群，积极更新多个后端，这些所有的)

长期服务型的应用特点在于业务应用提供访问，有的 Node 上 可能有改 pod ,有的 Node 可以没有

DaemonSet

后台支撑服务集控制器的功能在于关注 k8s 中的 Node (物理机，虚拟机)
能保证每个节点上都有一个此类的 Pod 在运行
- 这种特性，就很实用用于部署如监控软件的 agenl,采集每一个目标 Node 的资源数据，
节点可以所有集群中的机器，也可能是基于 NodeSelector选定的部分节点。
DaemonSet 主要用于
- 日志采集
- 监控采集
- 存储
- 这几类服务的运行

SeatefulSet

有状态服务集在 k8s 1.3 版本后发布，之前于超老师说过，nginx 此类应用一般是无状态的，可以随意创建，删除；

还有一种就是有状态(stateful)的应用。

RC,RS,deployment 主要提供无状态服务的部署， pod 的名字也都是随机生成的，一个 pod 挂了 ，重建一个就好，pod 的。。。而 stateful 用来控制有状态的，每一个 pod 的名字是预先定义好的，不能更改；
无状态的 pod 一般不会挂载存储，保证 pod 共享状态即可，可以随意创建，删除;
有状态的 pod ,pod 都会单独挂载一个存储，如果 pod 出了问题，其他节点要重新创建 pod,并且获取原有 pod 的存储信息，继续。。。这个特性明显就是提供给数据库使用。

5. Service

上述讲的 pod 控制器，是实现了 Pod,容器被创建在目标 Node 机器，以及确保了数量，副本数；

但是目前还没说，这些 Pod 该如何访问？分散在不同的机器，通过什么 ip 去访问？

Node 节点主要就是 kubelet 和 api-server 通信，Pod 管理，也就是 docker 管理以及 kube-proxy 实现网络代理功能。

pause-amd64 是 kubernetes 基础设施的一部分，kubernetes 管理的所有 Pod 里，pause-amd64容器是第一个启动的，用于实现 pause container 作为 Pod 里其他所在 container 的 parent container,主要有两个职责：

1. 是 Pod 里其他容器共享 linux namespace 的基础。

2. 扮演 PID 1 的角色，负责处理僵尸进程。

Kubernetes 的官网解释:

https://github.com/kubernetes/kubernetes/tree/master/build/pause

参考资料

https://jimmysong.io/kubernetes-handbook/concepts/pause-container.html
https://lib.jimmysong.io/

Kubernetes 几大概念的作用

更详细的组件通信流程

Kubernetes 主要由以下几个核心组件组成：

1. etcd 保存了整个集群的状态；

2. API Server 提供了资源操作的唯一入口，并提供认证，授权，访问控制，API 注册和发现等机制；

3. Controller Manager 负责维护集群的状态，比如故障检查，自动扩展，滚动更新等；

4. Scheduler 负责资源的调度，按照预定的调度策略将 Pod 调度到相应的机器上；

5. Kubelet 负责维护容器的生命周期，同时也负责 Volume(CVI) 和网络(CNI)的管理；

6. Container Runtime 负责镜像管理以及 Pod 和容器的真正运行(CRI);

7. Kube-proxy 负责为 Service 提供 cluster 内部的服务发现和负载均衡；

理解 k8s 核心几块资源

k8s 默认的组件很多，每一个 Pod 控制器(工作负载)，以及网络插件组件，没法一个个的去读，前期也都被封装在了底层，也关心不到。

因此，只聊我们能用到的几个组件，如 Pod 创建，需要用到几个组件，需要背一背，以及查看对应的资源，在机器上的容器进程信息。

后续不断的加入新知识，再去理解对应的组件，即可循序渐进的理解 k8s 的复杂知识。

当然，建议也是，平日里看 k8s 官网文档，以及如 k8s 权威指南 v5版本书籍，去阅读理论知识，扩充自己的理论知识，更合适。v1-v5

上课，为了更快速的，理解，操作，k8s 组件该如何玩。

1) .快速学会玩法

2).再去看资料理解本质原理

1. CRI

容器运行时 | Kubernetes

容器运行时，这是 k8s 组件之一，负责容器运行。

默认情况 k8s 使用 CRI 容器运行时接口，和你部署的容器交互。

如果同时检测你部署了 docker engine,containerd 两款容器，优先会选用 docker

2. docker engine

https://kubernetes.io/zh-cn/docs/setup/production-environment/container-runtime/#docker

负责 Node 上容器的管理工作，创建 docker 容器实例。

3. kubelet

安装在 Node 节点上的代理程序，用来管理 Pod, 容器，镜像，Volume等。

4. kube-proxy

安装在 Node 上的网络代理程序，提供网络代理，负载均衡，和 Service 通讯

5. k8s 重要资源(学会用 k8s 就靠这个)

不属于k8s的资源，属于重要概念

一. Node

(不属于k8s的资源，属于重要概念)-ECS机器 k8s 运行的一个环境

Pod等资源，属于 k8s 安装好后的，集群内的一个资源信息。

Node 是 Pod 真正运行的主机，可以是物理机，也可以是虚拟机。

为了管理 Pod,每个 Node 节点上至少要运行 container runtime(比如 docker 或 rkt), kuberlet 和 kube-proxy 服务。

1. k8s 工作节点,node,运行环境可以是：：：vmware 创建的一个虚拟机，k8s-node-11 k8s-node-12

2. node 上具体运行啥呢？运行容器，k8s 部署的应用，都是跑在容器里，node 上还得安装 docker,

3.初始化，运行工作节点，或者主节点，背后的逻辑：

a. 下载 k8s 自身的一些组件的镜像。

b. 运行镜像，创建对应的容器，到对应的目标机器上(k8s-master,k8s-node-11,k8s-node-12)

这就是我们主要部署的架构逻辑

k8s-node 的部署逻辑

二 container

Container(容器) 是一种便携式，轻量级的操作系统级虚拟化技术。

它使用 namespace 隔离不同的软件运行环境，并通过镜像自包含软件的运行环境，从而使得容器可以很方便的在任何地方运行。

容器同样比虚拟机更加透明，这有助于监测和管理。尤其是容器进程的生命周期由基础设施管理，而不是被进程管理隐藏在容器内部，最后，每个应用程序用容器封装，管理容器部署就等同于管理应用程序部署。

其他容器的优点还包括：

敏捷的应用程序创建和部署：与虚拟机镜像相比，容器镜像更易用，更高效。

持续开发，集成和部署：提供可靠与频繁的容器镜像构建，部署和快速简便的回滚(镜像是不可变的)。

开发与运维的关注分离：在构建/发布时及创建容器镜像，从而将应用与基础架构分离。

开发，测试与生产环境的一致性：在笔记本电脑上运行和云中一样。

可观测：不仅显示操作系统的信息和度量，还显示应用自身的信息和度量。

云和操作系统的分发可移植性：可运行在 Ubuntu,RHEL,CoreOS,物理机，GKE以及其他任何地方。

以应用为中心的管理：从传统的硬件上部署操作系统提升到操作系统中部署应用程序。

松耦合，分布式，弹性伸缩，微服务：应用程序被分成更小，更独立的模块，并可以动态管理和部署-而不是运行在专用设备上的大型单体程序。

资源隔离：可预测的应用程序性能。

资源利用：高效率和高密度。

1. Pod

Kubernetes 使用 Pod 来管理容器，每个 Pod 可以包含一个或多个紧密关联的容器。

Pod 是一组紧密关联的容器集合，它们共享 进程间通信 和 Network namespace, 是 Kubernetes 调度的基本单位。

Pod 内的多个容器共享网络和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。

Pod 的设计理念是支持多个容器在一个 Pod 中共享网络地址和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。

Pod 是 k8s 集群中所有业务类型的基础，可以看作运行在 k8s 集群中的小机器人，不同类型的业务就需要不同类型的小机器人去执行。

目前 k8s 中的业务主要可以分为长期伺服型(long-running), 批处理型 (batch), 节点后台支撑型(node-daemon) 和有状态应用型(stateful application)。

分别对应的小机器人控制器为 Deployment, Job, DaemonSet 和 StatefulSet.

创建 Pod 请求走向

API Server 负责 etcd 存储的所有操作，且只有 API Server 才直接操作 etcd 集群

API Server 对内 (集群中的其他组件) 和对外 (用户) 提供统一的 REST API,其他组件均通过 API Server 进行通信

Controller Manager, Scheduler, Kube-proxy 和 Kubelet 等均通过 API Server watch API 监测资源变化情况，并对资源作相应的操作。

所有需要更新资源状态的操作均通过 API Server 的 REST API 进行

API Server 也会直接调用 Kubelet API (如 logs,exec,attach等)，默认不校验 Kubelet 证书，但可以通过 --kubelet-certificate-authority 开启(而 GKE 通过 SSH 隧道保护他们之间的通信)

Pod 是如何被创建的

架构组件的认识

1.系统各个组件分工明确(APIServer 是所有请求入口，CM 是控制中枢，Scheduler 主管调度，而 Kubelet负责运行)，配合流畅，整个运行机制一气呵成。

2. 除了配置管理和持久化组件 ETCD,其他组件并不保存数据，意味 除ETCD外 其他组件都是无状态的。

3. 因此，从架构设计上对 kubernetes 系统高可用部署提供了支撑。

4. 同时因为组件无 状态，组件的升级，重启，故障等并不影响集群最终状态，只要组件恢复后就可以从中所处继续运行。

5. 各个组件和 kube-apiserver 之间的数据推送都是通过 list-watch 机制来实现。

Pod 是一组紧密关联的容器集合，它们共享进程间通信和 Network namespace, 是 Kubernetes 调度的基本单位。

2. 除了配置管理和持久化组件 ETCD,其他组件并不保存数据，意味除ETCD外其他组件都是无状态的。

4. 同时因为组件无状态，组件的升级，重启，故障等并不影响集群最终状态，只要组件恢复后就可以从中所处继续运行。

label 定义好后其他对象可以使用 Label Selector 来选择一组相同 label 对象（比如 ReplicaSet 和用 label 来选择一组 Pod)，Label Selector 支持以下几种方式：

但是目前还没说，这些 Pod 该如何访问？分散在不同的机器，通过什么 ip 去访问？

pause-amd64 是 kubernetes 基础设施的一部分，kubernetes 管理的所有 Pod 里，pause-amd64容器是第一个启动的，用于实现 pause container 作为 Pod 里其他所在 container 的 parent container,主要有两个职责：