Kubernetes核心概述

文章目录

• Kubernetes 核心概述
• • Pod 容器组
  • • Pod阶段 phase
    • 容器状态
  • Controller 控制器
  • • Controller 作用
  • Label 标签
  • • 语法和字符集
    • Label Selector
  • Service 服务
  • Endpoints
  • DNS
• Kubernetes核心概念之间的关系
• • Pod与Controller
  • Pod与Label
  • Pod与Service
  • Service与DNS
• 基于kubernetes集群容器化应用的微服务
• • 服务部署方式介绍
  • 微服务架构服务组件（kubernetes核心概念）之间的关系
  • • 从微服务视角看 Kubernetes 核心组件分工

Kubernetes 核心概述

Pod 容器组

Pod是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元

Pod就像是豌豆荚一样，包含着一组（一个或多个）容器（豌豆）

这些容器共享存储，网络，以及怎样运行这些容器的声明

举例说明：

container 容器 —— 一颗豌豆

Pod 容器组 —— 一个豌豆荚

Node 节点 —— 一根碗豆藤

Cluster 集群 —— 一个豌豆园

为了运行Pod，我们需要在每个节点安装容器运行时（runtime（containerd或者cri-docker））

Pod阶段 phase

pod的阶段有哪些呢？

当 Pod 反复启动失败，处于崩溃循环、反复失效，且回退延迟机制仍在生效时，某些 kubectl 命令的 Status 字段中可能会出现 CrashLoopBackOff

当 Pod 被删除时，某些 kubectl 命令的 Status 字段中可能会出现 Terminating

这两个不是阶段phase中的内容，但是会在status字段中出现

Pod 阶段（phase）是 Kubernetes 数据模型和 Pod API 的一个明确的部分

容器状态

Pod中容器的状态有哪些呢？

如果容器配置了 preStop 回调，则该回调会在容器进入 Terminated 状态之前执行

Controller 控制器

在 Kubernetes中，用于管理和运行Pod的对象

在 Kubernetes 中，控制器通过监控集群的公共状态，并致力于将当前状态转变为期望的状态

Controller 作用

可以想象成房间里的温度自动调节器，当你设置了温度，告诉了温度自动调节器你的期望状态(Desired state)。房间的实际温度是当前状态 (Current state)。 通过对设备的开关控制，温度自动调节器让其当前状态接近期望状态

所以，一个控制器至少追踪一种类型的 Kubernetes 资源。这些对象有一个代表期望状态的 spec 字段。 该资源的控制器负责确保其当前状态接近期望状态

不同类型的控制器实现的控制方式不一样，例如：

• deployment
  • 部署无状态应用：认为pod都一样，没有顺序要求，不用考虑在哪个node运行，随意进行扩展和伸缩
  • 管理Pod和 ReplicaSet
  • 部署、滚动升级等
  • 典型的像web服务、分布式服务等
• StatefulSet
  • 部署有状态应用：认为每个Pod都独立运行，保持pod 启动顺序和唯一性；有网络标识符，持久存储，有序（比如mysql的主从），主机名固定
  • 其扩展以及升级等操作也是按顺序进行的操作
• DaemonSet
  • 部署守护进程
  • DaemonSet保证在每个Node上都运行一个容器副本，常用来部署一些集群的日志、监控或者其他系统管理应用。 新加入的node 也同样运行在一个pod 里面
• Job
  • 一次性任务
  • job负责批量处理短暂的一次性任务(short lived one-off tasks)，即仅执行一次的任务，它保证批处理任务的一个或多个Pod成功结束
• Cronjob
  • 周期性定时任务

Label 标签

标签（Labels）是附加到 Kubernetes 对象（比如 Pod）上的键值对。 标签旨在用于指定对用户有意义且相关的对象的标识属性，但不直接对核心系统有语义含义。

一个个Label是一个key=value的键值对，其中key与value由用户自己指定

标签可以用于组织和选择对象的子集。标签可以在创建时附加到对象，随后可以随时添加和修改。 每个对象都可以定义一组键/值标签。每个键对于给定对象必须是唯一的

标签能够支持高效的查询和监听操作，对于用户界面和命令行是很理想的。 应使用注解记录非识别信息（比如自定义的标签，时间、工作环境、用途等）

语法和字符集

Label key：

• 字符数 <= 63
• 可以使用前缀，使用/分隔，前缀必须是DNS子域，字符数 <= 253，系统中的自动化组件创建的label 必须指定前缀，kubernetes.io/ 由kubernetes 保留
• 起始必须时字母（不分大小写）或数字，中间可以有连字符、下划线或点

Label value：

• 字符数 <= 63
• 起始必须时字母（不分大小写）或数字，中间可以有连字符、下划线或点

Label Selector

通过label selector，客户端/用户可以指定一个object集合，通过label selector对object的集合进行操作

Label Selector 由两种类型：

• equality-based（基于等式）：可以使用=，==，!= 来检索标签
• set-based（基于集合）：可以使用 in，notin，! 来检索标签

Service 服务

将运行在一组 Pods上的应用程序公开为网络服务的抽象方法

由于Pod是非永久性资源对象，如果使用Controller运行应用程序，可以动态创建和销毁Pod，这样就会导致无法准确访问到所想要访问的Pod

这就带来了一个问题：如果某组 Pod（称为“后端”）为集群内的其他 Pod（称为“前端”） 集合提供功能，前端要如何发现并跟踪要连接的 IP 地址，以便其使用负载的后端组件呢？

是一组iptables或ipvs规划，通过把客户端的请求转发到服务端(Pod),如有多个Pod情况，亦可实现负载均衡的效果

例如，考虑一个无状态的图像处理后端，其中运行 3 个副本（Replicas）。 这些副本是可互换的 —— 前端不需要关心它们调用的是哪个后端。 即便构成后端集合的实际 Pod 可能会发生变化，前端客户端不应该也没必要知道这些， 而且它们也不必亲自跟踪后端的状态变化

所以，将在集群中运行的应用通过同一个面向外界的端点公开出去，即使工作负载分散于多个后端也完全可行

Endpoints

为Service管理后端Pod，当后端Pod被创建或销毁时，endpoints列表会更新Pod对应的IP地址，以便 Service访问请求能够确保被响应

DNS

为kubernetes集群内资源对象的访问提供名称解析，这样就可以实现通过DNS名称而非IP地址来访问服务：

• 实现集群内 Service 名称解析
• 实现集群内 Pod 内 Container 中应用访问互联网提供域名解析

Kubernetes核心概念之间的关系

Pod与Controller

pod 是通过Controller 实现应用的运维，比如伸缩，滚动升级等待。pod和 controller 通过label 标签建立关系

案例：删除其中一个pod，查看controller 自动创建新的pod

[root@master ~ 13:20:04]# kubectl get replicasets
NAME DESIRED CURRENT READY AGE
tomcat-test-75469fdc74 2 2 0 11s

[root@master ~ 13:20:15]# kubectl get pods
NAME READY STATUS RESTARTS AGE
tomcat-test-75469fdc74-jm5j7 1/1 Running 0 7s
tomcat-test-75469fdc74-m47kg 1/1 Running 0 7s

# 测试删除pod
[root@master ~ 13:25:51]# kubectl delete pod tomcat-test-75469fdc74-jm5j7
pod "tomcat-test-75469fdc74-jm5j7" deleted

# 快速自动生成新的pod
[root@master ~ 13:26:26]# kubectl get pods
NAME READY STATUS RESTARTS AGE
tomcat-test-75469fdc74-552sv 1/1 Running 0 5s
tomcat-test-75469fdc74-m47kg 1/1 Running 0 46s

Pod与Label

查看控制器管理的标签Selector

[root@master ~ 13:26:30]# kubectl describe replicasets tomcat-test-75469fdc74
Name: tomcat-test-75469fdc74
Namespace: default
Selector: app=tomcat,pod-template-hash=75469fdc74# 对应
Labels: app=tomcat
pod-template-hash=75469fdc74
Annotations: deployment.kubernetes.io/desired-replicas: 2
deployment.kubernetes.io/max-replicas: 3
deployment.kubernetes.io/revision: 1
Controlled By: Deployment/tomcat-test
Replicas: 2 current / 2 desired
Pods Status: 2 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
Labels: app=tomcat
pod-template-hash=75469fdc74
Containers:
tomcat:
Image: tomcat:9.0.85-jdk11
Port: 8080/TCP
Host Port: 0/TCP
Environment: <none>
Mounts:
/usr/local/tomcat/webapps/ROOT/index.html from web-content (rw,path="index.html")
Volumes:
web-content:
Type: ConfigMap (a volume populated by a ConfigMap)
Name: tomcat-web-content
Optional: false
Events:
Type Reason Age From Message
—- —— —- —- ——-
Normal SuccessfulCreate 113s replicaset-controller Created pod: tomcat-test-75469fdc74-m47kg
Normal SuccessfulCreate 113s replicaset-controller Created pod: tomcat-test-75469fdc74-jm5j7
Normal SuccessfulCreate 72s replicaset-controller Created pod: tomcat-test-75469fdc74-552sv

对应上的pod标签就能进行有效管理

[root@master ~ 13:28:35]# kubectl describe pod tomcat-test-75469fdc74
Name: tomcat-test-75469fdc74-552sv
Namespace: default
Priority: 0
Service Account: default
Node: node2/192.168.108.136
Start Time: Mon, 19 Jan 2026 13:26:25 +0800
Labels: app=tomcat# 对应
pod-template-hash=75469fdc74
Annotations: cni.projectcalico.org/containerID: d43e634f9dd96696c9a3c3d9a5a79485a8e87d7cf51ebde7638f3ed110352119
cni.projectcalico.org/podIP: 10.244.104.16/32
cni.projectcalico.org/podIPs: 10.244.104.16/32
Status: Running
IP: 10.244.104.16
IPs:
IP: 10.244.104.16
Controlled By: ReplicaSet/tomcat-test-75469fdc74
Containers:
tomcat:
Container ID: docker://b16a67d47113d033d9887acc016a59d0d769299b6a733cc68ebfd5961c951d5c
Image: tomcat:9.0.85-jdk11
Image ID: docker-pullable://tomcat@sha256:b2a4b6f5e09e147ee81f094051cb43d69efd56a68e76ca5b450b7584c5564c77
Port: 8080/TCP
Host Port: 0/TCP
State: Running
Started: Mon, 19 Jan 2026 13:26:26 +0800
Ready: True
Restart Count: 0
Environment: <none>

Pod与Service

service 是为了防止pod 失联，提供的服务发现，类似于微服务的注册中心。定义一组pod 的访问策略。可以为一组具有相同功能的容器应用提供一个统一的入口地址，并将请求负载分发到后端的各个容器应用上

service 通过selector 来管控对应的pod。根据label和selector 建立关联，通过service 实现 pod 的负载均衡

查看所有service

[root@master ~ 14:04:38]# kubectl get service
# service可以简写成svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 5d
tomcat-service NodePort 10.105.132.137 <none> 80:30080/TCP 39m

查看指定tomcat-service的service

[root@master ~ 16:54:31]# kubectl describe service tomcat-service
Name: tomcat-service
Namespace: default
Labels: <none>
Annotations: <none>
Selector: app=tomcat# 对应标签
Type: NodePort
IP Family Policy: SingleStack
IP Families: IPv4
IP: 10.105.172.100
IPs: 10.105.172.100
Port: <unset> 80/TCP
TargetPort: 8080/TCP
NodePort: <unset> 30080/TCP
Endpoints: 10.244.104.38:8080,10.244.166.181:8080
Session Affinity: None
External Traffic Policy: Cluster
Events: <none>

查看endpoints

[root@master ~ 17:07:33]# kubectl get endpoints
NAME ENDPOINTS AGE
kubernetes 192.168.108.128:6443 6d3h
tomcat-service 10.244.104.38:8080,10.244.166.181:8080 13m# 对应两个podIP，pod重启会引起IP变化，会被重新添加到此处

Service与DNS

通过DNS实现对Service名称解析，以此达到访问后端Pod的目的

查看DNS的pod

[root@master ~ 17:10:15]# kubectl get pods -n kube-system | grep dns
coredns-66f779496c-nzpjw 1/1 Running 1 (6d2h ago) 6d3h
coredns-66f779496c-wzrkp 1/1 Running 1 (6d2h ago) 6d3h

查看service获取集群IP，DNS的地址为10.96.0.10

[root@master ~ 17:10:27]# kubectl get service -n kube-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP,9153/TCP 6d3h
metrics-server ClusterIP 10.99.68.52 <none> 443/TCP 5d

查看DNS对应的pod地址

[root@master ~ 17:13:49]# kubectl get endpoints -n kube-system
NAME ENDPOINTS AGE
kube-dns 10.244.219.69:53,10.244.219.70:53,10.244.219.69:53 + 3 more... 6d3h
metrics-server 10.244.104.8:10250 5d

# 或者
[root@master ~ 17:15:30]# kubectl get pod -n kube-system -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
calico-kube-controllers-658d97c59c-dnj7l 1/1 Running 1 (6d3h ago) 6d3h 10.244.219.68 master <none> <none>
calico-node-kbhrw 1/1 Running 0 3h14m 192.168.108.128 master <none> <none>
calico-node-kw4fd 1/1 Running 0 3h14m 192.168.108.136 node2 <none> <none>
calico-node-tj7hq 1/1 Running 0 3h13m 192.168.108.129 node1 <none> <none>
coredns-66f779496c-nzpjw 1/1 Running 1 (6d3h ago) 6d3h 10.244.219.70 master <none> <none>
coredns-66f779496c-wzrkp 1/1 Running 1 (6d3h ago) 6d3h 10.244.219.69 master <none> <none>
etcd-master 1/1 Running 2 (6d3h ago) 6d3h 192.168.108.128 master <none> <none>
kube-apiserver-master 1/1 Running 4 (6d3h ago) 6d3h 192.168.108.128 master <none> <none>
kube-controller-manager-master 1/1 Running 2 (6d3h ago) 6d3h 192.168.108.128 master <none> <none>
kube-proxy-qjz9p 1/1 Running 1 (6d3h ago) 6d3h 192.168.108.136 node2 <none> <none>
kube-proxy-stz98 1/1 Running 2 (6d3h ago) 6d3h 192.168.108.128 master <none> <none>
kube-proxy-tzsgh 1/1 Running 1 (6d3h ago) 6d3h 192.168.108.129 node1 <none> <none>
kube-scheduler-master 1/1 Running 2 (6d3h ago) 6d3h 192.168.108.128 master <none> <none>
metrics-server-57999c5cf7-56szn 1/1 Running 0 5d 10.244.104.8 node2 <none> <none>

使用DNS解析tomcat-service

[root@master ~ 17:25:50]# dig -t a tomcat-service.default.svc.cluster.local. @10.96.0.10

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.16 <<>> -t a tomcat-service.default.svc.cluster.local. @10.96.0.10
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; –>>HEADER<<- opcode: QUERY, status: NOERROR, id: 58703
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;tomcat-service.default.svc.cluster.local. IN A

;; ANSWER SECTION:
tomcat-service.default.svc.cluster.local. 30 INA 10.105.172.100# 返回解析地址

;; Query time: 2 msec
;; SERVER: 10.96.0.10#53(10.96.0.10)
;; WHEN: 二 1月 20 17:25:54 CST 2026
;; MSG SIZE rcvd: 125

检验地址对应

[root@master ~ 17:28:48]# kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 6d4h
tomcat-service NodePort 10.105.172.100 <none> 80:30080/TCP 34m# 验证地址对应

基于kubernetes集群容器化应用的微服务

服务部署方式介绍

• 单体服务架构
  • 所有服务进程运行在同一台主机内
• 分布式服务架构
  • 服务进程分布于不同的主机，其中一台主机出现故障，不影响其它主机上的服务运行
• 微服务架构
  • 使用容器化技术把分布式服务架构运行起来，并实现对不同的服务进程的高可用及快速发布等

微服务架构服务组件（kubernetes核心概念）之间的关系

在基于 Kubernetes 的微服务架构中，每一个微服务通常以 Pod 作为最小运行单元，并由不同类型的 Controller 负责其生命周期管理，而 Service、Endpoints 与 DNS 则共同构成了微服务之间通信与服务发现的基础设施

从微服务视角看 Kubernetes 核心组件分工

总的来说，Kubernetes 通过 Pod 承载微服务实例，通过 Controller 保证服务稳定运行，通过 Label 建立资源关系，通过 Service + Endpoints + DNS 实现微服务之间的解耦通信，共同构成了一套完整、自动化、可扩展的微服务运行平台