【Kubernetes 笔记】一步一步推导 Kubernetes 核心组件

最新推荐文章于 2024-05-03 01:15:53 发布

一束尘光

最新推荐文章于 2024-05-03 01:15:53 发布

阅读量223

点赞数 1

分类专栏： # Kubernetes 文章标签： kubernetes 云原生

本文链接：https://blog.csdn.net/u013481793/article/details/128385313

版权

Kubernetes 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

引言

Kubernetes，通常简称为 K8s，它是一个开源的容器编排系统。其前身是拥有 15 年生产级别实践经验的 Borg 项目，Google 在 2014 年 9 月将这个项目开源成为 K8s 的第一个版本

在随后的几年，K8s 与 Docker 展开了激烈的容器编排大战。后来 Docker 将 Docker Swarm 内置到了 Docker 中，也就是 Docker 1.12，这引起了行业的不满，反而使得 K8s 社区空前活跃，K8s 很快就大比分胜出，成为云原生时代事实上的基础设施

接下来将介绍 K8s 是什么，并以推导的方式，介绍 K8s 核心概念，以及 K8s 集群架构模型

一、Kubernetes 是什么

K8s 官网链接

K8s 是一款容器编排工具，以服务集群的形式工作，对集群节点上运行的容器进行自动化管理，可以实现应用程序的部署、伸缩、监控等多种需求

K8s 是用 Go 语言开发的，其主要功能如下

服务发现和负载均衡
- 服务可以通过自动发现的形式找到它所依赖的服务
- 如果一个服务启动了多个容器实例，自动实现请求的负载均衡
自动发布和回滚
- 以声明式配置的方式，描述应用程序容器的期望状态，K8s 将以合适的速率调整容器的实际状态，并逐步达到最终期望的状态
- 如果最新发布的程序有故障，可以快速回退到之前的版本
弹性伸缩
- 根据实际需求，对运行中的容器实例数量进行调整
自愈功能
- 重启非正常停机的容器
- 替换、kill 那些不满足自定义健康检查条件的容器
- 在容器就绪之前，避免调用者发现该容器
存储编排
- 根据容器自身的需求，自动创建存储卷

二、推导 Kubernetes 核心概念

K8s 是容器编排工具，那一定会涉及到对容器的操作，现在就从 Docker 容器开始，一步一步推导出 K8s 的一些核心组件

(一) Pod

K8s 不直接操作 Docker 容器，而是对其做了简单的封装，于是有了 K8s 的最小操作单元—— Pod

官方文档

A Pod is a group of one or more containers, with shared storage and network resources, and a specification for how to run the containers

Pod 是一组 container 的集合，共享存储和网络。Pod 的运行状态是由声明式配置文件中的 PodTemplate 描述的，如下图所示

K8s 将 Pod 中的容器分为以下 3 类

初始化容器 / init container
1. 在应用容器启动之前运行，可以配置一个或多个
2. 总是运行到结束状态
3. 如果配置了多个初始化容器，前一个成功结束后，下一个容器才会开始执行
应用容器 / app container
1. 真正用于运行应用程序的容器
2. 不能添加应用容器到运行中的 Pod
临时容器 / ephemeral container
1. K8s v1.25 新增特性
2. 可以添加临时容器到运行中的 Pod 中，用于检查运行状态，通常是 Debug

(二) ReplicaSet

线上环境部署应用程序时，通常会部署多个服务实例。在 K8s 中对应多个副本的组件是 ReplicaSet，它包含一个或多个 Pod

官方文档

A ReplicaSet is defined with fields, including a selector that specifies how to identify Pods it can acquire, a number of replacas indicating how many Pods it should be maintaining, add a pod template specifying the data of new Pods it should create to meet the number of replicas criteria.

ReplicaSet 用来维护一个数量稳定的 Pod 副本集合，ReplicaSet 与 Pod 的关系如下图所示

(三) Deployment

虽然 ReplicaSet 已经可以对 Pod 进行新增、删除等操作了，但 K8s 设计了 Deployment 作为 ReplicaSet 的一个替代项，并推荐始终使用 Deployment，即使只需要一个 Pod

官方文档

A Deployment provides declarative updates for Pods and ReplicaSets.

Deployment 常用于部署无状态服务。Deployment 支持声明式更新 Pod 和 ReplicaSet。使用 Deployment 方式时，仍然会创建 ReplicaSet，但 Deployment 将处理相关细节

(四) Label

当 Pod 数量不断增加时，如果不采取某些措施，K8s 也会难以区分。K8s 设计了 Label，可以将相同或者有关联的 Pod 归集到一起

官方文档

Labels are key/value pairs that are attached to objects, such as pods.

Keep in mind that label Key must be unique for a given object.

K8s 中的 Label 是附加到 K8s 对象上的一组名值对（不仅仅是 Pod），但又不会对 K8s 核心逻辑造成影响

可以在创建 K8s 对象时添加 Label，也可以在对象创建后再添加

Label 的 key 分为两部分：可选前缀 / 标签名

(五) Label Selector

定义了 Label 之后，可以通过 Label Selector 选取那些有关联的 K8s 对象

官方文档

Via a label selector, the client/user can identify a set of objects. The label selector is the core grouping primitive in Kubernetes.

Label Selector 支持 2 种写法

等值标签选择器 / equality-based Selector

environment = production
tier != frontend

集合标签选择器 / set-based Selector

environment in (production, qa)
tier notin (frontend, backend)
# 以下两种写法只根据 Label 的 key 进行选择
partition
!partition

(六) Service

具有相同 Label 的 Pods，可以抽象成 Service，作为对外服务的统一入口

官方文档

An abstract way to expose an application running on a set of Pods as a network service.

Service 与 Pod 的关系如下图所示

(七) Node

有了 Service 以后，还需要启动才能对外提供服务。K8s 最终会将 Pod 运行在 Node 上，Node 可以是物理机，也可以是虚拟机

官方文档

Kubernetes runs your workload by placing containers into Pods to run on Nodes. A node may be a virtual or physical machine, depending on the cluster. Each node is managed by the control plane and contains the services necessary to run Pods.

每个 Node 上都包含可以管理 Pod 的 K8s 基础服务，如下图所示