" name="sm-site-verification"/>
侧边栏壁纸
博主头像
PySuper 博主等级

千里之行,始于足下

  • 累计撰写 231 篇文章
  • 累计创建 15 个标签
  • 累计收到 2 条评论

目 录CONTENT

文章目录

Kubernetes | Pod

PySuper
2021-05-10 / 0 评论 / 0 点赞 / 47 阅读 / 0 字
温馨提示:
本文最后更新于2024-05-28,若内容或图片失效,请留言反馈。 所有牛逼的人都有一段苦逼的岁月。 但是你只要像SB一样去坚持,终将牛逼!!! ✊✊✊
  • 自助式Pod
    • 死亡之后不会重启
    • 不会创建副本
  • 控制器管理的Pod
    • 可以按照期望,自动的伸缩
    • 无故死亡之后,会重启

控制器

ReplicationController

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

ReplicaSet

  • 跟 RC 没有本质的不同,只是名字不一样
  • 但是 ReplicaSet 支持集合式的 selector

Deployment

虽然 ReplicaSet 可以独立使用,但一般还是建议使用 Deployment 来自动管理

这样就无需担心跟其他机制的不兼容问题(比如 ReplicaSet 不支持 rolling-update 但 Deployment 支持)

Deployment 为 Pod 和 ReplicaSet 提供了一个声明式定义 (declarative) 方法(替代RC)

  • 典型的应用场景包括:
    • 定义 Deployment 来创建 Pod 和 ReplicaSet
    • 滚动升级和回滚应用
    • 扩容和缩容
    • 暂停和继续 Deployment

Horizontal Pod Autoscaling

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

StatefulSet

StatefulSet 是为了解决有状态服务的问题(对应 RS 和 Deployments 是为无状态服务而设计)其应用场景包括:

  • 稳定的持久化存储
    • Pod 重新调度后,还是能访问到相同的持久化数据
    • 基于 PVC 来实现
  • 稳定的网络标志
    • Pod 重新调度后其 PodName 和 HostName 不变,基于Headless Service来实现
    • 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

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

Cron Job

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

网络通讯方式

Kubernetes 的网络模型假定了所有 Pod 都在一个可以直接连通的扁平的网络空间

这在GCE(Google Compute Engine)里面是现成的网络模型,Kubernetes 假定这个网络已经存在
而在私有云里搭建 Kubernetes 集群,就不能假定这个网络已经存在了。
我们需要自己实现这个网络假设,将不同节点上的 Docker 容器之间的互相访问先打通,然后运行 Kubernetes

  • 同一个 Pod 内的多个容器之间:lo
  • 各 Pod 之间的通讯:Overlay Network
  • Pod 与 Service 之间的通讯:各节点的 Iptables 规则(最新版本已经引入IPVS)

Flannel

Flannel 是 CoreOS 团队针对 Kubernetes 设计的一个网络规划服务

简单来说,它的功能是让集群中的不同节点主机创建的 Docker 容器都具有全集群唯一的虚拟IP地址

而且它还能在这些 IP 地址之间建立一个覆盖网络(Overlay Network)

通过这个覆盖网络,将数据包原封不动地传递到目标容器内

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
0

评论区