南山草舍

0%

K8S概念及组件说明

发表于 更新于 分类于

K8S学习知识图谱：https://www.processon.com/view/link/637d798d6376897f2b8d9f30

K8S是什么？

Kubernetes是容器集群管理系统，是一个开源的平台，可以实现容器集群的自动化部署、自动扩缩容、维护等功能。Kubernetes是Google 2014年创建管理的，是Google 10多年大规模容器管理技术Borg的开源版本。

K8S特点

  • 可移植: 支持公有云，私有云，混合云，多重云（multi-cloud）
  • 可扩展: 模块化, 插件化, 可挂载, 可组合
  • 自动化: 自动部署，自动重启，自动复制，自动伸缩/扩展

K8S组件

  • APISERVER：所有服务访问统一入口，并提供认证、授权、访问控制、API注册和发现等机制；
  • CrontrolerManager: 负责维护集群的状态，比如故障检测、自动扩展、滚动更新、维持副本期望数目等；
  • Scheduler：负责资源的调度，选择合适的节点进行分配任务
  • ETCD：键值对数据库 储存K8S集群所有重要信息 (持久化)
  • Kubelet：直接跟容器引擎交互实现容器的生命周期管理
  • Kube-proxy：负责写入规则至 IPTABLES、IPVS 实现服务映射访问的
  • COREDNS：可以为集群中的SVC创建一个域名IP的对应关系解析
  • DASHBOARD：给K8S 集群提供一个B/S结构访问体系
  • INGRESS CONTROLLER: 官方只能实现四层代理，INGRESS 可以实现七层代理
  • FEDETATION：提供一个可以跨集群中心多K8S统一管理功能
  • PROMETHEUS：提供一个K8S集群的监控能力
  • EFK：提供K8S集群日志统一分析接入平台

K8S架构

POD概念

Pod是Kubernetes创建或部署的最小/最简单的基本单位，一个Pod代表集群上正在运行的一个进程。

一个Pod封装一个应用容器（也可以有多个容器），存储资源、一个独立的网络IP以及管理控制容器运行方式的策略选项。Pod代表部署的一个单位：Kubernetes中单个应用的实例，它可能由单个容器或多个容器共享组成的资源。

控制器类型

ReplicationController & ReplicaSet & Deployment

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

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

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

HPA(HorizontalPodAutoscale)

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

StatefulSet

StatefulSet 是为了解决有状态服务的问题（对应 Deployment 和 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，即：

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

网络通讯

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

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

网络解决方案Flannel

ETCD 之 Flannel 提供说明：

存储管理 Flannel 可分配的 IP 地址段资源

监控 ETCD 中每个 Pod 的实际地址，并在内存中建立维护 Pod 节点路由表

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

    同一个 Pod 共享同一个网络命名空间，共享同一个 Linux 协议栈）

  • 各 Pod 之间的通讯：Overlay Network

​ Pod1 与 Pod2 不在同一台主机，Pod 的地址是与 docker0 在同一个网段的，但 docker0 网段与宿主机网卡是两个完全不同的 IP 网段，并且不同的 Node 之间的通信只能通过宿主机的物理网卡进行。将 Pod 的 IP 和所在的 Pod 的 IP 关联起来，通过这个关联让 Pod 可以互相访问

​ Pod1 与 Pod2 在同一台机器，由 Docker0 网桥直接转发请求至 Pod2，不需要经过 Flannel

  • Pod 与 Service 之间的通讯：目前基于性能考虑，全部为 Iptables 维护和转发，新版本已支持lvs转发

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

外网访问 Pod：Service

​