K8s-Pod介绍

Pod介绍

  • Pod：：Kubernetes 集群调度的最小单位，一组容器的逻辑结合，把pod看成 是封装了一组容器的最小单位，一个pod一个独立的网络栈
  • Pod分类：
    • 自举式Pod：一旦损坏，没有办法自动恢复
    • 控制器管理式Pod：通过控制器创建，不同的控制器拥有不同的特性
# RC、RS、Deployment

# RC 3 pod nginx，其中一个死，RC会自动创建一个，只要集群 不死	
	pod app=nginx 
	pod app=nginx 
	pod app=nginx 
# RS 4 pod nginx 可做运算标签，灵活度更强 
	pod app=1 
	pod app=nginx-rs 
	pod app=nginx-rs 
	
# Deployment 4 pod nginx 滚动更新，死一个更新一个 
	Deployment > RS > pod
	
# Job、Cronjob 运行批处理任务，关心的是pod的返回码 
	#如果 pod 退出码为 0，代表任务结束，否则重新创建 pod 完整批 处理任务
	
# DaemonSet 会保证每个物理节点有且只有一个 pod 被运行

# statefulSet 有状态服务可被封装在statefulSet，此控制器会有持久卷分配给pod，数据保留
	有序扩容缩
	稳定的存储卷
	稳定的网络标识
	稳定的创建队列以及回收队列：删除和创建有序

Pod工作方式：

优化后方案：

第一个容器：pause，多个pause组成一个集群

k8s服务分类：有状态服务，无状态服务，中心化服务，去中心话服务

  • 有状态服务

    • 服务端每次都记录与之会话的客户端信息 , 从而识别客户端身份 , 根据用 户身份进行请求的处理 ,比如Tomcat中的session. (MySQL也是有状态服务)
    • 缺点：server 自身消耗较多的存储资源 , 存储大量session 服务端保存着用户的状态 , 无法做到水平扩展 客户端请求依赖服务器 , 多次请求 必须依赖同一台服务器

  • 无状态服务

    • 客户端每次想服务端发起请求 , 自己需要携带自描述信息 , 服务端通过这 些信息识别用户身份
    • 优点：客户端请求不依赖服务端的信息，任务多次请求 ,不需要访问同一台服务器
    • 服务端的集群和状态对客户端透明 , 服务端可以任意地迁移和伸缩 , 减小服务器存储压力

  • 如何区分有状态服务和无状态服务？

    • 两个来自相同的发起者的请求,在服务端是否有上下文关系 , 有则为有状 态服务 ,无则为无状态服务
    • 对于有状态服务，在做高可用的第一步，应该考虑如何做到共享存储

  • 中心化服务/去中心化服务

    • 中心化（Centralization）和去中心化（Decentralization）就是集权与 分权，在互联网上，就是指从我说你听的广播模式，向人人有个小喇叭的广场 模式转变。中心化的典型例子是门户网站，去中心化的典型例子是 blog、 UGC、社交媒体等。很多人对去中心化有一些误解，比如说 Facebook、 Twitter 等正在成为更集中的中心。去中心化不是说今后不再有大网站，也不 是说大网站就一定是中心化的，去中心化主要是指技术对普通用户的赋权。另 外，去中心化也不是人人绝对平等的意思，总会有人更善于利用技术赋予的可 能性，有人则不善用或不在乎
    • 目前多数为中心化服务(kubernetes依然为中心化服务)，去中心化服务 较少 (如元宇宙 , 区块链)
    • 门户网站：所谓门户网站，是指提供某类综合性互联网信息资源并提供有关信息服 务的应用系统。在全球范围中，最为著名的门户网站则是谷歌以及雅虎，而在 中国，著名的门户网站有新浪、网易、搜狐、腾讯、百度、新华网、人民网、 凤凰网等

控制器的详细说明

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

​ ReplicaSet 跟 ReplicationController 没有本质的不同，只是名字不一 样，并且 ReplicaSet 支持集合式的 selector(标签选择器)

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

  • 结论
    • RC：将用户定义的 Pod 数量与当前运行的 pod 数量相匹配（不能多不能 少）
    • RS：跟 RC 相同，但是可以做标签运算
    • Deployment：通过创建不同的 RS，可以实现滚动更新

​ HPA：可以通过控制 RC、RS、Deployment 实现 pod 数量的调整，可以 根据 CPU、内存、自定义阀值 实现触发(Horizontal Pod Autoscaling 仅适 用于 Deployment 和 ReplicaSet ，在 V1 版本中仅支持根据 Pod 的 CPU 利用 率扩所容，在 v1alpha 版本中，支持根据内存和用户自定义的 metric 扩缩容)

statefulSet

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

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

  • 使用 DaemonSet 的一些典型用法：
    • 运行集群存储 daemon，例如在每个 Node 上运行 glusterd、ceph。
    • 在每个 Node 上运行日志收集 daemon，例如fluentd、logstash。
    • 在每个 Node 上运行监控 daemon，例如 Prometheus Node Exporter

批处理-脚本：希望脚本正常执行成功 返回码 0 --- 成功

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

​ pod 1 ---杀死

​ pod 2 ---杀死

​ pod 0 ---返回码为 0 执行成功

CronJob 轮训创建 Job 实现脚本运行 * * * * * 分时日月周

CronJob 管理基于时间的 Job，即： 在给定时间点只运行一次 周期性地在给定时间点运行

网路通讯方式

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

  • 同物理机的容器间的网络模式

  • 同物理机的Pod的网络模式

  • 同物理机的两个不同Pod的网络模式

  • 不同物理机之间的pod解决方案

    • Flannel
    • Calico

  • Flannel介绍

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

​ 实现过程：

​ ETCD 为 Flannel 提供说明： 存储管理 Flannel 可分配的 IP 地址段资源 监控 ETCD 中每个 Pod 的实际地址，并在内存中建立维护 Pod 节点路由 表 因为是在内网进行通讯，所以使用UDP，速度快，若使用TCP，还会涉及到 TCP的慢启动，在这种小报文传输场景中，并不适合TCP

  • Calico介绍

    • calico是一个比较有趣的虚拟网络解决方案，完全利用路由规则实现动态组网，通过BGP协议通告路由。
    • calico的好处是endpoints组成的网络是单纯的三层网络，报文的流向完全通过路由规则控制，没有overlay等额外开销。
    • calico的endpoint可以漂移，并且实现了acl。
    • calico的缺点是路由的数目与容器数目相同，非常容易超过路由器、三层交换、甚至node的处理能力，从而限制了整个网络的扩张。
    • calico的每个node上会设置大量（海量)的iptables规则、路由，运维、排障难度大。
    • calico的原理决定了它不可能支持VPC，容器只能从calico设置的网段中获取ip。
    • calico目前的实现没有流量控制的功能，会出现少数容器抢占node多数带宽的情况。
    • calico的网络规模受到BGP网络规模的限制

  • Calico组网原理

​ calico组网的核心原理就是IP路由，每个容器或者虚拟机会分配一个workload-endpoint(wl)。从nodeA上的容器A内访问nodeB上的容器B时:

  • 注释：
    • 从ConA中发送给ConB的报文被nodeA的wl-A接收，根据nodeA上的路由规则，经过各种iptables规则后，转发到nodeB。
    • 如果nodeA和nodeB在同一个二层网段，下一条地址直接就是node-B，经过二层交换机即可到达。
    • 如果nodeA和nodeB在不同的网段，报文被路由到下一跳，经过三层交换或路由器，一步步跳转到node-B。
    • 核心问题是，nodeA怎样得知下一跳的地址？答案是node之间通过BGP协议交换路由信息。

每个node上运行一个软路由软件bird，并且被设置成BGP Speaker，与其它node通过BGP协议交换路由信息。可以简单理解为，每一个node都会向其它node通知这样的信息:

​ 我是X.X.X.X，某个IP或者网段在我这里，它们的下一跳地址是我。

​ 通过这种方式每个node知晓了每个workload-endpoint的下一跳地址

kubernetes网络拓扑结构

  • pod网络：真实服务器的IP地址
  • service网络：负载均衡调度器的IP地址
posted @ 2022-07-21 15:42  Sunset_cloud  阅读(203)  评论(0)  编辑  收藏  举报