Kubernetes学习实践(三) -- 关键组件操作实践
进一步对K8s关键组件进行操作实践
1. 引言
通过前面对K8s的环境搭建和Redis环境的部署,已经有一些实践经验了。下面继续对环境中的组件进行操作实践,并简要对比代码,进一步了解K8s各个组件的功能和相关实现。
从 kubernetes github 中 fork 相应代码进行学习,并切换到与当前环境一致的分支:release-1.33
。
2. 集群中运行的几个容器
crictl ps
先查看当前运行的几个容器,可看到K8s集群的几个关键组件:kube-proxy
、kube-controller-manager
、coredns
、etcd
、kube-scheduler
、kube-apiserver
。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
# 省略了部分列
[root@xdlinux ➜ ~ ]$ crictl ps
CONTAINER IMAGE STATE NAME POD NAMESPACE
2fc197c519935 9b38108e295d1 Running redis redis-2 default
f87801fdfefbc 9b38108e295d1 Running redis redis-1 default
558d59adb947c 9b38108e295d1 Running redis redis-0 default
f51fbab3eb587 af855adae7960 Running kube-proxy kube-proxy-6ptwm kube-system
0da3e07a247f2 1cf5f116067c6 Running coredns coredns-757cc6c8f8-v2mgf kube-system
15bd1f6bc3a7f 1cf5f116067c6 Running coredns coredns-757cc6c8f8-nxw7g kube-system
f6f4852a86c52 bf97fadcef430 Running kube-controller-manager kube-controller-manager-xdlinux kube-system
695cfc514a5ff 499038711c081 Running etcd etcd-xdlinux kube-system
c5b9e0185069d 41376797d5122 Running kube-scheduler kube-scheduler-xdlinux kube-system
9ffc7318407b7 a92b4b92a9916 Running kube-apiserver kube-apiserver-xdlinux kube-system
# 可以看下所有namespace下的pod(`--all-namespaces`参数,也可以简写为`-A`,即:`kubectl get pod -A`)
# `-n kube-system` 指定对应namespace下的pod(不指定则默认只显示default下的pod)
[root@xdlinux ➜ ~ ]$ kubectl get pod --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
default redis-0 1/1 Running 0 4d21h
default redis-1 1/1 Running 0 4d21h
default redis-2 1/1 Running 0 4d21h
kube-system coredns-757cc6c8f8-nxw7g 1/1 Running 0 11d
kube-system coredns-757cc6c8f8-v2mgf 1/1 Running 0 11d
kube-system etcd-xdlinux 1/1 Running 2 11d
kube-system kube-apiserver-xdlinux 1/1 Running 2 11d
kube-system kube-controller-manager-xdlinux 1/1 Running 0 11d
kube-system kube-proxy-6ptwm 1/1 Running 0 4d23h
kube-system kube-scheduler-xdlinux 1/1 Running 2 11d
# 查看所有namespace:
[root@xdlinux ➜ ~ ]$ kubectl get namespaces
NAME STATUS AGE
default Active 11d
kube-node-lease Active 11d
kube-public Active 11d
kube-system Active 11d
下面对各个组件进行操作说明。
3. 查看kube-apiserver处理过程
第一篇总体介绍中提到,kube-apiserver
提供HTTP API服务,并负责处理接收到的请求,是K8s控制平面的核心,并且kubectl
的操作也是通过调用API来完成的。
可以在执行kubectl
时,通过-v 8
来查看调用API的详细信息。
-v / --v
用于指定详细级别,部分级别说明如下:6
– HTTP请求路径 + 响应状态码8
– 完整请求和响应
3.1. kubectl version过程
以kubectl version
查看版本为例:可看到会先加载/etc/kubernetes/admin.conf
配置文件进行认证
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
[root@xdlinux ➜ ~ ]$ kubectl version -v 8
I0729 21:45:30.645383 778204 loader.go:402] Config loaded from file: /etc/kubernetes/admin.conf
I0729 21:45:30.645608 778204 envvar.go:172] "Feature gate default state" feature="ClientsAllowCBOR" enabled=false
I0729 21:45:30.645619 778204 envvar.go:172] "Feature gate default state" feature="ClientsPreferCBOR" enabled=false
I0729 21:45:30.645625 778204 envvar.go:172] "Feature gate default state" feature="InformerResourceVersion" enabled=false
I0729 21:45:30.645631 778204 envvar.go:172] "Feature gate default state" feature="InOrderInformers" enabled=true
I0729 21:45:30.645636 778204 envvar.go:172] "Feature gate default state" feature="WatchListClient" enabled=false
I0729 21:45:30.645665 778204 discovery_client.go:657] "Request Body" body=""
I0729 21:45:30.645718 778204 round_trippers.go:527] "Request" verb="GET" url="https://192.168.1.150:6443/version?timeout=32s" headers=<
Accept: application/json, */*
User-Agent: kubectl/v1.33.3 (linux/amd64) kubernetes/80779bd
>
I0729 21:45:30.649450 778204 round_trippers.go:632] "Response" status="200 OK" headers=<
Audit-Id: ea53bfd7-8bd4-4cbc-9354-e3cbc656c712
Cache-Control: no-cache, private
Content-Length: 379
Content-Type: application/json
Date: Tue, 29 Jul 2025 13:45:30 GMT
X-Kubernetes-Pf-Flowschema-Uid: a85b9af0-4d2d-493d-8ebf-b43193f9dd31
X-Kubernetes-Pf-Prioritylevel-Uid: bb92ee23-b810-4c85-9fbc-b3c9f72105d2
> milliseconds=3
I0729 21:45:30.649617 778204 discovery_client.go:657] "Response Body" body=<
{
"major": "1",
"minor": "33",
"emulationMajor": "1",
"emulationMinor": "33",
"minCompatibilityMajor": "1",
"minCompatibilityMinor": "32",
"gitVersion": "v1.33.3",
"gitCommit": "80779bd6ff08b451e1c165a338a7b69351e9b0b8",
"gitTreeState": "clean",
"buildDate": "2025-07-15T17:59:42Z",
"goVersion": "go1.24.4",
"compiler": "gc",
"platform": "linux/amd64"
}
>
Client Version: v1.33.3
Kustomize Version: v5.6.0
Server Version: v1.33.3
调用的是https://192.168.1.150:6443/version
的GET
接口(需要鉴权的命令则会报错无权限)
- 1)可在浏览器里直接请求
https://192.168.1.150:6443/version?timeout=32s
,会返回结果信息 - 2)也可用
curl
进行如下请求:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
[root@xdlinux ➜ ~ ]$ curl -k https://192.168.1.150:6443/version\?timeout\=32s
{
"major": "1",
"minor": "33",
"emulationMajor": "1",
"emulationMinor": "33",
"minCompatibilityMajor": "1",
"minCompatibilityMinor": "32",
"gitVersion": "v1.33.3",
"gitCommit": "80779bd6ff08b451e1c165a338a7b69351e9b0b8",
"gitTreeState": "clean",
"buildDate": "2025-07-15T17:59:42Z",
"goVersion": "go1.24.4",
"compiler": "gc",
"platform": "linux/amd64"
}
3.2. /etc/kubernetes/admin.conf 配置文件说明
上述kubectl
执行时,可看到会先加载/etc/kubernetes/admin.conf
配置文件进行认证。
admin.conf
是一个YAML
格式的kubeconfig文件,该文件记录集群管理员的认证信息和API服务器地址kubeadm init
初始化集群时会自动生成该配置文件
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
[root@xdlinux ➜ ~ ]$ cat /etc/kubernetes/admin.conf
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: xxx (Base64编码的CA证书)
server: https://192.168.1.150:6443 (API服务器地址)
name: kubernetes
contexts:
- context:
cluster: kubernetes
user: kubernetes-admin
name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
user:
client-certificate-data: xxxxx (Base64编码的客户端证书)
client-key-data: xxxxxx (Base64编码的客户端私钥)
上述配置文件的加载逻辑实现在:kubernetes/staging/src/k8s.io/client-go/tools/clientcmd/loader.go
1
2
3
4
5
6
7
8
9
10
11
// kubernetes/staging/src/k8s.io/client-go/tools/clientcmd/loader.go
func LoadFromFile(filename string) (*clientcmdapi.Config, error) {
kubeconfigBytes, err := os.ReadFile(filename)
if err != nil {
return nil, err
}
config, err := Load(kubeconfigBytes)
if err != nil {
return nil, err
}
}
对应的配置结构如下,可以和配置文件的YAML
格式一一对应:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// kubernetes/staging/src/k8s.io/client-go/tools/clientcmd/api/types.go
type Config struct {
Kind string `json:"kind,omitempty"`
APIVersion string `json:"apiVersion,omitempty"`
// Preferences holds general information to be use for cli interactions
Preferences Preferences `json:"preferences"`
// Clusters is a map of referencable names to cluster configs
Clusters map[string]*Cluster `json:"clusters"`
// AuthInfos is a map of referencable names to user configs
AuthInfos map[string]*AuthInfo `json:"users"`
// Contexts is a map of referencable names to context configs
Contexts map[string]*Context `json:"contexts"`
// CurrentContext is the name of the context that you would like to use by default
CurrentContext string `json:"current-context"`
// Extensions holds additional information. This is useful for extenders so that reads and writes don't clobber unknown fields
// +optional
Extensions map[string]runtime.Object `json:"extensions,omitempty"`
}
除此之外,/etc/kubernetes/
下面的其他几个配置文件(如kubelet.conf
),也是通过上面的结构体所定义的,查看里面可看到相同的YAML结构。
1
2
3
4
5
6
7
8
9
[root@xdlinux ➜ ~ ]$ ll /etc/kubernetes/
total 40K
-rw------- 1 root root 5.6K Jul 21 07:47 admin.conf
-rw------- 1 root root 5.6K Jul 21 07:47 controller-manager.conf
-rw------- 1 root root 2.0K Jul 21 07:47 kubelet.conf
drwxr-xr-x 2 root root 113 Jul 22 22:20 manifests
drwxr-xr-x 3 root root 4.0K Jul 21 07:47 pki
-rw------- 1 root root 5.5K Jul 21 07:47 scheduler.conf
-rw------- 1 root root 5.6K Jul 21 07:47 super-admin.conf
3.3. kubectl proxy绕过认证(Authentication)
kubectl get pods -v 8
可看到对应的请求为 Request" verb="GET" url="https://192.168.1.150:6443/api/v1/namespaces/default/pods?limit=500"
。
下面通过curl -k
调用GET
请求,发现-k
忽略掉认证过程的curl被判定为system:anonymous
用户,而此用户没有list pods
的权限,所以报错了。
1
2
3
4
5
6
7
8
9
10
11
12
13
[root@xdlinux ➜ ~ ]$ curl -k https://192.168.1.150:6443/api/v1/namespaces/default/pods\?limit\=500
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {},
"status": "Failure",
"message": "pods is forbidden: User \"system:anonymous\" cannot list resource \"pods\" in API group \"\" in the namespace \"default\"",
"reason": "Forbidden",
"details": {
"kind": "pods"
},
"code": 403
}
可以通过kubectl proxy
在本地和集群之间创建一个代理:
1
2
3
4
5
# 会阻塞等待请求,也可加&在后台运行
[root@xdlinux ➜ ~ ]$ kubectl proxy -v8
I0729 23:23:16.454401 783638 loader.go:402] Config loaded from file: /etc/kubernetes/admin.conf
Starting to serve on 127.0.0.1:8001
而后向127.0.0.1
的8001
端口发送HTTP
(而非HTTPS
)请求:
- 注意,
192.168.1.150
则不行 - 上面的
kubectl proxy
会使用/etc/kubernetes/admin.conf
配置文件
1
2
3
4
5
6
7
8
9
10
11
12
[root@xdlinux ➜ ~ ]$ curl http://127.0.0.1:8001/api/v1/namespaces/default/pods\?limit\=500
{
"kind": "PodList",
"apiVersion": "v1",
"metadata": {
"resourceVersion": "987772"
},
"items": [
...
]
...
}
4. etcd操作和K8s中的应用
etcd是一个高可用的分布式键值存储系统(键值数据库),存储K8s中的关键配置、所有状态信息等,是K8s集群的核心存储组件。
etcdctl
是官方命令行客户端工具,用于与etcd集群交互,执行键值存储操作、集群管理和监控等任务。
在K8s中,只有API Server(kube-apiserver)
会直接与etcd交互,其他组件(如Controller Manager
、Kubelet
、Scheduler
等)均通过API Server
提供的 REST API 间接操作数据。
4.1. 进入etcd pod
本地实验环境中只部署了一个etcd实例,根据上面kubectl get pods -A
显示的pod,选择进入etcd
对应的pod:etcd-xdlinux
。
- 当前基础镜像(取决于不同镜像的配置)对应的
etcd
pod里只安装了sh
,没安装bash
,所以下面--
后面使用sh
1
2
[root@xdlinux ➜ ~ ]$ kubectl -n kube-system exec -it etcd-xdlinux -- sh
sh-5.2#
而后就可以在容器里通过etcdctl
进行etcd相关操作了:
- etcd启用了严格的安全认证机制,且需要明确操作的目标集群,需要通过参数指定这些信息
--endpoints
:指定操作的etcd节点地址,如果不指定,etcdctl
会使用默认值(http://127.0.0.1:2379)- 证书参数
--cacert
:CA 根证书路径,用于验证etcd服务器的身份(确保连接的是真实的 etcd 节点,而非伪造的恶意节点)--cert
和--key
:客户端证书和私钥,用于向etcd服务器证明自己的身份(etcd 会验证客户端是否有权限操作数据)- 这些证书在 Kubernetes 集群中通常存放在
/etc/kubernetes/pki/etcd/
目录下,路径是固定的(由 kubeadm 等工具自动生成)。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# 命令
sh-5.2# etcdctl member list \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key
# 结果
bff3f519f190640f, started, xdlinux, https://192.168.1.150:2380, https://192.168.1.150:2379, false
# etcd的版本
sh-5.2# etcdctl version \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key
etcdctl version: 3.5.21
API version: 3.5
小技巧:在etcd Pod内执行export来设置相关环境变量
1
2
3
4
5
export ETCDCTL_API=3
export ETCDCTL_ENDPOINTS=https://127.0.0.1:2379
export ETCDCTL_CACERT=/etc/kubernetes/pki/etcd/ca.crt
export ETCDCTL_CERT=/etc/kubernetes/pki/etcd/server.crt
export ETCDCTL_KEY=/etc/kubernetes/pki/etcd/server.key
4.2. 基本增删改查
设置上述环境变量后,就能省略上述参数来执行基本增删改查命令了:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# 1、增和改:put
sh-5.2# etcdctl put xdkey1 111
OK
# 2、查:get
sh-5.2# etcdctl get xdkey1
xdkey1
111
# 3、删:del
sh-5.2# etcdctl del xdkey1
1
sh-5.2# etcdctl get xdkey1
sh-5.2#
# 4、观察监测更新:watch
sh-5.2# etcdctl watch xdkey1
# (上面阻塞会等待监测结果,在另一个窗口操作 etcdctl put xdkey1 ttt)
PUT
xdkey1
tttt
另外还支持分布式锁、租约等。
4.3. etcd中存储的K8s信息
K8s存储格式说明:
- K8s在etcd中以键值对(Key-Value)形式存储数据,键的结构与 K8s API 路径高度一致,便于按资源类型、命名空间等维度组织和查询。
- 键(key)格式:类似文件系统的分层路径结构,格式为
/registry/<资源类型>/<命名空间>/<资源名称>
- 比如:
etcdctl get /registry/pods/default/redis-1
- 比如:
- 值(Value)格式:值是经过Protocol Buffers(
protobuf
)序列化的 K8s API 对象,相对于Json更紧凑、序列化效率更高
相关信息查看:
- 查看所有资源的键(简要概览)
- Kubernetes 资源在 etcd 中的根路径是
/registry
,查看所有键的列表
- Kubernetes 资源在 etcd 中的根路径是
1
2
3
4
5
6
# 只显示值,只看键名(避免输出过多)
sh-5.2# etcdctl get /registry --prefix --keys-only
/registry/apiregistration.k8s.io/apiservices/v1.
/registry/apiregistration.k8s.io/apiservices/v1.admissionregistration.k8s.io
/registry/apiregistration.k8s.io/apiservices/v1.apiextensions.k8s.io
...
- 也可进一步过滤
pods
/services
/deployments
/nodes
/namespace
信息
比如路径前缀:/registry/namespaces
1
2
3
4
5
sh-5.2# etcdctl get /registry/namespaces --prefix --keys-only
/registry/namespaces/default
/registry/namespaces/kube-node-lease
/registry/namespaces/kube-public
/registry/namespaces/kube-system
- 查看集群成员信息,常用于检查etcd集群的节点状态和成员健康情况:
etcdctl member list
1
2
3
sh-5.2# etcdctl member list
# 成员ID 状态 成员名称 Peer通信地址(etcd之间同步数据地址) 客户端通信地址 是否为learner(是则仅同步数据,无投票权)
bff3f519f190640f, started, xdlinux, https://192.168.1.150:2380, https://192.168.1.150:2379, false
4.4. 基于etcd的K8s核心功能说明
K8s很多核心功能依赖etcd的原生特性实现。
1、实时状态同步(Watch 机制)
etcd 提供 Watch API,支持监听某个键或前缀的变化(创建、更新、删除)。K8s各组件通过该机制实现实时状态同步:
Controller Manager
:通过 Watch 监听特定资源(如 Deployment)的变化,触发控制逻辑(如创建 / 删除 Pod)- 示例:当
Deployment
资源被更新时,etcd通知apiserver
,apiserver
再通过Watch
机制通知Controller Manager
,后者根据新的 replicas 数量调整 Pod 副本数。
- 示例:当
Kubelet
:Watch 本节点上的 Pod 变化,执行启动、停止容器等操作Scheduler
:Watch 未调度的 Pod,触发调度逻辑
2、分布式一致性,etcd基于Raft
算法保证数据强一致性,确保所有节点看到的集群状态是一致的,当控制平面高可用部署多个实例时保证数据读写一致。
3、事务与原子操作
etcd 支持基于条件的事务(Transaction
)操作,K8s 利用这一特性实现并发安全的操作。
5. kube-controller-manager
K8s的Controller Manager
通过kube-apiserver
提供的信息持续的监控集群状态,并尝试将集群调整至预期的状态。
5.1. 相应的pod信息
先describe查看下kube-controller-manager
这个pod的信息,截取部分:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
[root@xdlinux ➜ ~ ]$ kubectl -n kube-system describe pod kube-controller-manager
Name: kube-controller-manager-xdlinux
Namespace: kube-system
Priority: 2000001000
Priority Class Name: system-node-critical
Node: xdlinux/192.168.1.150
...
Containers:
kube-controller-manager:
Container ID: containerd://f6f4852a86c52bc368ad5c9ca4802782667b318d9835c1e03b6acbb2992cce6d
# 容器镜像
Image: registry.aliyuncs.com/google_containers/kube-controller-manager:v1.33.3
...
Requests:
cpu: 200m
# 健康检查接口,可手动curl -k调用检查
Liveness: http-get https://127.0.0.1:10257/healthz delay=10s timeout=15s period=10s #success=1 #failure=8
Startup: http-get https://127.0.0.1:10257/healthz delay=10s timeout=15s period=10s #success=1 #failure=24
...
5.2. 简单观察Controller Manager
1、之前的redis创建了3副本,信息如下
1
2
3
4
5
6
7
8
9
10
11
12
13
[root@xdlinux ➜ ~ ]$ kubectl get all
NAME READY STATUS RESTARTS AGE
pod/redis-0 1/1 Running 0 5d
pod/redis-1 1/1 Running 0 5d
pod/redis-2 1/1 Running 0 5d
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 11d
service/redis-headless ClusterIP None <none> 6379/TCP 5d
service/redis-service NodePort 10.107.73.216 <none> 6379:30000/TCP 5d
NAME READY AGE
statefulset.apps/redis 3/3 5d
2、删除其中一个redis pod,如pod/redis-1
,查看信息,可看到立即就创建了一个新的pod(AGE
处为2s)
1
2
3
4
5
6
7
8
9
[root@xdlinux ➜ ~ ]$ kubectl delete pod/redis-1
pod "redis-1" deleted
[root@xdlinux ➜ ~ ]$ kubectl get all
NAME READY STATUS RESTARTS AGE
pod/redis-0 1/1 Running 0 5d
pod/redis-1 1/1 Running 0 2s
pod/redis-2 1/1 Running 0 5d
...
6. kube-scheduler
kube-scheduler
主要负责Pod调度,即根据一系列规则将待调度的 Pod 分配到集群中最合适的 Node 节点上。
1
2
3
4
5
6
7
8
9
10
11
12
13
# 支持模糊匹配,所以下面的kube-scheduler可以找到kube-scheduler-xdlinux
[root@xdlinux ➜ ~ ]$ kubectl describe -n kube-system pod kube-scheduler
Name: kube-scheduler-xdlinux
...
Containers:
kube-scheduler:
...
Liveness: http-get https://127.0.0.1:10259/livez delay=10s timeout=15s period=10s #success=1 #failure=8
Readiness: http-get https://127.0.0.1:10259/readyz delay=0s timeout=15s period=1s #success=1 #failure=3
Startup: http-get https://127.0.0.1:10259/livez delay=10s timeout=15s period=10s #success=1 #failure=24
Mounts:
/etc/kubernetes/scheduler.conf from kubeconfig (ro)
...
可手动检查上述接口,如:
1
2
[root@xdlinux ➜ ~ ]$ curl -k https://127.0.0.1:10259/livez
ok#
具体调度逻辑,后续进行学习。
7. kubelet
按照一般架构设计上的习惯,kubelet所承担的角色一般会被叫做
agent
,这里叫做kubelet
很大程度上受Borg
的命名影响,Borg
里面也有一个Borglet
的组件存在。kubelet便是K8s中的agent,负责Node和Pod相关的管理任务。
kubelet
是K8s集群中每个节点(Node)
上运行的核心代理组件,负责管理节点上的容器生命周期,是连接控制平面与节点的关键纽带。它确保容器按照Pod规范(PodSpec
)的定义正确运行,是实现Kubernetes容器编排能力的基础组件之一。
- 接收并执行控制平面(
kube-apiserver
)下发的Pod规范(PodSpec
),确保节点上的容器按照规范运行(创建、启动、停止、重启等)。 - 监控容器运行状态,并通过心跳向
kube-apiserver
汇报 - 执行Pod中的
存活探针(liveness probe)
、就绪探针(readiness probe)
、启动探针(startup probe)
,进行相关的容器健康状态检查 - 此外还负责资源管理、配合控制平面进行节点管理、镜像管理(拉取Pod所需的容器镜像)
配置文件路径:/var/lib/kubelet/config.yaml
1
2
3
4
5
6
# /var/lib/kubelet/config.yaml 部分内容
apiVersion: kubelet.config.k8s.io/v1beta1
cgroupDriver: systemd
# 健康检查所监听的地址和端口
healthzBindAddress: 127.0.0.1
healthzPort: 10248
可验证健康检查接口:
1
2
[root@xdlinux ➜ ~ ]$ curl 127.0.0.1:10248/healthz
ok#
8. 小结
9. 参考
- 极客时间:Kubernetes从上手到实践
- LLM