K8S入门了解 - 技术栈

K8S的入门安装和了解

文章目录

- Kubernetes（K8S）的概念和基本逻辑
- - k8s架构图
  - - 二、结合K8S知识的架构解释
    - - [1. Master节点（控制平面）：集群的"大脑"，负责全局管控](#1. Master节点（控制平面）：集群的“大脑”，负责全局管控)
      - [2. Worker节点：集群的"工作机器"，负责运行容器化应用](#2. Worker节点：集群的“工作机器”，负责运行容器化应用)
    - 三、集群工作逻辑（结合图）
  - K8S工作流程（详细版）
  - 用户访问流程

Kubernetes（K8S）的概念和基本逻辑

K8S是一个资源管理平台，用于管理容器服务器集群，可以运行各种微服务应用、服务和管理系统。K8S还可以实现负载均衡、内外网网关等功能。

K8S：资源管理平台（管理容器服务器集群的一个工具）

Docker主要用于单机多容器管理，而Kubernetes则提供了多节点多容器管理解决方案

容器引擎：docker，containerd

初级版本：

进阶-容器：K8S/再进阶-->云平台：

k8s架构图

这是Kubernetes（K8S）中心化集群架构图 ，核心分为**Master节点（控制平面）和Worker节点（工作节点）**两部分，各组件及标注如下：

Master节点（负责全局管理）
- 管理入口：kubectl（配套auth模块，实现集群操作的认证、鉴权）
- 核心组件：Api-server（集群通信枢纽）、ETCD（标注为"分布式数据库"）、调度、控制器
Worker节点（工作执行节点，示例为worker01、worker02）
- 节点组件：kubelet、kube-proxy（worker01处标注其"负责任务执行、具体工作"，且支持"发布服务给集群外用户访问内部服务"）
- 运行单元：Pod（K8S最小部署单元，每个Worker节点运行多个Pod）

二、结合K8S知识的架构解释

这张图对应K8S的标准集群架构，各组件的K8S核心作用如下：

1. Master节点（控制平面）：集群的"大脑"，负责全局管控

kubectl + auth ：
kubectl是K8S的命令行管理工具（即"管理集群的入口"），管理员通过它向集群发送指令；auth是K8S的认证/鉴权模块，确保只有授权用户能执行操作（比如禁止普通用户删除集群资源）。
Api-server ：

是K8S集群的"通信枢纽"------所有组件（调度器、控制器、Worker节点）的请求都必须经过Api-server转发，同时它也是集群资源操作的唯一入口（比如创建Pod的请求需提交给Api-server）。
ETCD ：

是K8S的分布式键值数据库，负责存储集群的所有状态与配置数据（比如Pod的期望数量、节点信息、Service规则等），是集群的"数据中心"。
调度（对应K8S的kube-scheduler） ：

负责将Pod"调度"到合适的Worker节点（比如根据节点的CPU剩余资源、标签匹配规则，选择最优节点运行Pod）。
控制器（对应K8S的kube-controller-manager） ：

负责维护集群资源的"期望状态"------比如Pod意外停止时，控制器会自动触发重启；Deployment控制器会确保Pod数量始终匹配用户配置的"副本数"。

2. Worker节点：集群的"工作机器"，负责运行容器化应用

kubelet ：

是Worker节点上的"代理组件"，负责与Master的Api-server通信，执行本节点的Pod管理任务（比如创建、启动、监控Pod的运行状态，若Pod异常则向Api-server上报）。
kube-proxy ：

是Worker节点的"网络代理"，核心作用是维护Service的网络规则：
- 实现Pod之间、Pod与集群外的网络通信；
- 提供服务发现与负载均衡（比如将请求分发到Service对应的多个Pod）；
  图中"发布服务给集群外用户"，正是通过kube-proxy配合Service的类型（如NodePort、LoadBalancer），让外部流量能访问集群内的服务。
Pod ：

是K8S中最小的部署单元，一个Pod内可包含一个或多个关联的容器（比如一个Web容器+一个日志收集容器），所有容器共享Pod的网络、存储资源。

三、集群工作逻辑（结合图）

K8S数据流向

1.首先Kubectl通过Auth认证，访问到Master节点的APIserver。

2.APIserver会先将访问数据发送给ETCD存储，相当于将Kubectl发送的请求，例如创建服务的指令形成一个类似与模板的数据，进行存储

3.ETCD会将请求重新发送给APIserver

4.APIserver会先调用controller-manager组件去执行ETCD模板请求，类似与生成一条指令，但是它没有执行的目标

5.controller-manager组件并不能直接在Node节点上创建服务，它会将类似于执行命令的数据发送给APIserver

6.APIserver再将该数据发送到ETCD，ETCD会记录操作请求，而后会将指令需求发送给scheduler组件

7.scheduler组件会kubelet监控，并发送给APIserver的节点信息，而后根据预选、优选策略去选择合适的节点去执行指令，但是它也无法直接将指令发送给kubelet，而是将指令发送给APIserver

8.APIserver将指令发送给kubelet

9.kubelet会在每一个node节点上执行，它将APIserver发送的指令在其所在的node节点上执行，同时它还会负责监控所在节点的Pod实例状态，管理所有Pod实例的生命周期。在执行完指令后，会将执行记录返回给APIserver，APIserver会将记录存储在ETCD当中。并负责与master进行通信。

10.此时用户访问服务，会通过kube-proxy来访问pod实例

注释：

①所有的执行操作与访问数据，都会记录到ETCD当中

②master组件之间并不会互相进行通信与调用，所有的操作都会通过APIserver进行调用执行

当管理员通过kubectl提交"创建Pod"的请求后：

请求经auth认证鉴权后，提交给Api-server；
Api-server将请求信息写入ETCD；
调度器（kube-scheduler）从Api-server获取请求，选择合适的Worker节点；
目标Worker节点的kubelet接收到Api-server的指令，创建并启动Pod；
kube-proxy维护网络规则，确保Pod能被正常访问；
控制器持续监控Pod状态，若Pod异常则自动修复，维持期望状态。

K8S工作流程（详细版）

一些组件的动作：

List-watch机制

list是资源清单

watch是监听机制

监听：events事件

events：ADD、Delete、Update、Modify

调度器、控制器管理中心+kubelet（每个节点）默认会监听Api-server这个接口上的"事件"（6443端口）

创建Pod的工作流程 ：

List-watch机制

1）kubectl创建一个Pod资源（指令/yml文件）

2）通过auth认证鉴权后，到达Api-server

3）Api-server将信息记录到etcd中，etcd会创建一个ADD的事件，并返回给Api-server一个List清单（清单中，会说明需要哪些资源）ETCD会提交一个list清单的ADD事件

4）Scheduler监听到Api-server上的ADD事件后，会触发default-scheduler规则，选择出最适合创建Pod的节点（比如work02），并提交Api-server的list清单中

5）work02的kubelet组件监听到Api-server上的List清单的调度结果后，会触发连接容器运行时的动作，从pull image、create、container、start container

kubectl主要管理的是容器，

6）controlller-manager控制器管理中心，也会监听到api-server上的List清单ADD事件。此时，controller-manager会创建deployment-->创建RS-->RS创建Pod管理lubelet创建的容器

7）后续Pod的状态，容器的探针等均由kubelet来监控、管理汇报给api-server

8）api-server会持续记录在ETCD中

开发者社区版本：

kubectl 创建一个Pod（在提交时，转化为json格式）

首先经过auth认证（鉴权），然后传递给api-server进行处理
api-server 将请求信息提交给etcd
scheduler和controller-manager 会watch（监听） api-server ，监听请求
在scheduler 和controller-manager监听到请求后，scheduler 会提交给api-server一个list清单------》包含的是获取node节点信息
此时api-server就会向etcd获取后端node节点信息，获取到后，被scheduler watch到，然后进行预选优选进行打分，最后将结果给与api-server
此时api-server也会被controller-manager watch（监听） controller-manager会根据请求创建Pod的配置信息（需求什么控制器）将控制器资源给与api-server
此时api-server 会提交list清单给与对应节点的kubelet（代理）
kubelet代理通过K8S与容器的接口（例如containerd）进行交互，假设是docker容器，那么此时kubelet就会通过dockershim 以及runc接口与docker的守护进程docker-server进行交互，来创建对应的容器，再生成对应的Pod
kubelet 同时会借助于metrics server 收集本节点的所有状态信息，然后再提交给api-server
最后api-server会提交list清单给与etcd来存储（最后api-server会将数据维护在etcd中）

用户访问流程

假设用户需创建 nginx资源（网站/调度）kubectl ------》auth ------》api-server
基于yaml 文件的 kubectl create run / apply -f nginx.yaml(pod 一些属性，pod )
请求发送至master 首先需要经过4. 4. apiserver（资源控制请求的唯一入口）
apiserver 接收到请求后首先会先记载在Etcd中
Etcd的数据库根据controllers manager（控制器）查看创建的资源状态（有无状态化）
通过controllers 触发 scheduler (调度器)
scheduler 通过验证算法（）验证架构中的nodes节点，筛选出最适合创建该资源，接着分配给这个节点进行创建
node节点中的kubelet 负责执行master给与的资源请求，根据不同指令，执行不同操作
对外提供服务则由kube-proxy开设对应的规则（代理）
container 容器开始运行（runtime 生命周期开始计算）
外界用户进行访问时，需要经过kube-proxy -》service 访问到container （四层）
如果container 因故障而被销毁了，master节点的controllers 会再次通过scheduler 资源调度通过kubelet再次创建容器，恢复基本条件限制（控制器，维护pod状态、保证期望值-副本数量）
pod ------》ip 进行更改------》service 定义统一入口（固定被访问的ip:端口）