知识点

Kubernetes: 构建K8S集群
资源清单：掌握资源清单的语法，编写Pod， 掌握Pod的生命周期
Pod控制器：掌握各种控制器的特点及使用定义方式
服务发现：掌握SVC原理及其构建方式
存储：掌握多种存储类型的特点，并且能够在不同环境中选择合适的存储方案（有自己的见解）
调度器：掌握调度器的原理，能够根据要求把Pod定义到想要的节点运行
安全：集群的认证，鉴权，访问孔子，原理及其流程
HLEM：Linux yum 包管理工具。掌握HELM原理，HELM模板 自定义， HEML部署常用一些组件
运维：修改Kubdeadm，达到证书可用期限为10年， 能构建高可用的Kubernetes集群

K8S架构

image.png
APISERVER: 所有服务访问统一入口
CrontrollerManager：维持副本期望数目
Scheduler：负责介绍任务，选择合适的节点进行分配任务
ETCD： 键值对数据库， 存储K8S集群所有的重要信息（持久化）
Kubelet：直接跟容器引擎交互实现容器的生命周期管理
Kub-proxy：负责写入规则至 IPTABLES、IPVS 实现服务映射访问的
CoreDNS：可以为集群中的SVC创建一个域名IP的对应关系解析
DASHBOARD：给 K8S 集群提供一个 B/S 结构访问体系
INGRESS Controller：官方只能实现四层代理， Ingress可以实现七层代理
FEDETATION：提供一个可以跨集群中心多K8S同意管理功能
PROMETHEUS：提供 K8S 集群的监控能力
ELK：提供 K8S 集群日志统一分析介入平台

高可用集群副本数据最好是 >= 3 （奇数）个

Pod

自主式Pod

共享网络，也共享存储

Pod 退出了，此类型的 Pod 不会被创建

控制器管理的Pod

在控制器的生命周期里，始终要维持 Pod 的副本数目

ReplicationController & ReplicaSet & Deployment

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

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

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

HPA

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

StatefulSet

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）

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, Cron Job

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

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

    网络通讯模式

    网络通讯模式 -1

    模式1

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

模式2

同一个Pod内的多个容器之间：Lo
各Pod之间的通讯：Overlay Network
Pod与Service之间的通讯：各节点的Iptables规则

网络解决方案 Kubernetes + Flannel

-1

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

-2

image.png
Flanneld转发方案
image.png

-3

ETCD 之 Flannel 提供说明：

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

不同情况下网络通信方式

同一个Pod内部通讯：同一个Pod共享同一个网络命名空间，共享同一个Linux协议栈

Pod1至Pod2

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

image.png
Pod至Service的网络：目前基于性能考虑，全部为iptables维护和转发（最新版用 LVS 转发，性能更好）

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

外网访问 Pod:Service

组件通讯示意图

image.png
Pod网络、service网络都为虚拟网络