Kubernetes | 基础概念 - BasicConcept

Pod 概念

自主 Pod

同一个 Pod 内部共用网络栈。
Php-fpm 和 nginx 其实都共用 pause 的网络栈。
在同一个 Pod 里，容器的端口不能冲突。
- 冲突的话会起不来或无限重启。
在同一个 Pod 里，既共享存储，又共享网络栈。

ReplicationController & ReplicaSet & Deployment (控制器管理 Pod)

ReplicationController

ReplicationController 用来确保容器应用的副本数始终保持在用户定义的副本数。即如果有容器异常退出，会自动创建新的 Pod 来替代，而如果异常多出来的容器也会自动回收。在新版本的 Kubernetes 中建议使用 ReplicaSet 来取代 ReplicationController。

新版本中官方抛弃 RC，全部转向 RS。

ReplicaSet

ReplicaSet 跟 ReplicationController 没有本质的不同，只是名字不一样，并且 ReplicaSet 支持集合式的 selector。

虽然 ReplicaSet 可以独立使用，但一般还是建议使用 Deployment 来自动管理 ReplicaSet，这样就无需担心跟其他机制的不兼容问题（比如 ReplicaSet 不支持 rolling-update，但 Deployment 支持）。

RS 不支持滚动更新；Deploy 支持。

滚动更新创建 V2 的时候 V1 不删除，只是停用，还可以再次回滚。

Deployment

Deployment 为 Pod 和 ReplicaSet 提供了一个声明式定义（declarative）方法，用来替代以前的 ReplicationController 来方便的管理应用。典型的应用场景包括：

定义 Deployment 来创建 Pod 和 ReplicaSet。
滚动升级和回滚应用。
扩容和缩容。
暂停和继续 Deployment。

HPA（HorizontalPodAutoScale）

Horizontal Pod Autoscaling 仅适用于 Deployment 和 ReplicaSet，在 V1 版本中仅支持根据 Pod 的 CPU 利用率扩所容，在 v1alpha 版本中，支持根据内存和用户自定义的 metric 扩缩容。

弹性伸缩水平自动扩展

StatefullSet

StatefulSet 是为了解决有状态服务的问题（对应 Deployments 和 ReplicaSets 是为无状态服务而设计）。其应用场景包括：

稳定的持久化存储，即 Pod 重新调度后还是能访问到相同的持久化数据，基于 PVC 来实现。
稳定的网络标志，即 Pod 重新调度后其 PodName 和 HostName 不变，基于 Headless Service（即没有 Cluster IP 的 Service）来实现。
有序部署，有序扩展，即 Pod 是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行（即从 0 到 N-1，在下一个 Pod 运行之前所有之前的 Pod 必须都是 Running 和 Ready 状态），基于 init containers 来实现。
- 单个 Pod 中容器的启动顺序。
有序收缩，有序删除（即从 N-1 到 0）。
- 单个 Pod 中容器的删除顺序。

DaemonSet

DaemonSet 确保全部（或者一些）Node 上运行一个 Pod 的副本。当有 Node 加入集群时，也会为他们新增一个 Pod。当有 Node 从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。使用 DaemonSet 的一些典型用法：

运行集群存储 daemon，例如在每个 Node 上运行 glusterd、ceph。
在每个 Node 上运行日志收集 daemon，例如 fluentd、logstash。
在每个 Node 上运行监控 daemon，例如 Prometheus Node Exporter。
有需求在每个 Pod 上运行一个东西，那么就可以用这个。

Job，Cronjob

Job 负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个 Pod 成功结束。Cron Job 管理基于时间的 Job，即：

在给定时间点只运行一次。
周期性地在给定时间点运行。
例如备份数据库。
可以设置如果不是正常退出，那么可以重新执行（可以加次数），并且有复用性。

Service 是通过标签选择器选择到 Pod 的。
Service 会有 IP Port 供 Client 访问。

案例

传统架构

K8s 架构

K8s 是一个扁平化网络，容器之间是可以互相访问的。

网络通讯方式

网络通讯模式

Kubernetes 的网络模型假定所有 Pod 都在一个 可以直接连通的扁平的网络空间中 。在 GCE（Google Compute Engine）中，这是现成的网络模型，Kubernetes假定这个网络已经存在。但是，在私有云中搭建 Kubernetes 集群时，就不能假定这个网络已经存在。我们需要自己实现这个网络假设，将不同节点上的 Docker 容器之间的互相访问先打通，然后运行 Kubernetes。

同一个 Pod 内的多个容器之间：lo [Pause - localhost]
各 Pod 之间的通讯：Overlay Network
Pod 与 Service 之间的通讯：各节点的 Iptables 规则

网络解决方案 Kubernetes + Flannel

Flannel 是 CoreOS 团队针对 Kubernetes 设计的一个网络规划服务。简单来说，它的功能是让集群中的不同节点主机创建的 Docker 容器都具有全集群唯一的虚拟 IP 地址。而且它还能在这些 IP 地址之间建立一个覆盖网络（Overlay Network），通过这个覆盖网络，将数据包原封不动地传递到目标容器内。

不同机器容器 IP 不能一致。
最难的、迫切需要解决的：不同机器之间的 Pod 如何互相访问。

UDP 转发的数据包更快。

ETCD 之 Flannel 提供说明：

存储管理 Flannel 可分配的 IP 地址段资源。
监控 ETCD 中每个 Pod 的实际地址，并在内存中建立维护 Pod 节点路由表。
所以如果要高可用的话，ETCD 一定要是最先高可用的。官方已经解决好了它的集群化，天生支持高可用，非常优秀的集群化。

不同情况下网络通信方式

同一个 Pod 内部通讯：同一个 Pod 共享同一个网络命名空间，共享同一个 Linux 协议栈 [Localhost 回环网卡通信]。

Pod1 至 Pod2

Pod1 与 Pod2 不在同一台主机，Pod 的地址是与 docker0 在同一个网段的，但 docker0 网段与宿主机网卡是两个完全不同的 IP 网段。不同 Node 之间的通信只能通过宿主机的物理网卡进行。将 Pod 的 IP 和所在 Node 的 IP 关联起来，通过这个关联让 Pod 可以互相访问。
Pod1 与 Pod2 在同一台机器，由 Docker0 网桥直接转发请求至 Pod2，不需要经过 Flannel。