Eli's Blog

1. 架构

Kubernetes特点：

  • 轻量级：消耗资源小
  • 开源
  • 弹性伸缩
  • 负载均衡：IPVS

1.1 核心组件

  • etcd: 保存整个集群的状态

  • apiserver: 资源操作的唯一入口，提供了认证、授权、访问控制、API注册和发现等机制

  • controller manager: 负责维护集群的状态，比如故障检测、自动扩展、滚动更新等

  • scheduler: 负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上

  • kubelet: 负责维护容器的生命周期、Volume(CVI) 和网络(CNI)的管理

  • container runtime: 负责镜像管理以及Pod和容器的真正运行 (CRI)

  • kube-proxy: 负责为Service提供cluster内部的服务发现和负载均衡 （四层）

    • iptables
    • ipvs

etcd: 可信赖的分布式键值对存储服务，为整个分布式集群存储关键数据，协助分布式集群的正常运转。

components

1.2 Add-ons:

  • kube-dns: 负责为整个集群提供DNS服务（CoreDNS, 可以为集群中的SVC创建一个域名IP对应关系解析，即A记录)
  • Ingress Controller: 为服务提供外网入口 （七层代理）
  • Dashboard: 提供GUI
  • Federation: 提供跨可用区的集群
  • Prometheus：监控
  • ELK：集群日志统一分析接入平台

2. Pod

  • 共享存储
  • 共享网络

2.1 Pod 控制器类型

  • RelicationController & ReplicaSet & Deployment

2.1.1 ReplicationController & ReplicaSet & Deployment

  • ReplicationController: 用来确保容器的应用副本数始终是用户定义的副本数。即如果有容器异常退出，会创建新的Pod来代替；如果多出来，自动回收。
  • ReplicaSet: 新版k8s中建议使用ReplicaSet取代RelocationController，它支持集合式selector
  • Deployment: 用来自动管理ReplicaSet。ReplicaSet不支持rolling-update，但Deployment支持。

2.1.2 HPA （HorizontalPodAutoScale)

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

2.1.3 StatefulSet

解决有状态服务的问题（Deployment和ReplicaSet只支持无状态服务），应用场景：

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

2.1.4 DaemonSet

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

一些典型的DaemonSet用法：

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

2.1.5 Job & CronJob

  • Job: 负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个Pod成功结束
  • CronJob：定时Job
    • 在给定时间点运行一次
    • 周期性地在给定时间点运行

2.2 服务发现

Service 通过标签选择到Pod

3. 网络通讯模式

k8s 的网络模型假定了所有Pod都在一个可以直接连通的扁平化网络空间中。在GCE(Google Compute Engine) 里面是现成的网络模型。但在私有云中搭建k8s集群，一般需要我们自己去实现这个扁平化网络模型。

扁平化网络：所有的Pod可以通过IP“直接到达”

3.1 通讯模式

  • 同一个Pod内的多个容器之间：lo
  • 各Pod之间的通信: Overlay Network
  • Pod与Service之间的通讯：各节点的iptables规则

3.2 Flannel

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

etcd为Flannel提供服务：

  • 存储Flannel可分配的IP地址段资源
  • 监控etcd中每个Pod的实际地址，并在内存中创建和维护Pod节点路由表

3.3 总结：不同情况下网络的通信方式

  • 同一个Pod内部通信：共享同一个网络命名空间，共享同一个Linux协议栈。lo网卡
  • Pod1至Pod2:
    • 同一台主机：由Docker0网桥转发，不需要经过Flannel
    • 不同主机：将Pod的IP和Node的IP关联起来，通过这个关联让Pod可以相互访问。涉及网络封包和拆包，较消耗资源。
  • Pod至Service网络：基于性能考虑，全部为iptables/LVS维护和转发
  • Pod到外网：Pod向外网发送请求，查找路由表，转发数据包到宿主机的网卡，宿主机网卡完成路由选择后，iptables执行Masquerade，把源IP更改为宿主网卡的IP，然后向外网服务器发送请求
  • 外网访问Pod：Service

3.4 组件通讯示意图

network

  • 节点网络：物理的网络
  • Pod网络：虚拟网络
  • Service网络：虚拟网络

 上一页