Kubernetes 授权
环境准备
bash
root@master30:~# kubectl create ns auth
root@master30:~# kubectl config set-context --current --namespace authKubernetes API 访问控制
当用户使用User 或 服务账号访问Kubernetes API时，每个请求都会经过多阶段的访问控制之后才会被接受，包括身份认证、鉴权以及准入控制（Admission Control）。
认证管理
Kubernetes 中的用户
Kubernetes 集群有两类用户：
- 普通用户 ，Kubernetes 中普通用户不是由 kubernetes 直接提供，而是身份认证插件提供，Kubernetes 并不包含用来代表普通用户账号的对象 。 普通用户的信息无法通过 API 调用添加到集群中，Kubernetes 认为：能够提供由集群的证书机构签名的合法证书的用户是通过身份认证的用户。 基于这样的机制，Kubernetes 使用证书中的 'subject' 的通用名称（Common Name）字段 （例如，"/CN=bob"）来确定用户名。 接下来，基于角色访问控制（RBAC）子系统会确定用户是否有权针对某资源执行特定的操作。
- 服务账号，Kubernetes 中服务账号是 Kubernetes API 所管理的用户。它们被绑定到特定的名字空间， 或者由 API 服务器自动创建，或者通过 API 调用创建。服务账号与一组以 Secret 保存的凭据相关，这些凭据会被挂载到 Pod 中，从而允许集群内的进程访问 Kubernetes API。
每个 API 请求必须包含一个用户：普通用户相关或者服务账号，客户端也可以发起匿名请求。这意味着集群内外的每个进程在向 API 服务器发起请求时都必须通过身份认证，否则会被视作匿名用户。
创建账户
以下探讨使用 **X509客户证书 **插件管理用户。
客户端准备
客户端要想访问集群，必须安装与集群版本一致的kubectl工具。
bash
root@client:~# apt install -y kubectl=1.30.2-1.1准备申请材料
bash
# 创建私钥
root@client:~# openssl genrsa -out cyh.key 2048
# 根据私钥，创建请求证书
root@client:~# openssl req -new -key cyh.key -out cyh.csr -subj '/CN=cyh/O=kubernets'
# 参数说明：
## C，Country，代表国家
## ST，STate，代表省份
## L，Location，代表城市
## O，Organization，代表组织，公司
## OU，Organization Unit，代表部门
## CN，Common Name，代表服务器域名
## emailAddress，代表联系人邮箱地址。
# 其他示例：
root@client:~# openssl req -new -key servera.key -out servera.csr -subj "/C=CHINA/ST=JS/L=NJ/O=LM/OU=DEVOPS/CN=servera.lab.example.com/emailAddress=cyh@lab.example.com"
# 客户端将自己请求证书发给kubernetes管理员
root@client:~# scp cyh.csr root@master30:创建用户凭据
管理员使用以下资源文件创建用户的kubeconfig。
bash
# 使用ca.crt和ca.key签名cyh.csr，得到cyh.crt证书
root@master30:~# openssl x509 -req -in cyh.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out cyh.crt -days 1095
# 导出kubeconfig模版
root@master30:~# kubectl config view > config.tpl
# 将kubeconfig模板、cyh.crt和kubernetes的ca证书发给客户端
root@master30:~# scp config.tpl cyh.crt /etc/kubernetes/pki/ca.crt root@client:~创建 kubeconfig
kubeconfig创建方法：
**方法一：**使用kubectl config命令创建。
修改模版config.tpl，结果如下：
yaml
apiVersion: v1
clusters:
- cluster:
server: https://10.1.8.30:6443
name: kubernetes
contexts:
- context:
cluster: kubernetes
namespace: default
user: cyh
name: cyh@kubernetes
current-context: cyh@kubernetes
kind: Config
users:
- name: cyh
bash
# 设置 cluster
root@client:~# mv config.tpl config
root@client:~# kubectl config set-cluster kubernetes --kubeconfig=config --certificate-authority=ca.crt --embed-certs
# --kubeconfig指定kubeconfig文件
# --server指定kubernetes服务器认证地址
# --certificate-authority选项指定ca证书
# --embed-certs选项作用是将ca.crt的内容添加到config文件中，
# 如果没有该选项，则添加 --certificate-authority 选项指定的路径，也就是ca.crt
# 设置credentials
root@client:~# kubectl config set-credentials cyh --kubeconfig=config --client-key=cyh.key --client-certificate=cyh.crt --embed-certs
# --client-key 指定用户私钥
# --client-certificate 指定服务器为用户生成的证书
# 设置context
root@client:~# kubectl config set-context cyh --kubeconfig=config --namespace=default --cluster=kubernetes --user=cyh
# --namespace指定Namespace
# --cluster指定集群
# --user指定用户
# 授权用户cyh集群管理员角色，后续详细讲解角色管理
root@master30:~# kubectl create clusterrolebinding cyh-admin --clusterrole=cluster-admin --user=cyh
# 验证结果
root@client:~# kubectl get nodes --kubeconfig=config
NAME STATUS ROLES AGE VERSION
master30.cyh.cloud Ready control-plane 40h v1.30.2
worker31.cyh.cloud Ready <none> 40h v1.30.2
worker32.cyh.cloud Ready <none> 40h v1.30.2**方法二：**使用文本编辑器创建（不推荐）。
bash
# 获取文件ca.crt base64编码，填充到certificate-authority-data
root@client:~# cat ca.crt | base64 | tr -d '\n'
# 获取文件cyh.key base64编码，填充到client-key-data
root@client:~# cat cyh.key | base64 | tr -d '\n'
# 获取文件cyh.crt base64编码，填充到client-certificate-data
root@client:~# cat cyh.crt | base64 | tr -d '\n'
# 使用上面的base64编码修改配置文件对应值
root@master30:~# kubectl config view
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: DATA+OMITTED
server: https://10.1.8.30:6443
name: kubernetes
contexts:
- context:
cluster: kubernetes
user: kubernetes-cyh
name: kubernetes-cyh@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-cyh
user:
client-certificate-data: REDACTED
client-key-data: REDACTED删除账户
bash
# 通过删除证书进行删除账户即可，为了后续操作方便，该账户不删除
# k8s删除用户csr资源后，客户端用户仍可以访问集群。
# 解释：用户认证功能由x509提供，与k8s无关。
# 如果不予许用户登录，应该从x509认证机制方面下手，例如ca.crt将相应客户端csr加入黑名单。
# 删除权限
root@master30:~# kubectl delete clusterrolebindings.rbac.authorization.k8s.io cyh-admin
# 验证权限
root@client:~# kubectl get nodes
Error from server (Forbidden): nodes is forbidden: User "cyh" cannot list resource "nodes" in API group "" at the cluster scope授权管理
鉴权概述
Kubernetes API 服务器对 API 请求进行鉴权。 它根据所有策略评估所有请求属性来决定允许或拒绝请求。 一个 API 请求的所有部分都必须被某些策略允许才能继续。 这意味着默认情况下拒绝权限。
当系统配置了多个鉴权模块时，Kubernetes 将按顺序使用每个模块。
- 如果任何鉴权模块批准或拒绝请求，则立即返回该决定，并且不会与其他鉴权模块协商。
- 如果所有模块对请求没有意见，则拒绝该请求。 被拒绝响应返回 HTTP 状态代码 403。
鉴权模式
鉴权模式定义认证成功的用户对集群的操作权限，由kube-apiserver配置文件指定：
bash
root@master30:~# cat /etc/kubernetes/manifests/kube-apiserver.yaml |grep mode
- --authorization-mode=Node,RBAC我们这里使用RBAC 和Node模式。
支持的模式：
-
Node ，是节点专用的鉴权模式，根据调度到 kubelet 上运行的 Pod 为 kubelet 授予权限。 要了解有关使用节点鉴权模式的更多信息，请参阅节点鉴权。
-
ABAC ，基于属性的访问控制（ABAC）定义了一种访问控制范型，通过使用将属性组合在一起的策略， 将访问权限授予用户。策略可以使用任何类型的属性（用户属性、资源属性、对象，环境属性等）。 要了解有关使用 ABAC 模式的更多信息，请参阅 ABAC 模式。
-
RBAC ，基于角色的访问控制（RBAC） 是一种基于企业内个人用户的角色来管理对计算机或网络资源的访问的方法。要了解有关使用 RBAC 模式的更多信息，请参阅 RBAC 模式。
- 被启用之后，RBAC（基于角色的访问控制）使用
rbac.authorization.k8s.ioAPI 组来驱动鉴权决策，从而允许管理员通过 Kubernetes API 动态配置权限策略。 - 要启用 RBAC，请使用
--authorization-mode = RBAC启动 API 服务器。
- 被启用之后，RBAC（基于角色的访问控制）使用
-
Webhook ------ WebHook 是一个 HTTP 回调：发生某些事情时调用的 HTTP POST； 通过 HTTP POST 进行简单的事件通知。 实现 WebHook 的 Web 应用程序会在发生某些事情时将消息发布到 URL。 要了解有关使用 Webhook 模式的更多信息，请参阅 Webhook 模式。
-
AlwaysAllow，允许用户所有请求。
bash
# 前面我们删除了用户cyh权限，更改为AlwaysAllow模式，测试cyh用户权限。
root@master30:~# vim /etc/kubernetes/manifests/kube-apiserver.yaml
......
# 在spec.containers下的command中添加参数- --basic-auth-file=/etc/kubernets/pki/aa.csv
spec:
containers:
- command:
- --authorization-mode=AlwaysAllow
......
# 更改完成后，kubernetes会自动重启pod/kube-apiserver，等该pod状态为running再次验证。
root@client:~# kubectl get nodes
NAME STATUS ROLES AGE VERSION
master30.cyh.cloud Ready control-plane 12d v1.30.2
worker31.cyh.cloud Ready <none> 12d v1.30.2
worker32.cyh.cloud Ready <none> 12d v1.30.2- AlwaysDeny，拒绝用户所有请求，不管用户是否具有权限，但不限制admin用户。
role 管理
kubernetes 方便管理权限，将一组特定权限赋予角色，然后将角色赋予用户，那么用户将继承该角色具有的权限。
角色分类
-
role ，namespace 角色，限定用户访问特定namespace。role绑定给用户，称之为rolebinding。
-
clusterrole ，cluster 角色，可以管理集群，包括所有namespace中资源。clusterrole绑定给用户，称之为clusterrolebinding。
权限由kubernetes系统预定义的，clusterroles/admin中包涵系统中全部权限列表。
bash
root@master30:~# kubectl describe clusterroles admin
Name: admin
Labels: kubernetes.io/bootstrapping=rbac-defaults
Annotations: rbac.authorization.kubernetes.io/autoupdate: true
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
rolebindings.rbac.authorization.k8s.io [] [] [create delete deletecollection get list patch update watch]
roles.rbac.authorization.k8s.io [] [] [create delete deletecollection get list patch update watch]
configmaps [] [] [create delete deletecollection patch update get list watch]
endpoints [] [] [create delete deletecollection patch update get list watch]
......输出说明：
-
Resources：代表系统中资源类型，例如Secret，Configmap等。
-
Resource Names：代表特定资源。如果Resources是Secret，那么这里就指特定Secret。
-
Non-Resource URLs： 被称为非资源URL或虚拟URL对象，是k8s中所需要的特殊动作（不需要关注）。
-
Verbs：代表针对资源执行的动作，包括操作get、list、create、delete、update、edit、watch、exec。
- get ，用于获得特定资源信息，例如，针对pod，可以执行
GET /api/v1/namespaces/{namespace}/pods/{podname}。
- get ，用于获得特定资源信息，例如，针对pod，可以执行
bash
root@client:~# kubectl get pod -n kube-system
Error from server (Forbidden): pods is forbidden: User "cyh" cannot list resource "pods" in API group "" in the namespace "kube-system"
root@client:~# kubectl get pod kube-proxy-8kp8w -n kube-system
NAME READY STATUS RESTARTS AGE
kube-proxy-8kp8w 1/1 Running 4 52d- list ，用户查看某一类型资源清单，例如针对pod，可以执行
GET /api/v1/namespaces/{namespace}/pods。
bash
root@client:~# kubectl get pod -n kube-system
NAME READY STATUS RESTARTS AGE
calico-kube-controllers-6dfcd885bf-lq4n5 1/1 Running 4 52d
calico-node-44cf4 1/1 Running 4 52d
calico-node-48sm4 1/1 Running 4 52d
.....
root@client:~# kubectl get pod kube-proxy-8kp8w -n kube-system
Error from server (Forbidden): pods "kube-proxy-8kp8w" is forbidden: User "cyh" cannot get resource "pods" in API group "" in the namespace "kube-system"创建 role
bash
root@master30:~# kubectl create role -h
Create a role with single rule.
Usage:
kubectl create role NAME --verb=verb --resource=resource.group/subresource
[--resource-name=resourcename] [--dry-run=server|client|none] [options]示例1：可以对项目中所有pods执行get、list、watch操作
bash
root@master30:~# kubectl create role pod-role --verb=get,list,watch --resource=pods -n default --dry-run=client -o yaml
yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
creationTimestamp: null
name: pod-role
namespace: default
rules:
- apiGroups:
- ""
resources:
- pods
verbs:
- get
- list
- watch
bash
root@master30:~# kubectl create role pod-role --verb=get,list,watch --resource=pods -n default
root@master30:~# kubectl get roles pod-role -n default
NAME CREATED AT
pod-role 2021-08-24T10:24:36Z
root@master30:~# kubectl describe roles pod-role -n default
Name: pod-role
Labels: <none>
Annotations: <none>
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
pods [] [] [get list watch]示例2：访问特定资源pods/readablepod
bash
root@master30:~# kubectl create role pod-role --verb=get --resource=pods \
--resource-name=readablepod --resource-name=anotherpod示例3：可以对项目中所有replicasets执行get list watch操作
bash
root@master30:~# kubectl create role foo --verb=get,list,watch --resource=replicasets修改 role
bash
# 增加create权限
root@master30:~# kubectl edit roles -n default pod-role
......
rules:
- apiGroups:
- ""
resources:
- pods
verbs:
# 在verbs下添加相应权限
- list
- get
- watch
- createapiGroups
-
角色的 rules 属性中
apiGroups默认为空。 -
pod、service 资源的 apiVersion 是v1，apiGroups为""。
-
Deployment、DaemonSet 资源的 apiVersion 是apps/v1，apiGroups为"apps"。如下：
yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
creationTimestamp: null
name: deployments-role
namespace: default
rules:
- apiGroups:
- "apps"
resources:
- deployments
verbs:
- get
- list
- watch**示例1：**定义角色，无法操作deployments，因为apiGroups未指定apps。
yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
creationTimestamp: null
name: deployments-role
namespace: default
rules:
- apiGroups:
- ""
resources:
- deployments
verbs:
- get
- list
- watch**示例2：**定义一个可以 scale deployments 的角色。
yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
creationTimestamp: null
name: deployments-role
namespace: default
rules:
- apiGroups:
- "apps"
resources:
- deployments
# 额外添加以下资源
- deployments/scale
verbs:
- get
- list
- watch
# 额外添加以下权限
- patch**示例3：**定义一个对不同类型资源赋予不同权限的角色。
yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
creationTimestamp: null
name: all-role
namespace: default
rules:
- apiGroups:
- ""
resources:
- pods
verbs:
- get
- list
- watch
- apiGroups:
- "apps"
resources:
- deployments
- deployments/scale
verbs:
- get
- list
- watch
- patch常见apiGroups
| Type | apiVersion | apiGroups |
|---|---|---|
| Pod、Service、PersistentVolume、PersistentVolumeClaim | v1 | "" |
| Deployment、DaemonSet、StatefulSets | apps/v1 | apps |
| Job | batch/v1 | batch |
| CronJob | batch/v1beta1 | batch |
| Role RoleBinding ClusterRole ClusterRoleBinding | rbac.authorization.k8s.io/v1 | rbac.authorization.k8s.io |
| NetworkPolicy | networking.k8s.io/v1 | networking.k8s.io |
每种类型资源的 apiVersion 都可以通过以下命令查询：
bash
root@master30:~# kubectl explain deployment|grep VERSION
VERSION: apps/v1
root@master30:~# kubectl explain networkpolicy|grep VERSION
VERSION: networking.k8s.io/v1
# 或者
root@master30:~/auth# kubectl api-resources |grep -i deploy
deployments deploy apps/v1 true Deploymentrole 绑定
将 role 绑定给用户。
bash
root@master30:~# kubectl create rolebinding default-pod-cyh -n default --role=pod-role --user=cyh --dry-run=client -o yaml
yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
creationTimestamp: null
name: default-pod-cyh
namespace: default
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: pod-role
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: cyh
bash
# 绑定 ns/default 中角色 pod-role 给 cyh
root@master30:~# kubectl create rolebinding default-pod-cyh -n default --role=pod-role --user=cyh
# 角色绑定完成后，角色的权限发生变化，用户获得的权限也会跟着动态变化。
root@master30:~# kubectl get rolebindings -n default default-pod-cyh
NAME ROLE AGE
default-pod-cyh Role/pod-role 2m15s
root@master30:~# kubectl describe rolebindings -n default default-pod-cyh
Name: default-pod-cyh
Labels: <none>
Annotations: <none>
Role:
Kind: Role
Name: pod-role
Subjects:
Kind Name Namespace
---- ---- ---------
User cyh
# 验证
root@client:~# kubectl run web --image=hub.laoma.cloud/library/httpd --image-pull-policy=IfNotPresent -n default
root@client:~# kubectl get pod -n default
NAME READY STATUS RESTARTS AGE
web 1/1 Running 0 2m30s
root@client:~# kubectl get pod -n default -w
NAME READY STATUS RESTARTS AGE
web 1/1 Running 0 2m42srole 回收
bash
root@master30:~# kubectl delete rolebindings default-pod-cyh -n kube-system
rolebinding.rbac.authorization.k8s.io "default-pod-cyh" deleted
# 再次验证
root@client:~# kubectl get pod -n default
Error from server (Forbidden): pods is forbidden: User "cyh" cannot list resource "pods" in API group "" in the namespace "default"role 删除
bash
root@master30:~# kubectl delete roles pod-role -n default实践 1：角色管理
- 在 auth 命名空间，创建角色 pod-reader，针对pod，具备权限get、list、watch
- 赋予 cyh 用户 auth 命名空间 角色 pod-reader
- 管理员身份在 auth 命名空间创建 deployment
- 回收 cyh 用户 集群管理员角色 cluster-admin（如果存在）
- cyh 用户验证：查看deployment和pod
- 清理资源：回收用户角色，删除 deployment
clusterrole 管理
常见 clusterrole
kubernetes系统中已经预定义了很多clusterrole，常见的clusterrole如下：
- view，对系统中几乎所有的对象都有get、list和watch权限。
- edit，对系统中几乎所有的对象都有get、list和watch权限。其中部分对象额外具有 create、delete、deletecollection、patch、update 权限。
- admin ，对系统中大部分的对象具有所有权限。
- cluster-admin ，对系统中所有的对象具有所有权限。
创建 clusterrole
bash
root@master30:~# kubectl create clusterrole -h
Usage:
kubectl create clusterrole NAME --verb=verb --resource=resource.group
[--resource-name=resourcename] [--dry-run=server|client|none] [options]示例1：创建一个可以get、list、watch所有项目中pods的clusterrole
bash
root@master30:~# kubectl create clusterrole pod-role --verb=get,list,watch --resource=pods --dry-run=client -o yaml
yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
creationTimestamp: null
name: pod-role
rules:
- apiGroups:
- ""
resources:
- pods
verbs:
- get
- list
- watch
bash
root@master30:~# kubectl create clusterrole pod-role --verb=get,list,watch --resource=pods
root@master30:~# kubectl get clusterrole pod-role
NAME CREATED AT
pod-role 2021-08-25T14:31:21Z
root@master30:~# kubectl describe clusterrole pod-role
Name: pod-role
Labels: <none>
Annotations: <none>
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
pods [] [] [get list watch]示例2：创建一个可以get、list、watch所有项目中pods/readablepod和pods/anotherpod的clusterrole
bash
root@master30:~# kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod示例3：创建一个可以get、list、watch所有项目中pods和pods/status的clusterrole
bash
root@master30:~# kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status修改 clusterrole
bash
root@master30:~# kubectl edit clusterrole pod-role
......
rules:
- apiGroups:
- ""
resources:
- pods
verbs:
- get
- list
- watch
# 添加create权限
- createclusterrole 绑定
将clusterrole绑定给用户。
bash
root@master30:~# kubectl create clusterrolebinding cyh-pod-role --clusterrole=pod-role --user=cyh --dry-run=client -o yaml
yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
creationTimestamp: null
name: cyh-pod-role
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: pod-role
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: cyh
bash
root@master30:~# kubectl create clusterrolebinding cyh-pod-role --clusterrole=pod-role --user=cyh
root@master30:~# kubectl get clusterrolebinding cyh-pod-role
NAME ROLE AGE
cyh-pod-role ClusterRole/pod-role 35s
root@master30:~# kubectl describe clusterrolebinding cyh-pod-role
Name: cyh-pod-role
Labels: <none>
Annotations: <none>
Role:
Kind: ClusterRole
Name: pod-role
Subjects:
Kind Name Namespace
---- ---- ---------
User cyh
# client节点使用cyh用户测试权限
root@client:~# kubectl get pod -n kube-system
NAME READY STATUS RESTARTS AGE
calico-kube-controllers-6dfcd885bf-lq4n5 1/1 Running 6 53d
calico-node-44cf4 1/1 Running 6 53d
......
root@client:~# kubectl get pod -n default
NAME READY STATUS RESTARTS AGE
web 1/1 Running 1 15hclusterrole 回收
bash
root@master30:~# kubectl delete clusterrolebinding cyh-pod-role删除 clusterrole
bash
root@master30:~# kubectl delete clusterrole pod-reader服务账户
服务账户概述
Service Account，即服务账户，pod 使用 Service Account 身份运行容器。赋予Service Account相应角色，则使用该Service Account身份运行的pod中进程将具有对应Service Account的权限，进而有权限管理Kubernetes集群。
在每个namespace中都有一个名称为default的Service Account，创建的pod都会以 Service Account-default身份运行。
bash
root@master30:~# kubectl get sa
NAME SECRETS AGE
default 1 53d
# 创建一个pod，验证Service Account信息
root@master30:~# kubectl run web --image=hub.laoma.cloud/library/httpd --image-pull-policy=IfNotPresent
root@master30:~# kubectl get pod web -o yaml|grep serviceAccount
serviceAccount: default
serviceAccountName: default
- serviceAccountToken:服务账号与用户账号比较
Kubernetes 区分用户账号和服务账号的概念，主要基于以下原因：
| 类别 | 用户账号 | 服务账号 |
|---|---|---|
| 使用主体 | 针对人 | 针对Pod， Pod 中的应用程序通过服务账号访问集群。 |
| 范围 | 集群范围，集群中的用名称必须唯一。 | 命名空间范围，两个不同的名字空间可以包含具有相同名称的服务账号。 |
| 轻量程度 | 重量，通过认证模块配置。 | 轻量，用户为了具体的任务按需创建服务账号。将服务账户与用户分离开来， 使工作负载更易于遵从权限最小化原则。 |
服务账号令牌卷机制
默认情况下，Kubernetes 添加一个投射卷到 Pod， 此卷包括了访问 Kubernetes API 的令牌。
bash
root@master30:~# kubectl get pod web -o yaml
yaml
...
volumeMounts:
- mountPath: /var/run/secrets/kubernetes.io/serviceaccount
name: kube-api-access-sjffr
readOnly: true
...
volumes:
- name: kube-api-access-sjffr
projected:
sources:
- serviceAccountToken:
path: token # 必须与应用所预期的路径匹配
- configMap:
items:
- key: ca.crt
path: ca.crt
name: kube-root-ca.crt
- downwardAPI:
items:
- fieldRef:
apiVersion: v1
fieldPath: metadata.namespace
path: namespace该清单片段定义了由三个数据源组成的投射卷。在当前场景中，每个数据源也代表该卷内的一条独立路径。这三个数据源是：
-
serviceAccountToken数据源 ，包含 kubelet 从 kube-apiserver 获取的令牌。 kubelet 使用 TokenRequest API 获取有时间限制的令牌**。为 TokenRequest 服务的这个令牌会在 Pod 被删除或定义的生命周期（默认为 1 小时）结束之后过期。**该令牌绑定到特定的 Pod， 并将其 audience（受众）设置为与kube-apiserver的 audience 相匹配。 这种机制取代了之前基于 Secret 添加卷的机制，之前 Secret 代表了针对 Pod 的 ServiceAccount 但不会过期。注意：没有特定的机制可以使通过 TokenRequest 签发的令牌无效。 如果你不再信任为某个 Pod 绑定的服务账号令牌， 你可以删除该 Pod。删除 Pod 将使其绑定的服务账号令牌过期。
-
**
configMap数据源。**ConfigMap 包含一组证书颁发机构数据。 Pod 可以使用这些证书来确保自己连接到集群的 kube-apiserver（而不是连接到中间件或意外配置错误的对等点上）。 -
downwardAPI数据源，用于查找包含 Pod 的名字空间的名称， 并使该名称信息可用于在 Pod 内运行的应用程序代码。
Pod 内挂载这个特定卷的所有容器都可以访问上述信息。
bash
root@master30:~# kubectl exec -it web -- bash
root@web:/usr/local/apache2# ls /var/run/secrets/kubernetes.io/serviceaccount
ca.crt namespace token
root@web:/usr/local/apache2# cat \
/var/run/secrets/kubernetes.io/serviceaccount/token
eyJhbGciOiJSUzI1NiIsI......
root@web:/usr/local/apache2# cat /var/run/secrets/kubernetes.io/serviceaccount/name pace
auth服务账户管理
SA 创建
bash
root@master30:~# kubectl create sa sa1
root@master30:~# kubectl get sa sa1
NAME SECRETS AGE
sa1 1 9sSA 授权
bash
root@master30:~# kubectl create clusterrolebinding auth-sa1-cluster-admin --clusterrole=cluster-admin --serviceaccount=auth:sa1
clusterrolebinding.rbac.authorization.k8s.io/auth-sa1-cluster-admin created
# 选项--serviceaccoun指明Service Account时，格式为namespace:Service Account NameSA 使用
bash
# 删除 pod 重新创建
root@master30:~# kubectl delete pod web
root@master30:~# kubectl run web --image=hub.laoma.cloud/library/httpd --image-pull-policy=IfNotPresent --dry-run=client -o yaml > web.yaml
root@master30:~# vim web.yaml
yaml
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: web
name: web
spec:
containers:
- image: httpd
imagePullPolicy: IfNotPresent
name: web
resources: {}
dnsPolicy: ClusterFirst
restartPolicy: Always
# 添加以下任一记录
serviceAccount: sa1
serviceAccountName: sa1
status: {}
bash
root@master30:~# kubectl apply -f web.yaml
root@master30:~# kubectl get pod web -o yaml
......
spec:
......
serviceAccount: sa1
serviceAccountName: sa1重要：虽然 pod/web 中 httpd 进程具有 clusterrole/cluster-admin 角色，但是它只是用来提供httpd服务，不会做其他操作。
回收权限
bash
root@master30:~# kubectl delete clusterrolebindings auth-sa1-cluster-admin
clusterrolebinding.rbac.authorization.k8s.io "auth-sa1-cluster-admin" deleted使用案例
集群 dashboard 中 pod 使用服务账户管理集群。
手动管理服务账号 token
- v1.22 之前的 Kubernetes 版本会自动创建凭据访问 Kubernetes API。 这种机制是：先创建令牌 Secret，然后将其挂载到正运行的 Pod 中。
- 在包括 Kubernetes v1.28 在内最近的几个版本中，使用 TokenRequest API 直接获得 API 凭据， 并使用投射卷挂载到 Pod 中。这种方法获得的令牌具有绑定的生命周期， 当挂载的 Pod 被删除时这些令牌将自动失效。
创建临时令牌
bash
root@master30:~# kubectl create sa sa1
root@master30:~# kubectl create token sa1
eyJhbGciOiJSUzI1NiIsImt......
# 注意：服务账号属性中是看不到关联的token的。
root@master30:~# kubectl get sa sa1 -o yaml
apiVersion: v1
kind: ServiceAccount
metadata:
creationTimestamp: "2023-11-01T04:05:03Z"
name: sa1
namespace: cyh
resourceVersion: "11548"
uid: 4944f75b-43ae-43fc-abfd-f2d20b7375f1创建永久令牌
创建一个带有特殊注解 kubernetes.io/service-account.name 的 Secret 对象。一旦你手动创建一个 Secret 并将其关联到 ServiceAccount， Kubernetes 控制平面就会自动将令牌填充到该 Secret 中。
bash
root@master30:~# vim sa1-token.yaml
yaml
apiVersion: v1
kind: Secret
metadata:
name: sa1-secret
annotations:
kubernetes.io/service-account.name: sa1
type: kubernetes.io/service-account-token
bash
root@master30:~# kubectl apply -f sa1-token.yaml当你删除一个与某 Secret 相关联的 ServiceAccount 时，Kubernetes 的控制面会自动清理该 Secret 中长期有效的令牌。
bash
root@master30:~# kubectl delete sa sa1
root@master30:~# kubectl get secrets
No resources found in cyh namespace.说明： 尽管存在手动创建长久 ServiceAccount 令牌的机制，但还是推荐使用 TokenRequest 获得短期的 API 访问令牌。
环境清理
bash
root@master30:~# kubectl delete ns authKubernetes 集群 Dashboard
kuboard 介绍
Kuboard 是一款专为 Kubernetes 设计的免费管理界面，兼容 Kubernetes 版本 1.13 及以上。Kuboard 每周发布一个 beta 版本，最长每月发布一个正式版本，经过两年的不断迭代和优化，已经具备多集群管理、权限管理、监控套件、日志套件等丰富的功能，并且有 1000+ 的企业将 Kuboard 应用于其生产环境。Kuboard 自 2019年8月发布第一个版本以来，得到了众多用户的认可，目前已经获得了 10000+ GitHub Star。
Kuboard 的定位和 Dashboard 是相似的，主要的区别 在于：
- Kuboard 关注微服务参考架构的视角对界面进行组织，参考 Kuboard 简介。
- Kuboard 中，不需要手工编写 YAML 文件，进一步降低 K8S 使用难度，提高便捷性。
- Kuboard 可以导出整个微服务架构的部署信息，并在新的名称空间/集群导入配置信息。
- Kuboard 的一个发展方向是，提供内建的 监控套件（目前的全局监控套件成熟度比较高）。
Kubernetes Dashboard
介绍
Kubernetes Dashboard 是 Kubernetes 的官方 Web UI。
Kubernetes Dashboard 具备的功能：
- 向 Kubernetes 集群部署容器化应用
- 诊断容器化应用的问题
- 管理集群的资源
- 查看集群上所运行的应用程序
- 创建、修改Kubernetes 上的资源（例如 Deployment、Job、DaemonSet等）
- 展示集群上发生的错误
部署
bash
# 下载资源yaml文件
root@master30:~# wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.6.1/aio/deploy/recommended.yaml
# 查看images
root@master30:~# grep image: recommended.yaml
image: kubernetesui/dashboard:v2.6.1
image: kubernetesui/metrics-scraper:v1.0.8
# 执行部署
root@master30:~# kubectl apply -f recommended.yaml 验证
bash
root@master30:~# kubens
default
kube-node-lease
kube-public
kube-system
kubernetes-dashboard
root@master30:~# kubens kubernetes-dashboard
root@master30:~# kubectl get deployments.apps
NAME READY UP-TO-DATE AVAILABLE AGE
dashboard-metrics-scraper 1/1 1 1 2m25s
kubernetes-dashboard 1/1 1 1 2m25s
root@master30:~# kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes-dashboard-metrics-scraper ClusterIP 10.98.116.192 <none> 8000/TCP 3m54s
kubernetes-dashboard-web ClusterIP 10.107.63.216 <none> 8000/TCP 3m54s
root@master30:~# kubectl get serviceaccounts
NAME SECRETS AGE
default 1 23h
kubernetes-dashboard 1 23h
root@master30:~# kubectl describe serviceaccounts kubernetes-dashboard
Name: kubernetes-dashboard
Namespace: kubernetes-dashboard
Labels: app.kubernetes.io/part-of=kubernetes-dashboard
Annotations: <none>
Image pull secrets: <none>
Mountable secrets: <none>
Tokens: <none>
Events: <none>
# 创建了clusterrolebindings/kubernetes-dashboard
root@master30:~# kubectl get clusterrolebindings.rbac.authorization.k8s.io |grep dashboard
kubernetes-dashboard ClusterRole/kubernetes-dashboard 23h
# sa/kubernetes-dashboard具有ClusterRole/kubernetes-dashboard
root@master30:~# kubectl describe clusterrolebindings.rbac.authorization.k8s.io kubernetes-dashboard
Name: kubernetes-dashboard
Labels: <none>
Annotations: <none>
Role:
Kind: ClusterRole
Name: kubernetes-dashboard
Subjects:
Kind Name Namespace
---- ---- ---------
ServiceAccount kubernetes-dashboard kubernetes-dashboard
# ClusterRole/kubernetes-dashboard权限如下：
root@master30:~# kubectl describe clusterroles kubernetes-dashboard
Name: kubernetes-dashboard
Labels: k8s-app=kubernetes-dashboard
Annotations: <none>
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
nodes.metrics.k8s.io [] [] [get list watch]
pods.metrics.k8s.io [] [] [get list watch]
# deployments.apps/kubernetes-dashboard以sa/kubernetes-dashboard身份运行，所以deployments.apps/kubernetes-dashboard部署的pod只可以查看资源nodes.metrics.k8s.io和pods.metrics.k8s.io
root@master30:~# kubectl get deployments.apps kubernetes-dashboard -o yaml|grep ' serviceAccount'
serviceAccount: kubernetes-dashboard
serviceAccountName: kubernetes-dashboard修改 service/kubernetes-dashboard 类型为 NodePort，从外部访问。
bash
root@master30:~# kubectl edit svc kubernetes-dashboard
spec:
......
type: NodePort
root@master30:~# kubectl get svc kubernetes-dashboard
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes-dashboard NodePort 10.111.32.116 <none> 443:30518/TCP 4m45s使用ingress配置访问，参考：
yamlapiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ingress-dashboard namespace: kubernetes-dashboard annotations: # 关键：透传 TLS，Ingress 不解密 nginx.ingress.kubernetes.io/ssl-passthrough: "true" nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" spec: ingressClassName: nginx rules: - host: dashboard.cyh.cloud http: paths: - path: / pathType: Prefix backend: service: name: kubernetes-dashboard port: number: 443客户端配置dashboard.cyh.cloud域名到ingress服务地址，实验环境是10.1.8.40
访问 Dashboard
新版本
Kubernetes Dashboard 新版本只支持使用 Bearer Token登录。
Kubernetes Dashboard 默认部署时，只配置了最低权限的 RBAC。因此，我们要创建一个名为 admin-user 的 ServiceAccount，再创建一个 ClusterRolebinding，将其绑定到 Kubernetes 集群中默认初始化的 cluster-admin 这个 ClusterRole。
bash
root@master30:~# cat > kubernetes-dashboard-admin.yaml <<'EOF'
apiVersion: v1
kind: ServiceAccount
metadata:
name: kubernetes-dashboard-admin
namespace: kubernetes-dashboard
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: kubernetes-dashboard-admin
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: kubernetes-dashboard-admin
namespace: kubernetes-dashboard
EOF
yaml
root@master30:~# kubectl apply -f kubernetes-dashboard-admin.yaml
# 创建 Bearer Token
root@master30:~# kubectl -n kubernetes-dashboard create token kubernetes-dashboard-admin
eyJhbGciOiJSUzI1NiIsImtpZCI6ImhLWEhaTWQtNGZTek5zUFUyUmNobzN1V2ZlOG1iWkwzSU5kZDZLbU1WUTAifQ.eyJhdWQiOlsiaHR0cHM6Ly9rdWJlcm5ldGVzLmRlZmF1bHQuc3ZjLmNsdXN0ZXIubG9jYWwiXSwiZXhwIjoxNjc2NDU4ODI3LCJpYXQiOjE2NzY0NTUyMjcsImlzcyI6Imh0dHBzOi8va3ViZXJuZXRlcy5kZWZhdWx0LnN2Yy5jbHVzdGVyLmxvY2FsIiwia3ViZXJuZXRlcy5pbyI6eyJuYW1lc3BhY2UiOiJrdWJlcm5ldGVzLWRhc2hib2FyZCIsInNlcnZpY2VhY2NvdW50Ijp7Im5hbWUiOiJhZG1pbi11c2VyIiwidWlkIjoiYmViNGI3MWMtNmI5MS00ODk4LThiMTMtZWQwZWE3N2JiMmQ5In19LCJuYmYiOjE2NzY0NTUyMjcsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDprdWJlcm5ldGVzLWRhc2hib2FyZDphZG1pbi11c2VyIn0.kBwU3g3Euqj5jMKD9AYu-OQW2yc9pc2hb7uaDi2PO3AdkOBVMkaIiXnWEUC98hpFyXUWGSiaZWPsylJHXMpWz_X-J03nd7zZegUhPbzVxPh7vHyaOaILmqATlakAHMHbwcEQDygBQPBNbPNd-hD-rzaVNkmr2oARNGVRaX7fMNRkuvcbji0-s6IO5yotKkWaGXkIAtwmMTgtgcGnOpVsB97UYjPgWz6RMBL9ZCZIVXHxE_FIl_If7ewhObyaijZIbWeZ21job5PPvb1H1VAHOZoDXtFK_lZdIRIK6e6MYYU4mfYqTcOyiEG8c5SxCOaD4xchWGdzFcfZfn52VQJ7hQ提示：Token默认有效期24小时，过期后自动删除。下一次登录需要生成新的Token。
分析 SA 使用案例
Kubernetes Dashboard 默认部署时，只配置了最低权限的 RBAC。接下来分析默认的权限配置。
bash
# Kubernetes Dashboard 以deployment形式运行
root@master30:~# kubectl get deployments.apps
NAME READY UP-TO-DATE AVAILABLE AGE
dashboard-metrics-scraper 1/1 1 1 146m
kubernetes-dashboard 1/1 1 1 146m
# 以 serviceAccount: kubernetes-dashboard 身份运行
root@master30:~# kubectl get deployments.apps kubernetes-dashboard -o yaml|grep serviceAc
serviceAccount: kubernetes-dashboard
serviceAccountName: kubernetes-dashboard
# serviceAccount: kubernetes-dashboard 绑定了Role/kubernetes-dashboard
root@master30:~# kubectl get rolebindings.rbac.authorization.k8s.io
NAME ROLE AGE
kubernetes-dashboard Role/kubernetes-dashboard 147
# Role/kubernetes-dashboard 具备能力如下：
root@master30:~# kubectl describe role kubernetes-dashboard
Name: kubernetes-dashboard
Labels: k8s-app=kubernetes-dashboard
Annotations: <none>
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
secrets [] [kubernetes-dashboard-certs] [get update delete]
secrets [] [kubernetes-dashboard-csrf] [get update delete]
secrets [] [kubernetes-dashboard-key-holder] [get update delete]
configmaps [] [kubernetes-dashboard-settings] [get update]
services/proxy [] [dashboard-metrics-scraper] [get]
services/proxy [] [heapster] [get]
services/proxy [] [http:dashboard-metrics-scraper] [get]
services/proxy [] [http:heapster:] [get]
services/proxy [] [https:heapster:] [get]
services [] [dashboard-metrics-scraper] [proxy]
services [] [heapster] [proxy]
# 创建 serviceAccount: kubernetes-dashboard Token
root@master30:~# kubectl -n kubernetes-dashboard create token kubernetes-dashboard
eyJhbGciOiJSUzI1NiIsImtpZCI6Im9jekNIUUFRZUpKYzA3VXdmRHJvT3ZhaU1fMFNxVkh6NEJZa2lyUnhaaXcifQ.eyJhdWQiOlsiaHR0cHM6Ly9rdWJlcm5ldGVzLmRlZmF1bHQuc3ZjLmNsdXN0ZXIubG9jYWwiXSwiZXhwIjoxNzc4MDUwMjI4LCJpYXQiOjE3NzgwNDY2MjgsImlzcyI6Imh0dHBzOi8va3ViZXJuZXRlcy5kZWZhdWx0LnN2Yy5jbHVzdGVyLmxvY2FsIiwianRpIjoiMTY0YzllOTItMzUwMS00Y2M2LWEwNjctOGZiNDI4OTQ4MDIwIiwia3ViZXJuZXRlcy5pbyI6eyJuYW1lc3BhY2UiOiJrdWJlcm5ldGVzLWRhc2hib2FyZCIsInNlcnZpY2VhY2NvdW50Ijp7Im5hbWUiOiJrdWJlcm5ldGVzLWRhc2hib2FyZCIsInVpZCI6IjU3ZDAwNjUxLTZmYWQtNDJmOC04ZmYxLTM3YmRmZGRiY2Y3ZCJ9fSwibmJmIjoxNzc4MDQ2NjI4LCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6a3ViZXJuZXRlcy1kYXNoYm9hcmQ6a3ViZXJuZXRlcy1kYXNoYm9hcmQifQ.EehmwsmNT6OVbazZs1pUOr_7kletmrpduE-8p4m2Y49c_hWXKs3ic7u3DMxw4jNJgbPfnvBiq2nrIObknsXBi6BKXL5XLDSlwsZobYUd0Uw0op2YOZZ3O_B4A-sSOiD-qD1eFMw2RYyR6aRuycWLngvYvyN3pfFCsd1GS_Gh4rAetsPtW4QzlFf230HL8Az2fU-M7A-0_kkt_ujpgMXQpyPSxV5qgyffjnDkOo-llDR-j_QsyyMt12k1zSjzN5ApcGQtHn9y8vbIS0xoqHulmU38kOjnKNpeQJ41nwKnf53q2I2MDoatO5r-hnD_TGx6xcckW0qFNrpje38XgRPHTQ Kubernetes 动态卷供应
动态卷介绍
之前创建存储卷（PV）都需要管理员手动操作，这类卷被称为静态卷。那么 Kubernetes 能不能 "智能" 管理卷呢？比如需要用卷时自动创建，不用时自动清理？
答案是可以的 ------ 这就是动态卷供应的能力。它彻底省去了集群管理员提前手动配置存储的工作，用户只要提出存储需求，系统就会自动创建对应的存储卷。
动态卷供应流程
- 管理员先创建 "存储模板"（StorageClass），指定用哪个 "造卷工具"（Provisioner，制备器）来创建卷；
- 用户创建 "存储申请单"（PVC）时，指定要用哪个 "存储模板"；
- 系统收到申请后，会让模板绑定的 "造卷工具" 自动创建一个 PV，并且把 PV 和用户的 PVC 绑定，用户直接用 PVC 就行。
StorageClass
StorageClass 就像管理员定义的 "存储套餐"------ 不同套餐对应不同的存储类型、服务质量（比如读写速度）、备份策略等。Kubernetes 不关心套餐叫什么，只负责按套餐规则造卷。
- 命名很重要：用户创建 PVC 时，要通过这个名字选择对应的存储套餐；
- 创建后不能改：StorageClass 一旦创建，名字和参数就没法修改了，要改只能重新建。
核心配置
每个 "存储套餐" 都包含以下核心信息，用来指导系统创建 PV：
-
provisioner：造卷工具（制备器），指定用哪个工具创建 PV，必须设置。
Kubernetes 自带一些 Provisioner，名字以 "kubernetes.io" 开头（比如 AWS EBS、Azure Disk）；也可以使用第三方提供的（比如 NFS 没有内置工人，需要自己装）Provisioner，按 Kubernetes 规则运行即可。
存储类型 是否内置 说明 AWSElasticBlockStore ✅ 是 亚马逊云硬盘 AzureFile/AzureDisk ✅ 是 微软云文件 / 硬盘 Ceph RBD ✅ 是 Ceph 块存储 Glusterfs ✅ 是 分布式文件系统 NFS ❌ 否 网络文件系统，需装外部工人 本地存储（Local） ❌ 否 节点本地硬盘，需装外部工人 iSCSI/CephFS ❌ 否 需外部工人 -
reclaimPolicy：PV 回收策略，指定 PV 不用怎么处理 PV。
- Delete（默认）：PVC 删除后，PV 也自动删，对应的后端存储（比如云硬盘、NFS 目录）也会清掉；
- Retain：PVC 删除后，PV 保留下来，后端存储的数据也不删，管理员可以手动处理。
-
volumeBindingMode：PVC 创建出来后，指定 PVC 与P V 绑定时机。
- Immediate（立即绑定）：创建 PVC 就造卷，不管 Pod 会不会用；适合存储能被所有节点访问的场景（比如云硬盘）；
- WaitForFirstConsumer（等使用者）：先不造卷，等第一个用这个 PVC 的 Pod 创建后，根据 Pod 要跑的节点造卷；适合本地存储、只能被特定节点访问的存储。
-
mountOptions：指定 PV 挂载时附加的 "额外设置"，比如权限、调试模式。
注意：如果存储不支持这些选项，造卷会失败；如果选项填错，PV 挂载会失败。
-
parameters：比如存储类型（SSD/HDD）、副本数等，不同工具参数不一样。
基础示例
yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: standard # 套餐名，用户PVC要填这个
provisioner: kubernetes.io/aws-ebs # 用AWS EBS的造卷工具
parameters:
type: gp2 # 存储类型为gp2（AWS的通用型SSD）
reclaimPolicy: Retain # PVC 不用了保留，不删除
allowVolumeExpansion: true # 允许扩容
mountOptions:
- debug # 挂载时开启调试模式
volumeBindingMode: Immediate # 立即创建并绑定PV部署 Local Path provisioner
Local Path Provisioner 是 K8s 官方推荐的本地存储动态卷插件，适合需要使用节点本地磁盘的场景。
部署本地路径制备器
bash
# 下载官方模板
root@master30:~# wget https://github.com/rancher/local-path-provisioner/blob/v0.0.35/deploy/local-path-storage.yaml
# 查看资源配置
root@master30:~# cat local-path-storage.yaml
yaml
apiVersion: v1
kind: Namespace
metadata:
name: local-path-storage
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: local-path-provisioner-service-account
namespace: local-path-storage
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: local-path-provisioner-role
namespace: local-path-storage
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch", "create", "patch", "update", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: local-path-provisioner-role
rules:
- apiGroups: [""]
resources: ["nodes", "persistentvolumeclaims", "configmaps", "pods", "pods/log"]
verbs: ["get", "list", "watch"]
- apiGroups: [""]
resources: ["persistentvolumes"]
verbs: ["get", "list", "watch", "create", "patch", "update", "delete"]
- apiGroups: [""]
resources: ["events"]
verbs: ["create", "patch"]
- apiGroups: ["storage.k8s.io"]
resources: ["storageclasses"]
verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: local-path-provisioner-bind
namespace: local-path-storage
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: local-path-provisioner-role
subjects:
- kind: ServiceAccount
name: local-path-provisioner-service-account
namespace: local-path-storage
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: local-path-provisioner-bind
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: local-path-provisioner-role
subjects:
- kind: ServiceAccount
name: local-path-provisioner-service-account
namespace: local-path-storage
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: local-path-provisioner
namespace: local-path-storage
spec:
replicas: 1
selector:
matchLabels:
app: local-path-provisioner
template:
metadata:
labels:
app: local-path-provisioner
spec:
serviceAccountName: local-path-provisioner-service-account
containers:
- name: local-path-provisioner
image: rancher/local-path-provisioner:v0.0.35
imagePullPolicy: IfNotPresent
command:
- local-path-provisioner
- --debug
- start
- --config
- /etc/config/config.json
volumeMounts:
- name: config-volume
mountPath: /etc/config/
env:
- name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: CONFIG_MOUNT_PATH
value: /etc/config/
volumes:
- name: config-volume
configMap:
name: local-path-config
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: local-path
provisioner: rancher.io/local-path
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Delete
---
kind: ConfigMap
apiVersion: v1
metadata:
name: local-path-config
namespace: local-path-storage
data:
config.json: |-
{
"nodePathMap":[
{
"node":"DEFAULT_PATH_FOR_NON_LISTED_NODES",
"paths":["/opt/local-path-provisioner"]
}
]
}
setup: |-
#!/bin/sh
set -eu
mkdir -m 0777 -p "$VOL_DIR"
teardown: |-
#!/bin/sh
set -eu
rm -rf "$VOL_DIR"
helperPod.yaml: |-
apiVersion: v1
kind: Pod
metadata:
name: helper-pod
spec:
priorityClassName: system-node-critical
tolerations:
- key: node.kubernetes.io/disk-pressure
operator: Exists
effect: NoSchedule
containers:
- name: helper-pod
image: busybox
imagePullPolicy: IfNotPresentlocal-path-storage.yaml 核心由 5 类资源 组成，每部分各司其职：
| 资源类型 | 名称 | 核心作用 |
|---|---|---|
| Namespace | local-path-storage | 隔离 Local Path Provisioner 相关资源 |
| ConfigMap | local-path-config | 定义本地存储路径 规则（如默认 /opt/local-path-provisioner） |
| ServiceAccount + RBAC | local-path-provisioner | 赋予 Provisioner 操作 PV/PVC 的权限 |
| Deployment | local-path-provisioner | 运行 Local Path Provisioner 核心程序（动态创建本地 PV） |
| StorageClass | local-path | 提供给 PVC 调用的「本地存储模板」 |
bash
# 资源默认部署在命名空间：local-path-storage
root@master30:~# kubectl apply -f local-path-storage.yaml
# 确认资源状态
root@master30:~# kubectl get sc local-path
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
local-path rancher.io/local-path Delete WaitForFirstConsumer false 31s
root@master30:~# kubectl get all -n local-path-storage
NAME READY STATUS RESTARTS AGE
pod/local-path-provisioner-74b5c4bf98-955sk 1/1 Running 0 63s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/local-path-provisioner 1/1 1 1 63s
NAME DESIRED CURRENT READY AGE
replicaset.apps/local-path-provisioner-74b5c4bf98 1 1 1 63s验证部署
bash
# 设置默认命名空间
root@master30:~# kubectl config set-context --current --namespace default1. 创建 pvc
bash
root@master30:~# cat > local-path-pvc.yaml <<'EOF'
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: local-path-pvc
namespace: default
spec:
accessModes: ["ReadWriteOnce"]
resources:
requests:
storage: 5Gi
storageClassName: local-path # 指定 Local Path 的 StorageClass
EOF
root@master30:~# kubectl apply -f local-path-pvc.yaml
root@master30:~# kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE
local-path-pvc Pending local-path <unset> 6s
# 等待pod关联才会创建本地目录2. 创建 deployment
bash
root@master30:~# cat > local-path-deployment.yaml <<'EOF'
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: webapp
name: webapp
namespace: default
spec:
replicas: 2
selector:
matchLabels:
app: webapp
template:
metadata:
labels:
app: webapp
spec:
containers:
- image: nginx
name: nginx
volumeMounts:
- name: webapp-data
mountPath: /usr/share/nginx/html
volumes:
- name: webapp-data
persistentVolumeClaim:
claimName: local-path-pvc
EOF
root@master30:~# kubectl apply -f local-path-deployment.yaml
# 查看 pod 状态
root@master30:~# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
webapp-6d46b54487-6nqmh 1/1 Running 0 114s 10.224.19.21 worker31.cyh.cloud <none> <none>
webapp-6d46b54487-kzkd5 1/1 Running 0 114s 10.224.19.22 worker31.cyh.cloud <none> <none>
# 所有节点都调度到 worker31，因为只用worker31可以提供这个卷。
# 查看 pvc 状态
root@master30:~# kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE
local-path-pvc Bound pvc-e992833c-af6a-4d4d-aff5-fc544394db6d 5Gi RWO local-path <unset> 4m41s
# 写入测试文件
root@master30:~# kubectl exec webapp-6d46b54487-6nqmh -- bash -c 'echo Hello World From Nginx > /usr/share/nginx/html/index.html'
# 验证本地路径
root@worker31:~# ls /opt/local-path-provisioner/pvc-e992833c-af6a-4d4d-aff5-fc544394db6d_default_local-path-pvc/
index.html
root@worker31:~# cat /opt/local-path-provisioner/pvc-e992833c-af6a-4d4d-aff5-fc544394db6d_default_local-path-pvc/index.html
Hello World From Nginx3. 清理资源
bash
# 删除 deployment
root@master30:~# kubectl delete deployment webapp
# 删除 pvc
root@master30:~# kubectl delete pvc local-path-pvc
# 本地目录也被删除
root@worker31:~# ls /opt/local-path-provisioner/pvc-e992833c-af6a-4d4d-aff5-fc544394db6d_default_local-path-pvc/
ls: cannot access '/opt/local-path-provisioner/pvc-e992833c-af6a-4d4d-aff5-fc544394db6d_default_local-path-pvc/': No such file or directory部署 NFS provisioner
部署 NFS 服务
bash
# 安装 NFS server
root@master30:~# apt install -y nfs-kernel-server
# 安创建NFS目录 修改创建文件夹的权限
root@master30:~# mkdir -m 777 /shares/
# 配置共享，允许所有客户端访问
root@master30:~# cat << EOF > /etc/exports
/shares *(rw,sync,no_root_squash,no_all_squash,insecure)
EOF
# 重启 nfs server
root@master30:~# systemctl restart nfs-server.service
# 客户端安装
root@worker31:~# apt install -y nfs-common
root@worker32:~# apt install -y nfs-common部署 NFS provisioner
NFS没有内置制备器，这里我们自定义外部分配器。
bash
# 资源部署到命名空间：kube-storage
root@master30:~# kubectl create ns kube-storage
root@master30:~# kubectl config set-context --current --namespace kube-storage1. 创建 RBAC 权限
创建 nfs-rbac.yaml 文件，赋予 Provisioner 操作 PV/PVC 的权限。
yaml
root@master30:~# cat > nfs-rbac.yaml <<'EOF'
apiVersion: v1
kind: ServiceAccount
metadata:
name: nfs-client-provisioner
namespace: kube-storage
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: nfs-client-provisioner-runner
rules:
- apiGroups: [""]
resources: ["persistentvolumes"]
verbs: ["get", "list", "watch", "create", "delete"]
- apiGroups: [""]
resources: ["persistentvolumeclaims"]
verbs: ["get", "list", "watch", "update"]
- apiGroups: ["storage.k8s.io"]
resources: ["storageclasses"]
verbs: ["get", "list", "watch"]
- apiGroups: [""]
resources: ["events"]
verbs: ["create", "update", "patch"]
- apiGroups: [""]
resources: ["endpoints"]
verbs: ["get", "list", "watch", "create", "update", "patch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: run-nfs-client-provisioner
subjects:
- kind: ServiceAccount
name: nfs-client-provisioner
namespace: kube-storage
roleRef:
kind: ClusterRole
name: nfs-client-provisioner-runner
apiGroup: rbac.authorization.k8s.io
EOF
root@master30:~# kubectl apply -f nfs-rbac.yaml2. 部署 NFS Provisioner 应用
yaml
root@master30:~# cat > nfs-provisioner.yaml <<'EOF'
apiVersion: apps/v1
kind: Deployment
metadata:
name: nfs-client-provisioner
namespace: kube-storage
spec:
replicas: 1
strategy:
type: Recreate
selector:
matchLabels:
app: nfs-client-provisioner
template:
metadata:
labels:
app: nfs-client-provisioner
spec:
serviceAccountName: nfs-client-provisioner
volumes:
- name: nfs-client-root
nfs:
server: 10.1.8.30 # 同上 NFS 服务器 IP
path: /shares # 核心：同步改为 /shares
containers:
- name: nfs-client-provisioner
image: registry.k8s.io/sig-storage/nfs-subdir-external-provisioner:v4.0.2
volumeMounts:
- name: nfs-client-root
mountPath: /persistentvolumes
env:
- name: PROVISIONER_NAME
value: fuseim.pri/ifs
- name: NFS_SERVER
value: 10.1.8.30 # 替换为你的 NFS 服务器 IP
- name: NFS_PATH
value: /shares # 核心：共享路径改为 /shares
EOF
# 部署 NFS Provisioner 应用
root@master30:~# kubectl apply -f nfs-provisioner.yaml
# 查看 NFS Provisioner 应用
root@master30:~# kubectl get deployments.apps -n kube-storage
NAME READY UP-TO-DATE AVAILABLE AGE
nfs-client-provisioner 1/1 1 1 1m3. 创建 NFS StorageClass
yaml
root@master30:~# cat > nfs-storageclass.yaml <<'EOF'
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: nfs-storage
namespace: kube-storage
provisioner: fuseim.pri/ifs # 必须和 Provisioner 名称一致
parameters:
onDelete: retain # 删除 PVC 保留 NFS 数据
archiveOnDelete: "false"
# 按需设置回收策略
#reclaimPolicy: Retain
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: Immediate
EOF
# 创建 StorageClass
root@master30:~# kubectl apply -f nfs-storageclass.yaml
# 查看 StorageClass
root@master30:~# kubectl get sc
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
nfs-storage fuseim.pri/ifs Delete Immediate true 2s验证部署
在default命名空间测试。
bash
root@master30:~# kubens default1. 创建 pvc
bash
root@master30:~# cat > nfs-pvc.yaml <<'EOF'
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: webclaim
namespace: default
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
storageClassName: "nfs-storage"
EOF
# 创建 pvc
root@master30:~# kubectl apply -f nfs-pvc.yaml
# 查看 pvc 状态
root@master30:~# kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE
webclaim Bound pvc-6a020ff4-6b7f-4ef4-90fc-3dc94d3e8ddc 5Gi RWO default <unset> 3s
# 查看 pv 状态
root@master30:~# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE
pvc-6a020ff4-6b7f-4ef4-90fc-3dc94d3e8ddc 5Gi RWO Delete Bound default/webclaim default <unset> 65s
# 查看 nfs 共享目录
root@master30:~# ls /shares/
default-webclaim-pvc-6a020ff4-6b7f-4ef4-90fc-3dc94d3e8ddc
# 准备 web 主页
root@master30:~/nfs-storage# echo Hello World From Nginx > /shares/default-webclaim-pvc-6a020ff4-6b7f-4ef4-90fc-3dc94d3e8ddc/index.html2. 创建 deployment
bash
root@master30:~# cat > nfs-deploy.yaml << EOF
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: webapp
name: webapp
spec:
replicas: 2
selector:
matchLabels:
app: webapp
template:
metadata:
labels:
app: webapp
spec:
containers:
- image: nginx
name: nginx
volumeMounts:
- name: webapp-data
mountPath: /usr/share/nginx/html
volumes:
- name: webapp-data
persistentVolumeClaim:
claimName: webclaim
EOF
root@master30:~# kubectl apply -f nfs-deploy.yaml
root@master30:~# kubectl expose deployment webapp --target-port 80 --port 80 --protocol TCP
root@master30:~# kubectl get svc webapp
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
webapp ClusterIP 10.109.140.205 <none> 80/TCP 5m11s
# 访问测试
root@master30:~# curl 10.109.140.205
Hello World From Nginx
root@master30:~# curl 10.109.140.205
Hello World From Nginx3. 清理资源
bash
# 删除 deployment
root@master30:~# kubectl delete deployments.apps webapp
# 删除 pvc，pv也将一起删除
root@master30:~# kubectl delete pvc webclaim
persistentvolumeclaim "webclaim" deleted
root@master30:~# kubectl get pv
No resources found
# 查看后端存储中数据，仍然保留
root@master30:~# ls /shares/default-webclaim-pvc-6a020ff4-6b7f-4ef4-90fc-3dc94d3e8ddc/
index.html保留 NFS provisioner ，下一章 statefulset 使用。
Kubernetes StatefulSet
环境准备
bash
root@master30:~# kubectl create ns statefulset
root@master30:~# kubectl config set-context --current --namespace statefulset无状态应用 vs 有状态应用
| 维度 | 无状态应用（Stateless） | 有状态应用（Stateful） |
|---|---|---|
| 核心特征 | 不保存任何请求/会话数据，每次请求独立 | 依赖持久化的会话/数据，请求间有依赖关系 |
| 数据存储 | 数据仅在请求期间存在，不落地/仅落地外部存储 | 数据需持久化（本地/分布式存储），依赖固定存储 |
| 实例一致性 | 所有实例完全相同，可随意扩缩容/替换 | 实例有身份（如编号），启动/扩缩容有顺序要求 |
| 网络标识 | 共享 IP/域名，无固定网络标识 | 有固定网络标识（如 Headless Service + DNS） |
总结
- 无状态核心：实例"无记忆"，可随意替换/扩容，是云原生优先推荐的应用形态；
- 有状态核心：实例"有记忆"，依赖持久化和固定身份，需通过 StatefulSet 等组件保障稳定性；
- 最佳实践：尽可能将应用拆分为"无状态业务层 + 有状态数据层"，既提升扩展能力，又保障数据安全。
StatefulSet 介绍
StatefulSet 定义
StatefulSet 是 Kubernetes 中专门用于管理有状态应用 的工作负载资源，与用于管理无状态应用的 Deployment 相比，其核心优势在于为每个 Pod 分配固定且唯一的身份标识（包括名称、网络标识、存储关联），即便 Pod 发生重启、迁移或重建，其身份信息和绑定的存储资源也不会改变，确保有状态应用的稳定性和连续性。
适用场景：数据库（MySQL、PostgreSQL）、分布式中间件（Redis 集群、ZooKeeper）、消息队列（Kafka）等依赖节点身份和数据持久化的服务。
StatefulSet 特性
-
固定身份标识：每个 Pod 拥有唯一的序号（从 0 开始递增），hostname 固定为「StatefulSet 名称-序号」（如 mysql-0），同时通过 Headless Service 提供固定 DNS 解析（如 mysql-0.mysql.default.svc.cluster.local），便于集群内节点间稳定通信和服务发现。
-
有序操作：
-
部署/扩容：按序号从 0 到 N-1 依次创建 Pod，必须等待前一个 Pod 处于 Ready 状态后，再创建下一个，确保集群启动顺序符合业务依赖；
-
缩容/删除：按序号从 N-1 到 0 依次删除 Pod，前一个 Pod 彻底删除（Terminating 状态结束）后，再删除下一个，避免数据丢失或集群异常；
-
更新：默认按序号从 N-1 到 0 滚动更新，确保更新过程中集群始终保持可用，避免服务中断。
-
-
-
稳定存储 ：通过
PersistentVolumeClaim（PVC）模板为每个 Pod 自动创建独立的 PVC，PVC 名称与 Pod 序号绑定（格式：模板名-StatefulSet名称-序号）。即使 Pod 被删除，PVC 及绑定的 PersistentVolume（PV）仍会保留，重新创建的 Pod 会自动复用原 PVC 和 PV，实现数据不丢失。 -
Headless Service 依赖：StatefulSet 必须关联一个 Headless Service（ClusterIP 设为 None），该服务不提供负载均衡功能，仅负责为每个 Pod 提供固定的 DNS 解析，是 Pod 间稳定通信的核心前提。
StatefulSet VS Deployment
| 控制器 | StatefulSet | Deployment |
|---|---|---|
| 适用场景 | 有状态应用（数据库、分布式集群、消息队列） | 无状态应用（Web 服务、API 接口、静态服务） |
| 网络 | Headless Service（固定 DNS 解析） | ClusterIP/LoadBalancer（共享 IP） |
| 存储 | 必须 PVC + PV（固定存储卷绑定） | 可选 PVC（无数据持久化要求） |
| 扩缩容 | 按实例编号顺序扩缩容（如从 0→1→2） | 无顺序，瞬间完成 |
| 更新策略 | 有序更新（如从最后一个实例开始） | 滚动更新/重建，无顺序 |
| 重启/重建 | 实例重启后需恢复原有数据/身份 | 实例重启后无影响 |
StatefulSet 关键组件
- StatefulSet 控制器：Kubernetes 核心控制器之一，负责管理 Pod 的全生命周期，确保 Pod 按序号规则创建、更新、删除，维护 Pod 身份和存储的稳定性。
- Headless Service：核心作用是为 Pod 提供固定 DNS 解析，无 ClusterIP，仅负责将 Pod 名称映射为 DNS 记录，支持 Pod 间通过 hostname 稳定通信。
- PVC 模板：定义每个 Pod 所需的存储规格（如存储容量、访问模式），StatefulSet 会根据模板为每个 Pod 自动创建对应的 PVC，无需手动创建。
- PV（PersistentVolume）：实际的存储资源，与 PVC 一一绑定，为 Pod 提供持久化存储支持，可选用本地存储、云存储（AWS EBS、阿里云 EBS）、分布式存储（Ceph）等类型。
StatefulSet 实践操作
所有命令均在 statefulset 命名空间执行。
部署 NFS 服务器
bash
# 安装 NFS server
root@master30:~# apt install -y nfs-kernel-server
# 安创建NFS目录 修改创建文件夹的权限
root@master30:~# mkdir -m 777 -p /shares
# 配置共享，允许所有客户端访问
root@master30:~# cat << EOF >> /etc/exports
/shares *(rw,sync,no_root_squash,no_all_squash,insecure)
EOF
# 重启 nfs server
root@master30:~# systemctl restart nfs-server.service
# 客户端安装
root@worker31:~# apt install -y nfs-common
root@worker32:~# apt install -y nfs-common示例 1：部署 Nginx 集群
需求：部署 3 节点 Nginx 集群，实现数据持久化、固定网络标识、有序部署，满足高可用。
步骤 1：创建 StatefulSet
创建 nginx-statefulset.yaml，通过 PVC 模板自动创建存储。
yaml
root@master30:~# cat > nginx-statefulset.yaml <<'EOF'
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: nginx
spec:
selector:
matchLabels:
app: nginx
serviceName: "nginx"
replicas: 3
minReadySeconds: 10
template:
metadata:
labels:
app: nginx
spec:
terminationGracePeriodSeconds: 10
containers:
- name: nginx
image: docker.io/library/nginx:latest
ports:
- containerPort: 80
name: nginx
volumeMounts:
- name: nginx-data
mountPath: /usr/share/nginx/html
volumeClaimTemplates:
- metadata:
name: nginx-data
spec:
accessModes: [ "ReadWriteOnce" ]
# 使用上一章动态卷置备nfs Provider
storageClassName: "nfs-storage"
resources:
requests:
storage: 10Gi
EOF
# 创建 statefulset
root@master30:~# kubectl apply -f nginx-statefulset.yaml
# 查看 pods
root@master30:~# watch kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-0 1/1 Running 0 10m
nginx-1 1/1 Running 0 10m
nginx-2 1/1 Running 0 9m41s
# 预期输出：Pod 按 nginx-0、nginx-1、nginx-2顺序创建
# 先创建 nginx-0，处于 Running 状态
# 等待20s,再创建 nginx-1，处于 Running 状态
# 等待20s,再创建 nginx-2，处于 Running 状态
# 最终 3 个 Pod 均为 Running 状态。
# 查看 statefulset
root@master30:~# kubectl get sts
NAME READY AGE
nginx 3/3 10m
# 查看 pvc 创建和pv绑定过程（可选）
root@master30 ~# watch "kubectl get pvc| awk '{print $1,$3}'"
NAME VOLUME
nginx-data-nginx-0 pvc-8eb06bf1-a5de-4e94-bf83-514941f73c9f
nginx-data-nginx-1 pvc-e853eccd-8060-4326-8c45-0b88c34a3d97
nginx-data-nginx-2 pvc-27d944f7-1e62-4352-9023-3874e6867ef9步骤 2：准备 nfs 存储
bash
root@master30 ~# kubectl get pvc|awk '{print $1,$3}'
NAME VOLUME
nginx-data-nginx-0 pvc-8eb06bf1-a5de-4e94-bf83-514941f73c9f
nginx-data-nginx-1 pvc-e853eccd-8060-4326-8c45-0b88c34a3d97
nginx-data-nginx-2 pvc-27d944f7-1e62-4352-9023-3874e6867ef9
root@master30 ~# echo nginx-data-nginx-0 > /shares/statefulset-nginx-data-nginx-0-pvc-8eb06bf1-a5de-4e94-bf83-514941f73c9f/index.html
root@master30 ~# echo nginx-data-nginx-1 > /shares/statefulset-nginx-data-nginx-1-pvc-e853eccd-8060-4326-8c45-0b88c34a3d97/index.html
root@master30 ~# echo nginx-data-nginx-2 > /shares/statefulset-nginx-data-nginx-2-pvc-27d944f7-1e62-4352-9023-3874e6867ef9/index.html步骤 3：创建 Headless Service
创建 nginx-service.yaml，为后续 StatefulSet 管理的 Pod 提供固定名称。
yaml
root@master30:~# cat > nginx-service.yaml <<'EOF'
apiVersion: v1
kind: Service
metadata:
name: nginx
namespace: statefulset
spec:
selector:
app: nginx
clusterIP: None
ports:
- port: 80
targetPort: 80
name: nginx-port
EOF
# 创建服务
root@master30:~# kubectl apply -f nginx-service.yaml
# 没有 CLUSTER-IP
root@master30:~# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx ClusterIP None <none> 80/TCP 16m步骤 4：验证部署
bash
# 通过pod名称验证 pod 内容
root@master30 ~# kubectl run test --image nginx -it -- bash
If you don't see a command prompt, try pressing enter.
# pod名称后要加service后缀
root@test:/# curl nginx-0.nginx
nginx-data-nginx-0
root@test:/# curl nginx-1.nginx
nginx-data-nginx-1
root@test:/# curl nginx-2.nginx
nginx-data-nginx-2
# 删除 nginx-2，等待重新创
root@master30:~# kubectl delete pod nginx-2
root@master30:~# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-0 1/1 Running 0 49m
nginx-1 1/1 Running 0 49m
nginx-2 0/1 ContainerCreating 0 3s
# 新创建的pod的 IP 可能变化
# 验证 nginx-2 内容
root@master30 ~# kubectl exec test -it -- bash
If you don't see a command prompt, try pressing enter.
root@test:/# curl nginx-2.nginx
nginx-data-nginx-2
# 预期输出：数据仍存在，说明 PV/PVC 实现了数据持久化，Pod 重建后可复用存储。思考：如何为statefulset提供一个统一的IP入口呢？
答案：再创建一个普通的ClusterIP类型的service，暴漏statefulset。
bash
root@master30 ~# cat > nginx-service-www.yaml <<EOF
apiVersion: v1
kind: Service
metadata:
labels:
app: www
name: www
spec:
ports:
- name: 80-80
port: 80
protocol: TCP
targetPort: 80
selector:
app: nginx
type: ClusterIP
EOF
root@master30 ~# kubectl apply -f nginx-service-www.yaml
root@master30 ~# kubectl get svc www
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
www ClusterIP 10.100.163.95 <none> 80/TCP 20s
# 通过svc访问后端pod
root@master30 ~# curl 10.100.163.95
nginx-data-nginx-0
root@master30 ~# curl 10.100.163.95
nginx-data-nginx-1
root@master30 ~# curl 10.100.163.95
nginx-data-nginx-2步骤 5：清理环境
bash
root@master30:~# kubectl delete sts nginx
root@master30:~# kubectl delete svc nginx www
root@master30:~# kubectl delete pvc nginx-data-nginx-{0..2}
root@master30 ~# rm -fr /shares/statefulset-nginx-data-nginx-{0..2}-*
root@master30:~# kubectl delete pod test示例 2：部署 Etcd 集群
需求：部署 3 节点 etcd 集群，实现数据持久化、固定网络标识、有序部署，满足高可用。
步骤 1：准备 NFS 存储
bash
# 准备应用目录和文件
root@master30:~# mkdir -m 777 -p /shares/etcd/data-{0..2}步骤 2：创建 Headless Service
创建 etcd-service.yaml，为后续 StatefulSet 管理的 Pod 提供固定名称。
yaml
root@master30:~# cat > etcd-service.yaml <<'EOF'
apiVersion: v1
kind: Service
metadata:
name: etcd
namespace: statefulset
labels:
app: etcd
spec:
ports:
- port: 2379
name: client
- port: 2380
name: peer
clusterIP: None
selector:
app: etcd
EOF
# 创建服务
root@master30:~# kubectl apply -f etcd-service.yaml
# 没有 CLUSTER-IP
root@master30:~# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
etcd ClusterIP None <none> 2379/TCP,2380/TCP 5s步骤 3：创建 PV
创建 3个 PV，使用 NFS 存储（服务器地址10.1.8.30，共享目录/shares/），指定存储容量和回收策略。
yaml
root@master30:~# cat > etcd-pv.yaml <<'EOF'
apiVersion: v1
kind: PersistentVolume
metadata:
name: etcd-pv-0
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: etcd-storage
nfs:
server: 10.1.8.30
path: /shares/etcd/data-0
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: etcd-pv-1
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: etcd-storage
nfs:
server: 10.1.8.30
path: /shares/etcd/data-1
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: etcd-pv-2
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: etcd-storage
nfs:
server: 10.1.8.30
path: /shares/etcd/data-2
EOF
# 创建 pv
root@master30:~# kubectl apply -f etcd-pv.yaml
root@master30:~# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE
etcd-pv-0 10Gi RWO Retain Available etcd-storage <unset> 5s
etcd-pv-1 10Gi RWO Retain Available etcd-storage <unset> 5s
etcd-pv-2 10Gi RWO Retain Available etcd-storage <unset> 5s建议：使用动态卷制备。
步骤 4：创建 StatefulSet
创建 etcd-statefulset.yaml，通过 PVC 模板自动创建存储。
yaml
root@master30:~# cat > etcd-statefulset.yaml <<'EOF'
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: etcd
namespace: statefulset
spec:
serviceName: etcd
replicas: 3
selector:
matchLabels:
app: etcd
template:
metadata:
labels:
app: etcd
spec:
containers:
- name: etcd
image: registry.aliyuncs.com/google_containers/etcd:3.5.10-0
command:
- /usr/local/bin/etcd
ports:
- containerPort: 2379
name: client
- containerPort: 2380
name: peer
env:
- name: ETCD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: ETCD_DATA_DIR
value: /var/lib/etcd
- name: ETCD_INITIAL_ADVERTISE_PEER_URLS
value: "http://$(ETCD_NAME).etcd.statefulset.svc.cluster.local:2380"
- name: ETCD_LISTEN_PEER_URLS
value: "http://0.0.0.0:2380"
- name: ETCD_LISTEN_CLIENT_URLS
value: "http://0.0.0.0:2379"
- name: ETCD_ADVERTISE_CLIENT_URLS
value: "http://$(ETCD_NAME).etcd.statefulset.svc.cluster.local:2379"
- name: ETCD_INITIAL_CLUSTER
value: "etcd-0=http://etcd-0.etcd.statefulset.svc.cluster.local:2380,etcd-1=http://etcd-1.etcd.statefulset.svc.cluster.local:2380,etcd-2=http://etcd-2.etcd.statefulset.svc.cluster.local:2380"
- name: ETCD_INITIAL_CLUSTER_TOKEN
value: "etcd-token"
- name: ETCD_INITIAL_CLUSTER_STATE
value: "new"
volumeMounts:
- name: etcd-data
mountPath: /var/lib/etcd
resources:
requests:
cpu: 100m
memory: 256Mi
limits:
cpu: 500m
memory: 512Mi
volumeClaimTemplates:
- metadata:
name: etcd-data
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "etcd-storage"
resources:
requests:
storage: 10Gi
EOF
# 创建 statefulset
root@master30:~# kubectl apply -f etcd-statefulset.yaml
# 查看 pods
root@master30:~# kubectl get pods
NAME READY STATUS RESTARTS AGE
etcd-0 1/1 Running 0 77s
etcd-1 1/1 Running 0 74s
etcd-2 1/1 Running 0 71s
# 预期输出：Pod 按 etcd-0、etcd-1、etcd-2顺序创建
# 先创建 etcd-0，处于 Running 状态
# 再创建 etcd-1，处于 Running 状态
# 再创建 etcd-2，处于 Running 状态
# 最终 3 个 Pod 均为 Running 状态。
# 查看 statefulset
root@master30:~# kubectl get sts
NAME READY AGE
etcd 3/3 99s步骤 5：验证部署
验证集群状态
bash
# 验证集群状态：建立集群
root@master30:~# kubectl exec etcd-0 -- etcdctl member list
8747632212a8465, started, etcd-2, http://etcd-2.etcd.statefulset.svc.cluster.local:2380, http://etcd-2.etcd.statefulset.svc.cluster.local:2379, false
881e7c876792f042, started, etcd-0, http://etcd-0.etcd.statefulset.svc.cluster.local:2380, http://etcd-0.etcd.statefulset.svc.cluster.local:2379, false
b6d311da39fc1138, started, etcd-1, http://etcd-1.etcd.statefulset.svc.cluster.local:2380, http://etcd-1.etcd.statefulset.svc.cluster.local:2379, false
# 删除 etcd-2，等待重新创
root@master30:~# kubectl delete pod etcd-2
NAME READY STATUS RESTARTS AGE
etcd-0 1/1 Running 0 3m26s
etcd-1 1/1 Running 0 3m23s
etcd-2 1/1 Running 0 11s
# 验证集群状态：保持一直，etcd-2的ID也没有
root@master30:~# kubectl exec etcd-0 -- etcdctl member list
8747632212a8465, started, etcd-2, http://etcd-2.etcd.statefulset.svc.cluster.local:2380, http://etcd-2.etcd.statefulset.svc.cluster.local:2379, false
881e7c876792f042, started, etcd-0, http://etcd-0.etcd.statefulset.svc.cluster.local:2380, http://etcd-0.etcd.statefulset.svc.cluster.local:2379, false
b6d311da39fc1138, started, etcd-1, http://etcd-1.etcd.statefulset.svc.cluster.local:2380, http://etcd-1.etcd.statefulset.svc.cluster.local:2379, false验证数据
bash
root@master30:~# kubectl exec etcd-0 -- etcdctl put /users/user1/name laowang
OK
root@master30:~# kubectl exec etcd-2 -- etcdctl get /users/user1/name
/users/user1/name
laowang步骤 6：清理环境
bash
root@master30:~# kubectl delete sts etcd
root@master30:~# kubectl delete svc etcd
root@master30:~# kubectl delete pvc etcd-data-etcd-{0..2}
root@master30:~# kubectl delete pv etcd-pv-{0..2}
root@master30:~# rm -fr /shares/etcd示例 3：部署 Redis 集群
需求：部署 3 节点 Redis 集群（1 主 2 从），实现固定网络标识、数据持久化、集群自动组网，支持数据分片与故障自动切换，适用于高并发分布式缓存场景。
步骤 1：准备 NFS 存储
bash
# 准备应用目录
root@master30:~# mkdir -m 777 -p /shares/redis/data-{0..2}步骤 2：创建 Headless Service
创建 redis-service.yaml，为后续 StatefulSet 管理的 Pod 提供固定名称。
yaml
root@master30:~# cat > redis-service.yaml <<'EOF'
apiVersion: v1
kind: Service
metadata:
name: redis
namespace: statefulset
labels:
app: redis
spec:
ports:
- port: 6379
name: redis
- port: 26379
name: sentinel
clusterIP: None
selector:
app: redis
EOF
root@master30:~# kubectl apply -f redis-service.yaml
root@master30:~# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
redis ClusterIP None <none> 6379/TCP,26379/TCP 4s步骤 3：创建 PV
创建 3 个 PV，创建 redis-pv.yaml：
yaml
root@master30:~# cat > redis-pv.yaml <<'EOF'
apiVersion: v1
kind: PersistentVolume
metadata:
name: redis-pv-0
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: redis-storage
nfs:
server: 10.1.8.30
path: /shares/redis/data-0
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: redis-pv-1
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: redis-storage
nfs:
server: 10.1.8.30
path: /shares/redis/data-1
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: redis-pv-2
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: redis-storage
nfs:
server: 10.1.8.30
path: /shares/redis/data-2
EOF
root@master30:~# kubectl apply -f redis-pv.yaml
root@master30:~# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE
redis-pv-0 10Gi RWO Retain Available redis-storage <unset> 3s
redis-pv-1 10Gi RWO Retain Available redis-storage <unset> 3s
redis-pv-2 10Gi RWO Retain Available redis-storage <unset> 3s步骤 4：创建 StatefulSet
创建 redis-statefulset.yaml，部署 3 个 Redis 节点集群，实现集群自动组网。
yaml
root@master30:~# cat > redis-statefulset.yaml <<'EOF'
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: redis
namespace: statefulset
spec:
serviceName: redis
replicas: 3
selector:
matchLabels:
app: redis
template:
metadata:
labels:
app: redis
spec:
containers:
- name: redis
image: redis:7.0-alpine
ports:
- containerPort: 6379
name: redis
- containerPort: 26379
name: sentinel
command: ["/bin/sh", "-c"]
args:
- |
NODE_ID=$(hostname | awk -F'-' '{print $2}')
cat > /data/redis.conf << EOF
bind 0.0.0.0
protected-mode no
port 6379
dir /data
appendonly yes
requirepass "redis123"
masterauth "redis123"
EOF
if [ "$NODE_ID" != "0" ]; then
echo "replicaof redis-0.redis.statefulset.svc.cluster.local 6379" >> /data/redis.conf
fi
redis-server /data/redis.conf &
# 等待主节点域名解析成功
until nslookup redis-0.redis.statefulset.svc.cluster.local; do
echo "Waiting for DNS resolution..."
sleep 2
done
cat > /data/sentinel.conf << EOF
bind 0.0.0.0
protected-mode no
port 26379
sentinel resolve-hostnames yes
sentinel announce-hostnames yes
sentinel monitor mymaster redis-0.redis.statefulset.svc.cluster.local 6379 2
sentinel auth-pass mymaster redis123
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 10000
EOF
redis-sentinel /data/sentinel.conf
volumeMounts:
- name: redis-data
mountPath: /data
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 500m
memory: 512Mi
volumeClaimTemplates:
- metadata:
name: redis-data
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "redis-storage"
resources:
requests:
EOF
root@master30:~# kubectl apply -f redis-statefulset.yaml
root@master30:~# kubectl get pods
NAME READY STATUS RESTARTS AGE
redis-0 1/1 Running 0 4m49s
redis-1 1/1 Running 0 4m46s
redis-2 1/1 Running 0 4m44s
root@master30:~# kubectl get sts
NAME READY AGE
redis 3/3 4m52s步骤 5：验证部署
验证主从状态（redis-0 为主，2 个从节点）
bash
root@master30:~# kubectl exec -it redis-0 -- redis-cli -a redis123 info replication
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
# Replication
role:master
connected_slaves:2
slave0:ip=10.224.113.181,port=6379,state=online,offset=106182,lag=1
slave1:ip=10.224.19.24,port=6379,state=online,offset=106011,lag=1
master_failover_state:no-failover
master_replid:7048070355085a34084baef93981a849ae20db1c
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:106353
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:106353验证哨兵状态（能识别主节点）
bash
root@master30:~# kubectl exec -it redis-0 -n statefulset -- redis-cli -p 26379 sentinel master mymaster
1) "name"
2) "mymaster"
3) "ip"
4) "redis-0.redis.statefulset.svc.cluster.local"
5) "port"
6) "6379"
7) "runid"
8) "21cc9a4d3a506fa9b04734b62c22f051c7fb9806"
9) "flags"
10) "master"
11) "link-pending-commands"
12) "0"
13) "link-refcount"
14) "1"
15) "last-ping-sent"
16) "0"
17) "last-ok-ping-reply"
18) "43"
19) "last-ping-reply"
20) "43"
21) "down-after-milliseconds"
22) "5000"
23) "info-refresh"
24) "9677"
25) "role-reported"
26) "master"
27) "role-reported-time"
28) "461721"
29) "config-epoch"
30) "0"
31) "num-slaves"
32) "2"
33) "num-other-sentinels"
34) "2"
35) "quorum"
36) "2"
37) "failover-timeout"
38) "10000"
39) "parallel-syncs"
40) "1"验证集群数据分片与主从同步：
bash
## 在 redis-0（主节点）设置测试数据
root@master30:~# kubectl exec -it redis-0 -- redis-cli -a redis123 set test-key "redis-cluster-test"
## 在 redis-1（从节点）查看测试数据
root@master30:~# kubectl exec -it redis-1 -- redis-cli -a redis123 get test-key
"redis-cluster-test"验证集群故障切换。
bash
# 删除一个主节点（如 redis-0），模拟节点故障
root@master30:~# kubectl delete pod redis-0
# 等待 redis-0 重新创建，查看集群状态：redis-0 的 role 变更为 slave
root@master30:~# kubectl exec -it redis-0 -- redis-cli -a redis123 info replication
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
# Replication
role:slave
master_host:10.224.19.24
master_port:6379
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_read_repl_offset:210705
slave_repl_offset:210705
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:72c5eb5bf94433adb77857bea5d3c631841d5cfb
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:210705
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:209970
repl_backlog_histlen:736步骤 6：清理环境
bash
root@master30:~# kubectl delete svc redis
root@master30:~# kubectl delete sts redis
root@master30:~# kubectl delete pvc redis-data-redis-{0..2}
root@master30:~# kubectl delete pv redis-pv-{0..2}
root@master30:~# rm -fr /shares/redis/data-*/*示例 4：部署 Cassandra 集群
需求：部署 3 节点 Cassandra 集群，实现固定网络标识、数据持久化、集群自动组网，支持数据分片与故障自动切换，适用于高并发分布式缓存场景。
步骤 1：准备 NFS 存储
bash
# 准备应用目录
root@master30:~# mkdir -m 777 -p /shares/cassandra/data-{0..2}步骤 2：创建 Headless Service
创建 cassandra-service.yaml，为后续 StatefulSet 管理的 Pod 提供固定名称。
yaml
root@master30:~# cat > cassandra-service.yaml <<'EOF'
apiVersion: v1
kind: Service
metadata:
name: cassandra
namespace: statefulset
labels:
app: cassandra
spec:
ports:
- port: 9042
name: cql
- port: 7000
name: intra-node
clusterIP: None
selector:
app: cassandra
EOF
root@master30:~# kubectl apply -f cassandra-service.yaml
root@master30:~# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
cassandra ClusterIP None <none> 6379/TCP,26379/TCP 4s步骤 3：创建 PV
创建 3 个 PV，创建 cassandra-pv.yaml：
yaml
root@master30:~# cat > cassandra-pv.yaml <<'EOF'
apiVersion: v1
kind: PersistentVolume
metadata:
name: cassandra-pv-0
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: cassandra-storage
nfs:
server: 10.1.8.30
path: /shares/cassandra/data-0
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: cassandra-pv-1
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: cassandra-storage
nfs:
server: 10.1.8.30
path: /shares/cassandra/data-1
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: cassandra-pv-2
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: cassandra-storage
nfs:
server: 10.1.8.30
path: /shares/cassandra/data-2
EOF
root@master30:~# kubectl apply -f cassandra-pv.yaml
root@master30:~# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE
cassandra-pv-0 10Gi RWO Retain Available cassandra-storage <unset> 3s
cassandra-pv-1 10Gi RWO Retain Available cassandra-storage <unset> 3s
cassandra-pv-2 10Gi RWO Retain Available cassandra-storage <unset> 3s步骤 4：创建 StatefulSet
创建 cassandra-statefulset.yaml，部署 3 个 Redis 节点集群，实现集群自动组网。
yaml
root@master30:~# cat > cassandra-statefulset.yaml <<'EOF'
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: cassandra
namespace: statefulset
spec:
serviceName: cassandra
replicas: 3
selector:
matchLabels:
app: cassandra
template:
metadata:
labels:
app: cassandra
spec:
containers:
- name: cassandra
image: bitnami/cassandra:4.1.3
ports:
- containerPort: 9042
name: cql
- containerPort: 7000
name: intra-node
env:
- name: CASSANDRA_CLUSTER_NAME
value: "my-cassandra"
- name: CASSANDRA_SEEDS
value: "cassandra-0.cassandra.statefulset.svc.cluster.local"
- name: CASSANDRA_LISTEN_ADDRESS
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: CASSANDRA_BROADCAST_ADDRESS
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: CASSANDRA_BROADCAST_RPC_ADDRESS
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: CASSANDRA_RPC_ADDRESS
value: "0.0.0.0"
- name: CASSANDRA_NUM_TOKENS
value: "256"
- name: CASSANDRA_REPLICATION_FACTOR
value: "3"
volumeMounts:
- name: cassandra-data
mountPath: /bitnami/cassandra
resources:
requests:
cpu: 500m
memory: 2Gi
limits:
cpu: 1000m
memory: 4Gi
livenessProbe:
exec:
command: ["nodetool", "status"]
initialDelaySeconds: 60
periodSeconds: 10
readinessProbe:
exec:
command: ["cqlsh", "-e", "DESCRIBE KEYSPACES;"]
initialDelaySeconds: 30
periodSeconds: 5
volumeClaimTemplates:
- metadata:
name: cassandra-data
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "cassandra-storage"
resources:
requests:
storage: 10Gi
EOF
root@master30:~# kubectl apply -f cassandra-statefulset.yaml
root@master30:~# kubectl get pods
root@master30:~# kubectl get sts步骤 5：验证部署
-
验证 Redis 集群状态：
bash## 进入 cassandra-0 节点，查看集群整体信息 kubectl exec -it cassandra-0 -- cassandra-cli cluster info ## 查看集群节点列表（包含主从角色、节点 ID） kubectl exec -it cassandra-0 -- cassandra-cli cluster nodes ## 预期输出： ## `cluster info` 显示`cluster_state:ok`（集群正常）； ## `cluster nodes` 显示 6 个节点，其中 3 个为主节点（master），3 个为从节点（slave），每个主节点对应一个从节点。 -
验证集群数据分片与主从同步：
bash## 在 cassandra-0（主节点）设置测试数据 kubectl exec -it cassandra-0 -- cassandra-cli set test-key "cassandra-cluster-test" ## 查看该数据对应的从节点（根据 cluster nodes 结果确认，如 cassandra-3） kubectl exec -it cassandra-3 -- cassandra-cli get test-key ## 预期输出：查询结果为`"cassandra-cluster-test"，说明主从同步正常； ## 可在 cassandra-1、cassandra-2 主节点设置数据，验证分片功能（不同主节点存储不同分片的数据）。 -
验证集群故障切换：
bash## 删除一个主节点（如 cassandra-0），模拟节点故障 kubectl delete pod cassandra-0 -n default ## 等待 cassandra-0 重新创建，查看集群状态 kubectl get pods -n default -l app=cassandra kubectl exec -it cassandra-1 -- cassandra-cli cluster nodes ## 预期输出：cassandra-0 的从节点（如 cassandra-3）会自动切换为新的主节点，集群状态保持 `ok`，数据不丢失，实现故障自动恢复。
步骤 6：清理环境
示例 5：部署 MySQL 集群
需求：部署 2 节点 MySQL 集群，实现数据持久化、固定网络标识、有序部署，主从自动同步，满足数据库高可用需求。
步骤 1：准备 NFS 存储
bash
# 准备应用目录
root@master30:~# mkdir -m 777 -p /shares/mysql/data-{0,1}
# 重启 nfs server
root@master30:~# systemctl restart nfs-server.service步骤 2：创建 Headless Service
创建 mysql-service.yaml，为后续 StatefulSet 管理的 Pod 提供固定名称。
yaml
root@master30:~# cat > mysql-service.yaml <<'EOF'
apiVersion: v1
kind: Service
metadata:
name: mysql
namespace: statefulset
spec:
selector:
app: mysql ## 匹配 StatefulSet 管理的 Pod 标签
clusterIP: None ## 无头服务，ClusterIP 设为 None
ports:
- port: 3306
targetPort: 3306
name: mysql-port ## 端口名称，便于识别
EOF
# 创建服务
root@master30:~# kubectl apply -f mysql-service.yaml
# 没有 CLUSTER-IP
root@master30:~# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
mysql ClusterIP None <none> 3306/TCP 2s步骤 3：创建 PV
创建 2 个 PV（对应 2 个 MySQL 节点），使用 NFS 存储（服务器地址10.1.8.30，共享目录/shares/），指定存储容量和回收策略：
yaml
root@master30:~# cat > mysql-pv.yaml <<'EOF'
apiVersion: v1
kind: PersistentVolume
metadata:
name: mysql-pv-0 ## PV 名称，与后续 PVC 对应
spec:
capacity:
storage: 10Gi ## 存储容量，适配WordPress+MySQL存储需求
accessModes:
- ReadWriteOnce ## 仅允许单个 Pod 读写，保障MySQL数据一致性
persistentVolumeReclaimPolicy: Retain ## 回收策略：保留，删除 PVC 后 PV 仍存在
storageClassName: mysql-storage ## 存储类名称，需与 PVC 模板一致
nfs:
server: 10.1.8.30
path: /shares/mysql/data-0 ## 对应MySQL-0节点的NFS共享子目录（需在NFS服务器提前创建）
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: mysql-pv-1
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: mysql-storage
nfs:
server: 10.1.8.30 ## 同NFS服务器地址
path: /shares/mysql/data-1 ## 对应MySQL-1节点的NFS共享子目录（需提前创建）
EOF
# 创建 pv
root@master30:~# kubectl apply -f mysql-pv.yaml
# 查看 pv
root@master30:~# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE
mysql-pv-0 10Gi RWO Retain Available mysql-storage <unset> 4s
mysql-pv-1 10Gi RWO Retain Available mysql-storage <unset> 4s建议：使用动态卷制备。
步骤 4：创建 StatefulSet
创建 mysql-statefulset.yaml，通过 ConfigMap 挂载主从初始化脚本，通过 PVC 模板自动创建存储，实现主从自动配置：
yaml
root@master30:~# cat > mysql-statefulset.yaml <<'EOF'
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: mysql
namespace: statefulset
spec:
serviceName: mysql ## 关联上面创建的 Headless Service
replicas: 2 ## 2 个节点（1 主 1 从）
selector:
matchLabels:
app: mysql
template:
metadata:
labels:
app: mysql
spec:
containers:
- name: mysql
image: mysql:5.7
ports:
- containerPort: 3306
name: mysql
env:
- name: MYSQL_ROOT_PASSWORD
value: "123456"
volumeMounts:
- name: mysql-data ## 挂载存储卷，名称与 volumeClaimTemplates 一致
mountPath: /var/lib/mysql ## MySQL 数据存储路径
volumeClaimTemplates: ## PVC 模板，为每个 Pod 自动创建 PVC
- metadata:
name: mysql-data
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "mysql-storage" ## 与 PV 的 storageClassName 一致
resources:
requests:
storage: 10Gi ## 与 PV 容量匹配
EOF
# 创建 statefulset
root@master30:~# kubectl apply -f mysql-statefulset.yaml
# 查看 pods
root@master30:~# kubectl get pods
NAME READY STATUS RESTARTS AGE
mysql-0 1/1 Running 0 87s
mysql-1 1/1 Running 0 32s
# 预期输出：Pod 按 mysql-0、mysql-1 顺序创建
# mysql-0 先处于 Running 状态，再创建 mysql-1，最终两个 Pod 均为 Running 状态。
# 查看 statefulset
root@master30:~# kubectl get sts
NAME READY AGE
mysql 2/2 4m9s步骤 5：验证部署
bash
# 验证 pod 域名解析
root@master30:~# kubectl run test-pod --image busybox -- sleep 3600
root@master30:~/statefulset# kubectl exec test-pod -- ping -c2 mysql-1.mysql
PING mysql-1.mysql (10.224.113.148): 56 data bytes
64 bytes from 10.224.113.148: seq=0 ttl=62 time=1.586 ms
--- mysql-1.mysql ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 1.586/1.586/1.586 ms
# 创建测试数据
root@master30:~# kubectl exec -it mysql-1 -- mysql -u root -p123456 -e 'create database wordpress;'
# 删除 mysql-1 Pod，等待 mysql-1 重新创建
root@master30:~# kubectl delete pod mysql-1
root@master30:~# kubectl get pods mysql-1
NAME READY STATUS RESTARTS AGE
mysql-1 1/1 Running 0 82s
# 验证 pod 域名解析：IP地址变更
root@master30:~# kubectl exec test-pod -- ping -c1 mysql-1.mysql
PING mysql-1.mysql (10.224.113.149): 56 data bytes
64 bytes from 10.224.113.149: seq=0 ttl=62 time=0.584 ms
--- mysql-1.mysql ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.584/0.584/0.584 ms
# 查看数据是否保留
root@master30:~# kubectl exec -it mysql-1 -- mysql -u root -p123456 -e 'show databases;'
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| sys |
| wordpress |
+--------------------+
# 预期输出：数据仍存在，说明 PV/PVC 实现了数据持久化，Pod 重建后可复用存储。步骤 6：配置主从
-
进入主节点（mysql-0）
-
进入从节点（mysql-1）
mysql# 查看从节点同步状态：`SHOW SLAVE STATUS\G`， # 确认 `Slave_IO_Running` 和 `Slave_SQL_Running` 均为 Yes。
步骤 7：清理环境
bash
root@master30:~# kubectl delete svc mysql
root@master30:~# kubectl delete sts mysql
root@master30:~# kubectl delete pvc mysql-data-mysql-{0..1}
root@master30:~# kubectl delete pv mysql-pv-{0..1}
root@master30:~# rm -fr /shares/mysql/data-*/*StatefulSet 总结
-
生产环境中，敏感信息（如 MySQL 根密码、Redis 密码）需使用 Kubernetes Secret 管理，禁止明文写在 YAML 文件中，避免安全风险。
-
StatefulSet 缩容时，严格按序号从大到小删除 Pod，若需保留数据，建议提前备份 PV 中的数据，避免误操作导致数据丢失。
-
修改 StatefulSet 的 PVC 模板（如调整存储容量、修改
storageClassName）后，直接执行kubectl apply不会生效，需删除现有 PVC 和 Pod，重新创建（数据会保留，因 PV 为Retain策略）。 -
存储选型建议：当前已改为NFS存储（共享路径/shares/，适配WordPress+MySQL 5.7部署），测试环境可直接使用该NFS配置；生产环境建议选用高可用NFS集群或分布式存储（如Ceph），避免NFS单点故障，确保WordPress和MySQL 5.7数据高可用。
-
StatefulSet 不支持动态修改副本数以外的核心配置（如
serviceName、PVC 模板），若需修改，需删除 StatefulSet 后重新创建（Pod 和 PVC 可保留，数据不丢失）。