本文是自己的学习笔记

---

1、k8s中的核心概念

1.1、pod

• 容器的集合

Pod是k8s中最小的部署单元。

我们都知道在docker中，一个容器大部分情况下只可以部署一个应用（当然，一个容器部署多应用理论上可行，只是这种情况不多见，也不推荐）。而在k8s中，一个Pod中可以含有一个或多个容器（包括docker容器）。

一个Pod内的容器共享同一个网络。比如某个Pod对外暴露80端口，那该Pod下的所有容器都可以同时监听80端口。对于外部来说，不用在意服务被Pod中具体哪个容器处理，只需要往80端口发送请求即可。这种特性可以让一个Pod看成是一个具有单一职责的集群。比如一个Pod专门处理订单业务，在它之下就有多个容器（或者说机器）作为集群处理订单业务。

• 临时性

Pod被设计时是看成一个临时性资源。

比如一个Pod启动后会被用于处理一个短暂的任务，处理结束后便会被Kubernetes删除，不可恢复。不像容器一样可以反复部署。

这样的特性让Pod被视为一次性资源。如果一个Pod出问题了，那最好的方式是创建一个新的替代，而不是修复。

1.2、Service

概念： Service（服务）是一个抽象层，它定义了访问一组 Pod 的逻辑集合和访问策略。

本质： 解决了 Pod IP 地址不稳定的问题。它为后端的 Pod 提供了一个稳定的、不变的 IP 地址和 DNS 名称。

关键作用：

服务发现： 允许应用通过 Service 的名称（DNS）或 Cluster IP 访问后端 Pod。

负载均衡： 将流量自动分发到 Service 匹配的所有健康 Pod 实例上。

1.3、Controller

Controller负责管理Pod的生命周期，副本数量和期望状态。

它本质上是Controller Manager中的一个或多个控制循环，通过Watch机制监控集群状态确保实际状态符合期望状态。

当一个Pod创建失败后，Controller会创建一个新的取代它。

用户也可以通过Controller方便地对Pod增加或减少副本数量。

1.4、三者之间的关系

• Controller，确Pod的副本数量正确并健康运行。依赖API Service和Controller Manager管理Pod。
• Service，管理Pod的网络服务，为其下的容器提供统一的入口和负载均衡。使用户可以方便地通过Label Selector访问Pod。
• Pod，最小部署单位，可看成是一个集群。

2、k8s系统架构

2.1、架构简介

k8s主要由两个部分组成，master node和worker node。

master node 是流量入口，所有的请求会先到master node，之后才会被分发到worker node。

而worker node是真正处理业务逻辑的节点。

所以master node是一个流量分发器，自然而然也能处理流量控制，请求校验等工作。

2.2、Master node简介

master node有三部分组成，API Server,Scheduler和Controller。还有一个用于存储的etcd

• API server
  用与接受所有的请求并放到etcd中存储。自然也可以处理流量控制，身份验证与授权等工作。

• Scheduler
  主要用于Pod 调度： Scheduler的主要职责是为新创建且尚未分配节点 (Node) 的 Pod 找到一个最合适的节点来运行它们。pod暂时可以理解成一个操作系统，需要到具体的节点上运行。

• Controller
  全称是controller manager，用于处理集群中常规的后台任务，一个资源对应一个controller。比如集群中需要对节点做故障发现和心跳检测，那就会有一个node controller负责这件事；再比如namespace controller负责namespace的生命周期管理。所以controller可以看成是一个后台线程的集合，藏在幕后处理杂务，维持集群的运转。

• etcd用于存储集群中的状态数据

2.3、worker node简介

• kubelet
kubelet是连接master node和worker node之间的代理。它会收集worker node 的状态，确保worker node中的任务顺利执行。然后将状态汇报给master node。

• kube-proxy
  它是网络代理，用来维护worker node的网络，确保worker node中的pod之间和pod和外部能正常沟通。可以用来实现负载均衡

• container-runtime
  用于管理节点中的容器，比如拉取容器镜像，启动容器，隔离资源等。