K8S--02Kubernetes 基础概念--学习笔记sgg

文章目录

• • 2.1 Pod概念
  • • 2.1.1 Pod类型
    • 2.1.2 Pod控制器类型
    • • 1.ReplicationController & ReplicaSet
      • 2.Deployment
      • 3.HPA（HorizontalPodAutoScale）
      • 4.StatefullSet
      • 5.DaemonSet
      • 6.Job，Cronjob
    • 2.1.3 服务发现
  • 2.2 网络通信方式
  • • • 2.2.1 网络通讯模式
      • 2.2.2 网络解决方案Kubernetes + Flannel -1
    • 2.2.3 不同情况下网络通信方式
    • • 组件通讯示意图

2.1 Pod概念 2.1.1 Pod类型

自主式Pod

控制器管理的Pod

因此

• 在同一个pod中，容器端口不能冲突

2.1.2 Pod控制器类型 1.ReplicationController & ReplicaSet

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

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

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

2.Deployment

Deployment 为Pod 和ReplicaSet 提供了一个声明式定义(declarative) 方法，用来替代以前的ReplicationController

来方便的管理应用。典型的应用场景包括：

• 定义Deployment 来创建Pod 和ReplicaSet

• 滚动升级和回滚应用

• 扩容和缩容

• 暂停和继续Deployment

Deployment运行原理图解

• 更新时先建立副本RS-1，再逐步将RS运行的容器v1移至RS-1，并且停用RS
• 可进行回滚，是因为RS并没有被删除，而是停用！

3.HPA（HorizontalPodAutoScale）

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

扩缩容

4.StatefullSet

Docker是无状态服务：不需要进行实时数据分析存储

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）

5.DaemonSet

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

使用DaemonSet 的一些典型用法：

• 运行集群存储daemon，例如在每个Node 上运行glusterd、ceph。

• 在每个Node 上运行日志收集daemon，例如fluentd、logstash。

• 在每个Node 上运行监控daemon，例如Prometheus Node Exporter

6.Job，Cronjob

Job 负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个Pod

成功结束

Cron Job管理基于时间的Job，即：

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

2.1.3 服务发现

可以延申的概念：

pod与pod直接的通讯方案

2.2 网络通信方式 2.2.1 网络通讯模式

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

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

• 各Pod 之间的通讯：Overlay Network（全平台网络）

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

2.2.2 网络解决方案Kubernetes + Flannel -1

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

• 跨主机还想要通过ip进行通讯
• 二次封装、二次解封

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

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

1. 同一个Pod 内部通讯：同一个Pod 共享同一个网络命名空间，共享同一个Linux 协议栈
2. Pod1 至Pod2

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

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

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

3. 外网访问Pod：Service

组件通讯示意图