kubernetes-第二篇基础概念

小灰灰 2023-02-22 05:12 33阅读 0赞

### Pod的概念 ###

#### Pod类型 ####

*  自主式 Pod
 *  控制器管理的 Pod

#### Pod 控制器类型 ####

*  ReplicationController & ReplicaSet & Deployment >HPA（HorizontalPodAutoScale）
 *  StatefullSet
 *  DaemonSet
 *  Job，Cronjob

#### ReplicationController & ReplicaSet & Deployment ####

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

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

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

#### Deployment(ReplicaSet) ####

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 来实现
 *  有序收缩，有序删除（即从 N-1 到 0）

#### DaemonSet ####

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

使用 DaemonSet 的一些典型用法：

*  运行集群存储 daemon，例如在每个 Node 上运行 glusterd、ceph。
 *  在每个 Node 上运行日志收集 daemon，例如fluentd、logstash。
 *  在每个 Node 上运行监控 daemon，例如 Prometheus Node Exporter

#### Job，Cronjob ####

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

*  在给定时间点只运行一次
 *  周期性地在给定时间点运行

#### 服务发现 ####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center]

### 网络通讯方式 ###

#### 网络通讯模式 ####

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

**同一个 Pod 内的多个容器之间：lo**

**各 Pod 之间的通讯：Overlay Network**

\*\*Pod 与 Service 之间的通讯：各节点的 Iptables 规则 \*\*

通过ifconfig可以查看

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
            inet 127.0.0.1  netmask 255.0.0.0
            inet6 ::1  prefixlen 128  scopeid 0x10<host>
            loop  txqueuelen 1000  (Local Loopback)
            RX packets 130  bytes 14131 (13.7 KiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 130  bytes 14131 (13.7 KiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

#### 网络解决方案 Kubernetes + Flannel ####

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

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 1]  
ETCD 之 Flannel 提供说明：

> 存储管理 Flannel 可分配的 IP 地址段资源
> 
> 监控 ETCD 中每个 Pod 的实际地址，并在内存中建立维护 Pod 节点路由表

#### 不同情况下网络通信方式 ####

同一个 Pod 内部通讯：同一个 Pod 共享同一个网络命名空间，共享同一个 Linux 协议栈

Pod1 至 Pod2

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

Pod 至 Service 的网络：目前基于性能考虑，全部为 iptables 维护和转发

Pod 到外网：Pod 向外网发送请求，查找路由表, 转发数据包到宿主机的网卡，宿主网卡完成路由选择后，iptables执 行Masquerade，把源 IP 更改为宿主网卡的 IP，然后向外网服务器发送请求 外网访问 Pod：Service

docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
            inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
            ether 02:42:69:89:95:a7  txqueuelen 0  (Ethernet)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 2]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center]: https://img-blog.csdnimg.cn/20200701200437154.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 1]: https://img-blog.csdnimg.cn/20200701200504257.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 2]: https://img-blog.csdnimg.cn/20200701200529100.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200116191747278.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw,size_16,color_FFFFFF,t_70