首先来一张简结版的K8s架构图

    接着来一张详细的K8s架构图

    从上面的图可以看出整个K8s集群分为两大部分:

    • K8s控制平面
    • (工作)节点

    让我们具体看下这两个部分做了什么,以及其内部运行的内容又是什么。

    控制平面的组件

    控制平面负责控制并使得整个K8s集群正常运转。 回顾一下,控制平面包含如下组件:

    • ETCD分布式持久化存储 – etcd保存了整个K8s集群的状态;
    • API服务器 – apiserver提供了资源操作的唯一入口,并提供认证、授权、访问控制、API注册和发现等机制;
    • 调度器 – scheduler负责资源的调度,按照预定的调度策略将Pod调度到相应的机器上;
    • 控制器管理器 – controller manager负责维护集群的状态,比如故障检测、自动扩展、滚动更新等;

    这些组件用来存储、管理集群状态,但它们不是运行应用的容器。

    工作节点上运行的组件

    运行容器的任务依赖于每个工作节点上运行的组件:

    • Kubelet – 是 Node 的 agent,负责维护容器的生命周期,同时也负责Volume(CSI)和网络(CNI)的管理;
    • Kubelet服务代理(kube-proxy) – 负责为Service提供cluster内部的服务发现和负载均衡;
    • 容器运行时(Docker、rkt或者其他) – Container runtime负责镜像管理以及Pod和容器的真正运行(CRI);

    附加组件

    除了控制平面(和运行在节点上的组件),还要有几个附加组件,这样才能提供所有之前讨论的功能。包含:

    • K8s DNS服务器 – CoreDNS负责为整个集群提供DNS服务
    • 仪表板(可选) – Dashboard提供GUI,作为高级运维人员,使用kubectl命令行工具管理足矣
    • Ingress控制器 – Ingress Controller为服务提供外网流量入口
    • 容器集群监控 – Metrics-server为K8s资源指标获取工具; Prometheus提供资源监控
    • CNI容器网络接口插件 – calico, flannel(如果没有实施网络策略的需求,那么就直接用flannel,开箱即用;否则就用calico了,但要注意如果网络使用了巨型帧,那么注意calico配置里面的默认值是1440,需要根据实际情况进行修改才能达到最佳性能)

    简单概括

    API服务器只做了存储资源到etcd和通知客户端有变更的工作 调度器则只是给pod分配节点(由kubelet来启动容器) 控制管理器里的控制器始终保持活跃的状态,来确保系统真实状态朝API服务器定义的期望的状态收敛

    Deployment资源提交到API服务器的事件链

    准备包含Deployment清单的YAML文件,通过kubectl提交到Kubernetes。kubectl通过HTTP POST请求发送清单到Kubernetes API服务器。API服务器检查Deployment定义,存储到etcd,返回响应给kubectl,如下图所示:

    文档更新时间: 2021-07-28 16:01   作者:李延召