01-kubernetes 简介

01-kubernetes 简介

 
重点
  • 先抓住 Kubernetes 的定位：它不是替代容器，而是负责容器化应用的编排、调度、自愈、伸缩和服务发现。
  • 学习主线按“容器基础 -> Pod -> 控制器 -> 网络/存储/安全 -> 交付与运维”推进。
  • 看架构时要分清控制面组件、Node 组件和插件组件的职责边界。

k8s是什么

k8s，全称Kubernetes

k8s是一个跨宿主机管理容器的系统

为何要用k8s

docker是什么?

docker是一个容器引擎，负责基于容器的三大核心技术（名称空间、cgroup、联合文件系统）来创建容器

创建出容器之后的管理工作，容器引擎做的并不完善

比如:

  1. 监控容器的存活状态，挂掉了自动重启
  2. 集群化模式下，把容器调度到最合适的节点上
  3. 容器的跨宿主机网络通信

k8s就是为了解决上述的容器管理问题而生的

云原生：= cloud+Native

cloud

云计算--》资源统一管理形成一个资源池。

  • 关键词：资源池、循环利用

  • 各种云平台

    • 提供虚拟机的平台
    • 容器云平台

Native

  • 应用设计之初就考虑到云环境，或者通过后续的改造
  • 去利用云平台的优良特性，来提升软件的质量（比如故障自愈、资源利用）

云原生总结一句话：软件从诞生之初就是专门为了运行在云平台上的

云原生涉及到的技术

  1. 微服务

  2. Devops

    1. Dev：开发喜欢更新
    2. Op：运维讨厌更新

  3. CICD

    1. gitlab代码仓库-----------jenkins平台（流水线）----》构建得到镜像----》镜像仓库harbor------》目标环境（k8s）

  4. 容器

何时要用k8s

  1. 你们公司的应用是微服务架构的，或者应用数量较多运维成本大的时候也可以用
  2. 开发者需要快速部署自己的新功能到测试环境进行验证
  3. 降低硬件资源成本，提高资源使用率
  4. 容器自动化管理，故障监控与自愈，自动化部署等

什么时候不适合使用 Kubernetes

  1. 应用是轻量级的单体应用，没有高并发的需求
  2. 团队不适应变革

k8s架构、核心概念、组件

k8s是一个主从架构

master节点/主节点（控制平面）：

  1. master节点负责集群的调度、整套k8s集群的维护工作，是k8s集群的总控中心
  2. 高可用集群建议部署至少3台Master
  3. master节点通过与Slave节点不间断通信来维持整个集群的健康状态，集群中各个资源的状态信息存放于etcd中。若master节点不可用，则我们便无法管理k8s集群中的各种资源
  4. Master上部署的组件有apiserver、scheduler、controller-manager等管理组件，此外通常还需要部署etcd

slave节点/从节点/worker节点/node节点 (数据平面)

  1. kubelet会把本节点的资源信息、pod的状态等信息汇报给master的apiserver组件，然后存入etcd中
  2. kubelet会调用容器引擎来创建容器

Slave节点上部署有kubelet、kube-proxy、容器引擎等工作组件。

核心概念与组件

  • 组件：实际存在的软件

  • 资源：组件创建出的逻辑单位，例如namespace、pod、deployment、configmap、statefulset。。。。

资源

namespace名称空间

  1. 名称空间是一门技术，这门技术可以用在不同的地方

  2. 容器中用名称空间技术来隔离：pid、ipc、uts、mount、网络、user

  3. k8s中用名称空间技术来把一系列资源隔离到一起（例如pod、deployment、configmap、statefulset）

  4. k8s引入名称空间技术的好处

    1. 当很多人共用一套k8s集群时，可以用namespace将彼此使用的资源隔离开，互不干扰

    2. 一组资源被组织到一个namespace中后，更方便k8s进行统一性的管理配置，例如资源配额、访问控制等

      1. Resource Quota限定一个名称空间总共能用多少资源
      2. Limit range现在当前名称空间内，每个pod或者容器的最大资源使用量

Pod

pod是什么？

  • pod是一种把相关的容器组织到一起的方式/单位，pod内可以组织一个或多个容器（准确的说一个pod内至少两个容器）
  • pod是k8s的最小工作/调度单位

为何要有POD？

为何要引入POD这种概念来组织一下容器，直接管理容器不好吗？

不好

引入POD的好处

  1. 封装，屏蔽底层容器的差异化

  2. POD内的多个容器共享网络名称空间、共享挂载卷

    1. 所以如果应用由多个容器构成，并且想要实现本地通信，也可能有共享存储的需求

pod的两大特性

  1. pod内的多个容器共享网络（网络来自于pause容器）
  2. pod内的多个容器共享该pod的存储卷

组件

node节点上

容器引擎：略

kubelet

  1. 把本节点的资源信息、pod状态上报给master节点的apiserver然后存入etcd中
  2. 接收来自master的创建pod的请求，然后调用容器引擎以及网络插件把pod创建完成
kubelet对接容器引擎

  1. 在k8s1.24版之前，可以非常方便的对接docker容器引擎

    1. kubelet –> docker shim （在 kubelet 进程中） –> dockerd –> containerd

  2. 在k8s1.24版之后，默认对接的是containerd容器引擎

    1. kubelet –> cri plugin（在 containerd 进程中） –> containerd

  3. kubelet的GC机制会负责定期清理工作节点上的镜像以及退出的容器

对接container的优点
  1. 调用路径更短，效率更高
  2. k8s的kubelet版本更新迭代更便捷，直接对接cri-containerd即可

kube-proxy

强调：kube-proxy不负责pod的网络构建，负责的是pod的负载均衡（智能负载均衡、4层），网络是由网络插件实现的

  • kube-proxy------------------》service资源（智能负载均衡）

service的特点

  1. service与pod的动态关联（挂掉pod自动剔除对其的代理，新pod自动添加对其的代理）：基于标签来选中

    1. 负责维护service状态的组件是kube-proxy

  2. service如何实现流量的负载均衡

    1. 底层基于ipvs（与lvs类似）

master节点

etcd分布式数据

  1. 整个k8s的状态都存在etcd中
  2. etcd是一个分布式kv存储系统，采用RAFT算法，超过半数以上的etcd节点挂掉后整个etcd集群才不可用
  3. 补充：etcd集群的性能决定了集群的规模

apiserver

  • 在k8s中，只有apiserver可以访问操作etcd，其他组件想操作etcd都必须请求apiserver，所以因此apiserver是 整个K8S 集群入口

kube-scheduler

调度组件

创建pod时，scheduler组件会经过两个阶段来完成物理节点的挑选

  1. 预选（选出符合条件的）
  2. 优选（选出资源最优的）

kube-controller-manager组件

controller控制器

  1. 控制器负载管理维护pod的状态，使其始终处于预期的状态，该过程称之为调谐（Reconcile）

  2. 关系如下：

    1. 控制器---------------管理维护-------------pod状态

  3. 控制器优多种：

    1. deployment
    2. replicaset
    3. statefulset
    4. cronjob

  4. 补充：其实不仅仅是pod资源，几乎每一种k8s的资源都有对应的控制器来负载管理维护使其始终处于预期状态，完成自动化管理工作

kube-controller-manager组件

内置的控制器都由该组件管理，控制器管理器与控制器的关系如下

controller-manager------>多种控制器（deployment、statefulset、cronjob等）------> POD

详解：

  • controller-manger会通过apiserver访问etcd，来获取每种控制器的状态
  • 一旦控制器的状态不符合预期，就会根据该控制器的特性，来进行调谐的过程

储备知识：

List-watch机制

k8s中各组件间协同都采用list-watch机制进行通信。

  1. 客户端首先执行一次list操作来初始化资源状态
  2. 然后通过watch操作来持续接收后续的更新

与简单的短轮询相比，这种机制可以更有效地获取资源状态的更新，并减少了网络流量和APIserver服务器的负载。

创建pod的完整流程

0、controller-manager组件、scheduler组件、kubelet组件都watch监听apiserver、监听自己的关注的资源状态  
	只要有更新，apiserver就会上报该更新给对应的组件

1、客户端命令kubectl提交创建pod的请求（该pod的控制器采用Replicaset）

2、apiserver收到该请求，会把创建replicaset的请求写入etcd

3、上报事件replicaset created

4、controller-mamanger收到replicaset created事件，进入调谐阶段  
	controller-mamanger发现当前该pod是0副本，预期要创建1个副本

5、所以controller-mamanger发起要创建一个pod的请求给apiserver

6、apiserver将创建pod的事件存入etcd中

7、apiserver上报Pod created事件

8、scheduler组件收到Pod created事件（因为scheduler一直watch着该资源的变动）

	scheduler经过预选与优选来选出一台合适的物理节点来创建新pod

9、scheduler把调度结果（要在某一台物理节点上创建新pod）发送给apiserver

10、将事件存入etcd中

11、上报该事件

12、某一个物理节点上的kubelet会收到该事件，进入pod创建环节

13、kubelet会调用容器引擎以及网络插件创建出pod

	（1）kubelet会先调用容器引擎创建出一个pause容器  
	（2）然后kubelet会调用网络插件来把pause容器的网络打通  
	（3）kubelet会调用容器引擎来创建出业务容器，并且业务容器采用的container网络模式  
	与pause容器共享网络

	补充：关于kubelet如何对接容器引擎的详细如下  
		如果kubelet对接的docker引擎，对接流程如下

			kubelet –> docker shim （在 kubelet 进程中） –> dockerd –> containerd

		如果kubelet对接的containerd引擎，对接流程如下

			kubelet –> cri plugin（在 containerd 进程中） –> containerd

List-watch的实现

  1. List：短连接（一次通信完成之后tcp链接就断开，适用于访问频率不高）
  2. watch：长连接（一次通信完成之后tcp链接依然保留，适用于短时间内频繁访问）
  3. 组件长时间都处于watch状态，关注实时信息，有可能因为一些网络抖动故障导致watch丢失了某些事件
  4. 组件会定期发情list操作来获取最新的全量状态，弥补watch的不足
posted @ 2026-07-12 14:28  是绘梨衣呀  阅读(3)  评论(0)    收藏  举报