【K8s】概念篇
目录:
集群
比如有三台云主机，每台配置是2核4G，通过安装和配置可以将三台云主机变成一个 K8s 集群，对集群使用者来说好像是拥有了一台机器，这台机器的配置是6核12G。（每台云主机有自己的系统进程，实际使用内存肯定是比12G小的）
好处是比如上海的云主机挂了，K8s 集群会自动调配，将你的应用部署到其它云主机上，保证你的应用不会挂。
节点
集群里每一台机器可以是物理机器，就是你的笔记本电脑，你家台式机，也可以是虚拟机，比如各大云厂商的云主机。
不管是物理机还是虚拟机，集群里的每台机器统称为节点——Node。
Pod
直接以整个节点为单位部署应用会导致资源浪费。例如，一个Web服务仅需1核CPU和2GB内存，如果独占一个2核4G的节点，就会造成资源闲置。K8s 引入了 Pod 作为最小调度和管理单元，完美解决了这个问题。
一个节点上可以创建一个或多个 Pod，每个 Pod 就像一个独立主机，可以为其精确指定所需的 CPU 和内存资源（例如1核2G），集群也会为每个 Pod 分配 IP 地址。
单个Pod的资源请求（requests）和限制（limits）必须能被单个节点满足，因为一个Pod无法被拆分到多个节点上运行。例如，你无法调度一个需要3核CPU的Pod到三台2核的机器上“拼凑”运行。
需要注意的是: 在 K8s 集群中，Pod 的资源总和不能超过单个节点的可分配资源容量。例如，一个由三台2核4G节点组成的集群，其逻辑资源池看似为6核12G，但无法调度一个需要3核6G资源的 Pod 到其中任何一个节点上，因为每个 Pod 都必须完整地运行在单个节点之内，其资源需求必须能被某个节点独立满足。
Deployment
在 K8s 中，Deployment 简化了应用的部署和运维过程。
您需要编写一个 deployment.yaml 配置文件，在文件中定义 Pod 的期望状态: 比如需要用多少资源(如1核2G)，使用什么镜像，占用什么端口等等。
当您使用 kubectl apply -f deployment.yaml 命令应用此配置文件后，K8s 会接管后续所有工作，自动创建 Pod 并保证 Pod 按照配置文件中声明的方式运行。
📌 是不是很简单，你给个清单📁，接下来的事全丢给 K8s。
ReplicaSet
副本集（ReplicaSet）可以理解为 Pod 的“备份”。它的核心作用是确保任何时候都有指定数量的 Pod 在运行。
例如，部署一个 Web 服务时，如果将副本集数量设为 2，K8s 就会创建两个相同的 Pod 来提供服务。如果其中一个 Pod 因为任何原因停止工作，另一个 Pod 仍然可以继续处理请求，从而保证网站不会立刻中断。只有当两个 Pod 同时出问题时，服务才会中断。
副本集的另一个重要好处是能够轻松应对流量变化。平时网站访问量不大时，设置 1 个副本可能就足够了。如果遇到节日等特殊情况，访问量激增，你可以快速将副本集数量调整为 5。Kubernetes 会自动创建新的 Pod，让流量分摊到五个实例上，避免单个 Pod 过载导致网站崩溃。等高峰期过去，再将副本数量调回，这样可以动态地节省资源。
如何指定副本集数量？也是在 deployment.yaml 中声明式定义。
Service
在 K8s 中，每个Pod都会被分配一个唯一的内部 IP 地址，集群内的 Pod 之间可以直接通过 IP 进行通信。例如，一个提供前端服务的 web Pod 可以通过 IP 地址访问另一个提供后端 API 的 api Pod。
然而，Pod 是动态且短暂的。它们可能因为多种原因被销毁并重新创建，例如节点故障、应用扩缩容（上面介绍的副本集数量变化），容器实际使用的资源（如内存）超过其定义的限制（limits）。每次Pod被重新创建后，K8s 会为其分配一个新的 IP 地址。如果客户端（如 web Pod）依赖固定的 Pod IP 地址进行通信，那么后端 Pod 的 IP 变化将导致服务中断。
Service 正是为了解决此问题而设计的核心抽象。
Service 在集群内有固定的 IP 地址（ClusterIP）。客户端（如 web Pod）只需访问该地址，Service 通过标签选择器（selector）与一组功能相同的 Pod （如 api Pod）动态关联。
因此，无论后端的 api Pod 如何被替换或扩容，只要其标签匹配，web Pod 通过 Service 的固定 IP 或 DNS 名称就能持续、稳定地访问到 API 服务。
↶ 返回首页 ↶