k8s配置文件用法詳解
namespace
k8s中有命名空間這個(gè)概念,用來做資源隔離,k8s的所有資源操作,諸如get、delete等,都是要跟上-n參數(shù)來表示命名空間的,如果沒有跟這個(gè)參數(shù)默認(rèn)是操作的default這個(gè)命名空間。
工程實(shí)踐一般是測(cè)試環(huán)境一個(gè)namespace,正式環(huán)境一個(gè)namespace,用來進(jìn)行隔離避免誤操作。
namespace.yaml:
用來創(chuàng)建namespace,創(chuàng)建了后面就能用了。
apiVersion: v1 kind: Namespace metadata: name: db
deployment
部署發(fā)布命令:
kubectl apply -f eurekaserver-deployment.yaml
eurekaserver-deployment.yaml:
# 指定使用的Kubernetes API版本,Deployment資源屬于apps/v1版本
apiVersion: apps/v1
# 定義資源類型為Deployment,用于部署和管理Pod副本集
kind: Deployment
# 元數(shù)據(jù)部分,定義Deployment的基本信息
metadata:
# Deployment的名稱,在命名空間中必須唯一
name: eurekaserver
# 部署到的命名空間,默認(rèn)為default
namespace: default
# 標(biāo)簽集合,用于標(biāo)識(shí)和選擇此Deployment
labels:
# 應(yīng)用標(biāo)識(shí)標(biāo)簽
app: eurekaserver
# 環(huán)境標(biāo)識(shí)標(biāo)簽
environment: production
# 注解,用于存儲(chǔ)非識(shí)別性元數(shù)據(jù)
annotations:
# 描述信息
description: "Deployment for the main eurekaserver web server"
# 規(guī)格部分,定義Deployment的期望狀態(tài)
spec:
# 期望的Pod副本數(shù)量
replicas: 1
# Pod就緒后需要等待的秒數(shù)才被視為可用
minReadySeconds: 5
# 更新策略配置
strategy:
# 更新類型:RollingUpdate(滾動(dòng)更新)或Recreate(先刪除后創(chuàng)建)
type: RollingUpdate
# 滾動(dòng)更新具體配置
rollingUpdate:
# 更新過程中可以額外創(chuàng)建的Pod數(shù)量(相對(duì)于replicas)
maxSurge: 1
# 更新過程中最多允許不可用的Pod數(shù)量
maxUnavailable: 0
# 保留的舊ReplicaSet歷史記錄數(shù)量,用于回滾
revisionHistoryLimit: 5
# 標(biāo)簽選擇器,定義如何找到由該Deployment管理的Pod
selector:
matchLabels:
# 選擇所有擁有app: eurekaserver標(biāo)簽的Pod
app: eurekaserver
# Pod模板,定義Deployment創(chuàng)建的Pod的規(guī)格
template:
# Pod的元數(shù)據(jù)
metadata:
# Pod的標(biāo)簽,必須匹配上面的selector.matchLabels
labels:
app: eurekaserver
environment: production
# Pod的規(guī)格
spec:
# 容器列表
containers:
# 第一個(gè)容器定義
- name: eurekaserver # 容器名稱
image: eurekaserver:1.0 # 容器鏡像及標(biāo)簽
imagePullPolicy: IfNotPresent # 鏡像拉取策略: Always, IfNotPresent, Never
# 容器暴露的端口列表
ports:
- containerPort: 9001 # 容器內(nèi)監(jiān)聽的端口
protocol: TCP # 協(xié)議類型
# 環(huán)境變量列表
env:
- name: ENV_VAR_1 # 環(huán)境變量名稱
value: "value1" # 環(huán)境變量值
# 資源請(qǐng)求和限制
resources:
# 請(qǐng)求的資源量,調(diào)度器根據(jù)此值決定Pod放在哪個(gè)節(jié)點(diǎn)
requests:
cpu: "250m" # 250 milliCPU (0.25個(gè)CPU核心)
memory: "256Mi" # 256 Mebibytes
# 資源使用上限
limits:
cpu: "500m" # 500 milliCPU (0.5個(gè)CPU核心)
memory: "512Mi" # 512 Mebibytes
# 存活性探針,檢查容器是否還在正常運(yùn)行
livenessProbe:
httpGet: # 使用HTTP GET請(qǐng)求進(jìn)行檢查
path: / # 請(qǐng)求的路徑
port: 9001 # 請(qǐng)求的端口
initialDelaySeconds: 15 # 容器啟動(dòng)后等待多少秒才開始第一次探測(cè)
periodSeconds: 20 # 每次執(zhí)行探測(cè)的間隔時(shí)間(秒)
# 就緒性探針,檢查容器是否已準(zhǔn)備好接收流量
readinessProbe:
httpGet:
path: /
port: 9001
initialDelaySeconds: 5 # 容器啟動(dòng)后等待多少秒才開始第一次探測(cè)
periodSeconds: 10 # 每次執(zhí)行探測(cè)的間隔時(shí)間(秒)
# Pod內(nèi)容器的重啟策略,對(duì)于Deployment只能是Always
restartPolicy: Always
# 收到終止信號(hào)后,等待容器正常關(guān)閉的優(yōu)雅時(shí)間(秒)
terminationGracePeriodSeconds: 30可以把yaml文件想象成一份工廠的生產(chǎn)訂單。
頭文件
描述這是什么訂單?告訴 Kubernetes 這篇文章(YAML 文件)的類型和格式。
apiVersion: apps/v1 # -> 我們要使用 Kubernetes 的 "apps" 部門的 "v1" 版訂單格式。 kind: Deployment # -> 訂單的類型:我們要生產(chǎn)的是【一套可復(fù)制的應(yīng)用部署】,而不是單個(gè)產(chǎn)品(Pod)或一個(gè)服務(wù)(Service)。
元數(shù)據(jù)(metadata)
描述訂單的基本信息,定義這個(gè) Deployment 對(duì)象的身份信息,比如它叫什么、在哪、有什么標(biāo)簽。
metadata:
name: nginx-deployment # -> 這套部署的名字叫 "nginx-deployment"。這是它的唯一標(biāo)識(shí),后續(xù)操作(如更新、查看)都要用這個(gè)名字。
namespace: default # -> 把它部署到名為 "default" 的車間里。如果不指定,就默認(rèn)放這個(gè)車間。
labels: # -> 給這個(gè)訂單貼上個(gè)標(biāo)簽,方便以后篩選和查找。
app: nginx # 例如:貼上一個(gè) "app=nginx" 的標(biāo)簽。
annotations: # -> 給管理員看的備注信息,Kubernetes 本身不使用這些信息來識(shí)別對(duì)象。
description: "Deployment for the main NGINX web server" # 例如:備注一下這是給主服務(wù)器用的。規(guī)格(spec)
規(guī)格 (Spec),是最核心的部分,它定義了期望的應(yīng)用狀態(tài)。
strategy,定義了應(yīng)用的策略。
spec:
replicas: 3 # -> 我希望任何時(shí)候都保持有 3 個(gè)完全一樣的產(chǎn)品(Pod)在運(yùn)行。
strategy: # -> 當(dāng)需要升級(jí)產(chǎn)品時(shí),采用以下策略:
type: RollingUpdate # 【滾動(dòng)更新】:逐臺(tái)替換,保證服務(wù)不中斷。而不是【Recreate】:全部停機(jī)再更新。
rollingUpdate:
maxSurge: 1 # 更新時(shí),最多允許比 3 臺(tái)多 1 臺(tái)(即最多有 4 臺(tái)在運(yùn)行)。
maxUnavailable: 0 # 更新時(shí),最多允許 0 臺(tái)不可用(即必須保證至少有 3 臺(tái)隨時(shí)能服務(wù))。
revisionHistoryLimit: 5 # -> 保留 5 份舊的訂單記錄,方便以后出問題時(shí)回退到之前的版本。strategy定義應(yīng)用的副本數(shù)和更新策略,確保高可用和平滑升級(jí)。
k8s原生支持兩種部署策略:
RollingUpdate,滾動(dòng)更新,、逐步用新版本的 Pod 替換舊版本的 Pod,實(shí)現(xiàn)服務(wù)的無中斷??梢酝ㄟ^以下兩個(gè)關(guān)鍵參數(shù)來控制更新的節(jié)奏和可用性:
- maxUnavailable:指定在更新過程中不可用 Pod 的最大數(shù)量或比例。這保證了在更新時(shí)至少有一定數(shù)量的舊版 Pod 仍能處理請(qǐng)求。
- maxSurge:指定在更新過程中可以創(chuàng)建的超出期望 Pod 數(shù)量的最大數(shù)量或比例。這允許在刪除舊 Pod 的同時(shí)提前啟動(dòng)一些新 Pod 以加速更新過程47。
Recreate,先一次性終止所有舊版本的 Pod,等待它們被完全刪除后,再啟動(dòng)所有新版本的 Pod,在更新過程中服務(wù)會(huì)中斷一段時(shí)間。
Selector ,描述如何找到生產(chǎn)的產(chǎn)品。
selector: # -> 這是我的“產(chǎn)品篩選器”。
matchLabels: # 我管理的所有產(chǎn)品(Pod)都必須貼有下面這個(gè)標(biāo)簽。
app: nginx # 標(biāo)簽是 "app=nginx"。Kubernetes 會(huì)持續(xù)檢查,確保所有帶這個(gè)標(biāo)簽的 Pod 都是 3 個(gè)。Selector 建立 Deployment 和它管理的 Pod 之間的關(guān)聯(lián)關(guān)系。
template,定義單個(gè) Pod 是什么樣子。
Pod 的元數(shù)據(jù) (Template Metadata)
template: # -> 以下是一個(gè)產(chǎn)品的設(shè)計(jì)圖(Pod 模板)。
metadata:
labels: # -> 【必須】根據(jù)這張圖生產(chǎn)出的每一個(gè)產(chǎn)品,都要貼上這些標(biāo)簽。
app: nginx # 這個(gè)標(biāo)簽 `app: nginx` 必須和上面的 selector.matchLabels 完全一致!
environment: production # 還可以貼其他標(biāo)簽,比如標(biāo)注這是生產(chǎn)環(huán)境用的。template為每個(gè)Pod定義身份標(biāo)簽。這里的labels必須匹配上面 selector 的選擇條件。
Pod 的規(guī)格 (Template Spec)
spec: # -> 產(chǎn)品的詳細(xì)規(guī)格。
containers: # -> 這個(gè)產(chǎn)品里要安裝的【容器】(可以裝多個(gè))。
- name: nginx # 第一個(gè)容器的名字叫 "nginx"。
image: nginx:1.25.2 # 使用哪個(gè)鏡像文件來安裝這個(gè)容器?—— `nginx` 軟件的 `1.25.2` 版本。
ports: # 這個(gè)容器開放了哪個(gè)端口?—— 80 端口。(這主要是說明文檔,不影響實(shí)際網(wǎng)絡(luò))
- containerPort: 80
resources: # -> 【生產(chǎn)環(huán)境必填】這個(gè)容器最多能占用多少硬件資源?(防止它擠占其他容器的資源)
requests: # 最少需要多少資源才能開機(jī)?
cpu: "250m" # 需要 0.25 個(gè) CPU 核心。
memory: "64Mi" # 需要 64MB 內(nèi)存。
limits: # 運(yùn)行時(shí)最多不能超過多少資源?
cpu: "500m" # 最多能用 0.5 個(gè) CPU 核心。
memory: "128Mi" # 最多能用 128MB 內(nèi)存。
livenessProbe: # -> 【存活探針】—— 如何檢查這個(gè)容器是“死”是“活”?如果檢查失敗,就重啟它。
httpGet: # 檢查方法:發(fā)送一個(gè) HTTP GET 請(qǐng)求。
path: / # 請(qǐng)求的路徑是根目錄 "/"。
port: 80 # 請(qǐng)求的端口是 80。
initialDelaySeconds: 15 # 容器啟動(dòng)后,等 15 秒再執(zhí)行第一次檢查(給程序啟動(dòng)留出時(shí)間)。
readinessProbe: # -> 【就緒探針】—— 如何檢查這個(gè)容器是否“準(zhǔn)備好接待客戶”?如果沒準(zhǔn)備好,就先不讓流量進(jìn)來。
httpGet:
path: /
port: 80
initialDelaySeconds: 5 # 啟動(dòng)后 5 秒開始檢查。Template Spec是最核心的配置塊,定義了應(yīng)用本身——它是什么、需要什么資源、如何檢查它是否健康。
總結(jié)與類比
| 配置塊 | 類比 | 作用 |
|---|---|---|
| 文件頭 (apiVersion, kind) | 訂單部門 | 定義這是一個(gè)什么類型的訂單(Deployment 訂單)。 |
| 元數(shù)據(jù) (metadata) | 訂單抬頭 | 定義訂單名稱(name)、存放位置(namespace)和標(biāo)簽(labels)。 |
| 副本與策略 (replicas, strategy) | 生產(chǎn)要求 | 要生產(chǎn)多少份(replicas),以及如何更新?lián)Q代(strategy)。 |
| 標(biāo)簽選擇器 (selector) | 產(chǎn)品追蹤器 | 定義一個(gè)規(guī)則,如何找到由這個(gè)訂單生產(chǎn)的所有產(chǎn)品(Pod)。 |
| Pod 模板 (template) | 產(chǎn)品設(shè)計(jì)藍(lán)圖 | 核心中的核心。定義每一個(gè)產(chǎn)品(Pod)的具體規(guī)格,包括里面運(yùn)行什么程序(containers)、需要多少資源(resources)、如何檢查質(zhì)量(probes)。 |
最重要的關(guān)系:selector 就像一個(gè)追蹤器,它說“我要管理所有帶 app=nginx 標(biāo)簽的 Pod”。而 template 里定義的 Pod 在出生時(shí)就會(huì)被貼上 app=nginx 的標(biāo)簽。這樣,Deployment 就知道哪些 Pod 是歸它管的了。
service
deployment.yaml用來聲明配置部署相關(guān)的內(nèi)容,service用來聲明配置網(wǎng)絡(luò)相關(guān)的配置:
配置完service的name后,k8s內(nèi)部的服務(wù)之間可以相互通過這個(gè)service的name來訪問,避免了IP動(dòng)態(tài)變化帶來的問題,k8s內(nèi)部自帶一個(gè)CoreDNS組件用來解析域名。
# service.yaml
apiVersion: v1
kind: Service
metadata:
name: order-service # Service 的名稱,配置名稱后可以用配置的名稱來訪問服務(wù),從而擺脫對(duì)IP的強(qiáng)依賴
namespace: default # 可指定命名空間,不指定則默認(rèn)為 default
spec:
type: NodePort # 服務(wù)類型,此處為 NodePort,允許從外部訪問
selector: # 標(biāo)簽選擇器,用于選擇擁有以下標(biāo)簽的 Pod
app: orderserver # 必須與你的 Pod 的標(biāo)簽匹配
ports:
- name: http # 端口名稱,可自定義,多端口時(shí)必須唯一
protocol: TCP # 協(xié)議
port: 80 # Service 自身的端口,在集群內(nèi)部通過此端口訪問
targetPort: 9002 # 目標(biāo)端口,即 Pod 中容器實(shí)際監(jiān)聽的端口(你的應(yīng)用端口)
# nodePort: 30180 # 可選項(xiàng):手動(dòng)指定節(jié)點(diǎn)端口。若不指定,Kubernetes 會(huì)自動(dòng)分配一個(gè)spec.type,service的類型,包含以下幾種:
ClusterIP(默認(rèn)類型):
- 功能:為Service分配一個(gè)僅在集群內(nèi)部可以訪問的虛擬IP地址。
- 用途:用于集群內(nèi)部的服務(wù)間通信。例如,前端Pod需要訪問后端的API服務(wù)。這是最常用的類型。
NodePort:
- 功能:在
ClusterIP的基礎(chǔ)上,在每個(gè)Node(節(jié)點(diǎn))上打開一個(gè)靜態(tài)端口(NodePort)。訪問任何Node的IP地址的這個(gè)NodePort,流量都會(huì)被自動(dòng)轉(zhuǎn)發(fā)到該Service,最終到達(dá)后端Pod。 - 用途:用于從集群外部直接訪問服務(wù)。它是實(shí)現(xiàn)外部訪問的最基礎(chǔ)方式。
LoadBalancer:
- 功能:在 NodePort的基礎(chǔ)上,利用云服務(wù)商(如AWS, GCP, Azure, 阿里云等)的負(fù)載均衡器。云商會(huì)自動(dòng)創(chuàng)建一個(gè)外部的負(fù)載均衡器,并分配一個(gè)外部IP地址,所有訪問這個(gè)外部IP的流量都會(huì)均衡到各個(gè)節(jié)點(diǎn)的NodePort上。
- 用途:在公有云上對(duì)外暴露服務(wù)的最佳方式,通常需要付費(fèi)。
k8s對(duì)service的訪問自帶負(fù)載均衡的能力:

ingress
pod被分配到的IP地址是k8s集群內(nèi)部的ip地址,要對(duì)外暴露pod需要使用到ingress:

【question】為什么配置service后,還需要擴(kuò)展組件來對(duì)外暴露網(wǎng)絡(luò)?
【answer】核心組件和概念組件都可以理解為是對(duì)k8s內(nèi)部的,擴(kuò)展組件才是對(duì)外部的,由于k8s是個(gè)復(fù)雜的集群,需要核心組件來維持集群的內(nèi)部工作,所以核心組件是不對(duì)外的。
由于ingress是擴(kuò)展組件,需要先下載
Secret
secret用來存Base64編碼后的配置,只是對(duì)value做一個(gè)簡(jiǎn)單的Base64編碼,還是很容易被破解的,只是比明文好些罷了。
secret.yaml:
apiVersion: v1 kind: Secret metadata: name: mysecret type: Opaque data: username: YWxpY2U= # Base64 編碼后的值 password: UyFCXKpkJHpEc2I9
PersistentVolumeClaim
持久卷(PersistentVolume),可以理解為k8s對(duì)物理機(jī)存儲(chǔ)的一種抽象,用它來定義物理機(jī)上的一塊存儲(chǔ)。
持久卷聲明(PVC,PersistentVolumeClaim),可以理解為應(yīng)用對(duì)要用到的存儲(chǔ)的一種聲明。
持久卷(PV,PersistentVolume)和持久卷聲明(PVC,PersistentVolumeClaim)它們之間的關(guān)系可以概括為:PV 是集群中的實(shí)際存儲(chǔ)資源,由管理員提供;PVC 是用戶對(duì)存儲(chǔ)資源的請(qǐng)求通過 PVC,用戶無需關(guān)心底層存儲(chǔ)細(xì)節(jié),Kubernetes 會(huì)自動(dòng)為其綁定合適的 PV。
# ========================
# 持久卷(PV)配置
# ========================
apiVersion: v1 # Kubernetes API版本
kind: PersistentVolume # 資源類型:持久卷
metadata:
name: postgres-pv # 持久卷名稱
spec:
capacity:
storage: 10Gi # 存儲(chǔ)容量:10GB
accessModes:
- ReadWriteOnce # 訪問模式:?jiǎn)喂?jié)點(diǎn)讀寫[11](@ref)
persistentVolumeReclaimPolicy: Retain # 回收策略:保留(刪除PVC后PV保留)[11](@ref)
storageClassName: "" # 存儲(chǔ)類名稱(空字符串)
hostPath: # 使用節(jié)點(diǎn)本地目錄作為存儲(chǔ)[11](@ref)
path: /mnt/postgres-data # 節(jié)點(diǎn)上的主機(jī)路徑
---
# ========================
# 持久卷聲明(PVC)配置
# ========================
apiVersion: v1 # Kubernetes API版本
kind: PersistentVolumeClaim # 資源類型:持久卷聲明
metadata:
name: postgres-pvc # PVC名稱
namespace: db # 所屬命名空間
spec:
accessModes:
- ReadWriteOnce # 訪問模式:?jiǎn)喂?jié)點(diǎn)讀寫
resources:
requests:
storage: 10Gi # 請(qǐng)求的存儲(chǔ)容量:10GBpv需要關(guān)注的配置:
accessModes,訪問模式,節(jié)點(diǎn)以何種方式(讀寫或只讀)掛載該存儲(chǔ)卷。
- ReadWriteOnce (RWO):卷可以被單個(gè)節(jié)點(diǎn)以讀寫模式掛載,這是塊存儲(chǔ)(如 AWS EBS、GCP PD)或本地存儲(chǔ)(如
hostPath)的常見模式 - ReadOnlyMany (ROX):卷可以被多個(gè)節(jié)點(diǎn)以只讀模式掛載適用于需要被多個(gè)應(yīng)用實(shí)例同時(shí)讀取的靜態(tài)數(shù)據(jù)。
- ReadWriteMany (RWX):卷可以被多個(gè)節(jié)點(diǎn)以讀寫模式掛載文件存儲(chǔ)(如 NFS、CephFS)通常支持此模式適用于需要跨多個(gè) Pod 共享并寫入數(shù)據(jù)的應(yīng)用。
persistentVolumeReclaimPolicy,回收策略,
- Retain (保留):保持 PV 和其中的數(shù)據(jù)不變PV 狀態(tài)變?yōu)?
Released,無法被新的 PVC 綁定,需管理員手動(dòng)清理數(shù)據(jù)后,才能重新使用這是靜態(tài)配置 PV(如你的hostPath卷)時(shí)常用且安全的策略。 - Delete (刪除):自動(dòng)刪除 PV 對(duì)象以及后端存儲(chǔ)資源此策略通常由動(dòng)態(tài)供應(yīng)存儲(chǔ)的 StorageClass 使用(如云提供商中的存儲(chǔ)卷)
- hostPath,物理機(jī)上的實(shí)際存儲(chǔ)路基,
pvc需要關(guān)注的配置:
accessModes
- ReadWriteOnce (RWO):卷可以被單個(gè)節(jié)點(diǎn)以讀寫模式掛載,這是塊存儲(chǔ)(如 AWS EBS、GCP PD)或本地存儲(chǔ)(如
hostPath)的常見模式 - ReadOnlyMany (ROX):卷可以被多個(gè)節(jié)點(diǎn)以只讀模式掛載適用于需要被多個(gè)應(yīng)用實(shí)例同時(shí)讀取的靜態(tài)數(shù)據(jù)。
- ReadWriteMany (RWX):卷可以被多個(gè)節(jié)點(diǎn)以讀寫模式掛載文件存儲(chǔ)(如 NFS、CephFS)通常支持此模式適用于需要跨多個(gè) Pod 共享并寫入數(shù)據(jù)的應(yīng)用。
注意:pv和pvc的accessModes必須對(duì)齊。
StatefulSet
k8s集群中配置service后,應(yīng)用之間可以通過service的name來相互訪問,從而應(yīng)對(duì)IP動(dòng)態(tài)變化的問題,但是無法解決有狀態(tài)集群的問題。因?yàn)閟ervice會(huì)結(jié)合coreDNS將請(qǐng)求負(fù)載均衡的給service下的所有pod,無法區(qū)分出各個(gè)pod的角色,流量會(huì)均分給master和slove。這時(shí)候就要用StatefulSet來做pod的狀態(tài)管理。
StatefulSet可以給pod:
有序創(chuàng)建和命名: StatefulSet 中的 Pod 是按順序(從 0 到 N-1)創(chuàng)建和擴(kuò)展的。每個(gè) Pod 會(huì)獲得一個(gè)固定的名稱:<statefulset-name>-<ordinal-index>。
- 例如,一個(gè)名為
mysql的 StatefulSet 的三個(gè) Pod 將被命名為mysql-0,mysql-1,mysql-2。
穩(wěn)定的DNS主機(jī)名: 每個(gè) Pod 都會(huì)基于其名稱和 Headless Service 獲得一個(gè)唯一的、穩(wěn)定的 DNS 域名。
- 格式:
<pod-name>.<service-name>.<namespace>.svc.cluster.local - 示例:Pod
mysql-0的完整域名為mysql-0.mysql.default.svc.cluster.local。無論這個(gè) Pod 被調(diào)度到哪個(gè)節(jié)點(diǎn),甚至重啟后IP地址變了,這個(gè)域名都保持不變,并且總會(huì)解析到它當(dāng)前唯一的 IP 地址。
這樣k8s集群中的應(yīng)用就可以用每個(gè)pod自己獨(dú)特的DNS來訪問對(duì)應(yīng)pod了。
Headless Service (無頭服務(wù))
StatefulSet必須配合無頭服務(wù)(Headless Service),它不同于service的其他type,是一個(gè)特殊的service它不提供負(fù)載均衡,允許直接通過 DNS 發(fā)現(xiàn)所有 Pod 的個(gè)體地址。
apiVersion: v1
kind: Service
metadata:
name: mysql # 這個(gè)名稱會(huì)被用于Pod的DNS域名
spec:
clusterIP: None # 這就是Headless Service的定義
selector:
app: mysql
ports:
- port: 3306
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: mysql
spec:
serviceName: "mysql" # StatefulSet必須通過這個(gè)字段知道它屬于哪個(gè)Headless Service
replicas: 3
selector:
matchLabels:
app: mysql
template:
metadata:
labels:
app: mysql
spec:
containers:
- name: mysql
image: mysql:8.0
...
volumeClaimTemplates: # 存儲(chǔ)卷聲明模板
- metadata:
name: data # PVC的名稱會(huì)是 `data-mysql-0`, `data-mysql-1`, etc.
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "fast-ssd" # 指定存儲(chǔ)類,由管理員提供
resources:
requests:
storage: 20Gi如何把master精準(zhǔn)的暴露出去:
一個(gè)pod可以有多個(gè)service,所以為Master Pod創(chuàng)建獨(dú)立的NodePort Service即可
識(shí)別并標(biāo)記您的Master Pod 首先,確保您的Master Pod有一個(gè)唯一標(biāo)簽,以便Service可以精確選中它。通常,StatefulSet中的第一個(gè)Pod(如 mysql-0)是主節(jié)點(diǎn)。 您可以給它打上一個(gè) role: master 的標(biāo)簽:
kubectl label pod mysql-0 role=master
創(chuàng)建NodePort Service 編寫一個(gè)YAML文件(例如 mysql-master-svc.yaml),創(chuàng)建一個(gè)新的Service,其選擇器(selector)精確匹配帶有 role=master 標(biāo)簽的Pod。
apiVersion: v1
kind: Service
metadata:
name: mysql-master-external # 這是一個(gè)新的、用于外部訪問的Service
spec:
type: NodePort # 關(guān)鍵:類型為NodePort,用于對(duì)外暴露
selector:
app: mysql # 必須匹配您的Pod標(biāo)簽
role: master # 關(guān)鍵:只選擇Master Pod,確保流量不會(huì)跑到從節(jié)點(diǎn)
ports:
- protocol: TCP
port: 3306 # Service監(jiān)聽的端口
targetPort: 3306 # Pod上的端口
# nodePort: 30000 # 可選:指定一個(gè)NodePort端口(范圍30000-32767)。不指定則隨機(jī)分配。應(yīng)用這個(gè)配置:
kubectl apply -f mysql-master-svc.yaml
運(yùn)維
查看pod的ip:
kubectl get pods -o wide

kubectl get deployment <deployment-name> -n <namespace> -o yaml
查看出了什么問題:
deployment、service這些資源出于pending狀態(tài)等非running狀態(tài)一般都是pod啟動(dòng)失敗了,這時(shí)候要去查看pod出了什么問題。
- running狀態(tài)的pod可以通過:kubectl logs -f <pod>來查看日志
- 非running狀態(tài)的pod只能通過:kubectl describe pod -n <namespace> <pod>來查看具體情況
總結(jié)
以上為個(gè)人經(jīng)驗(yàn),希望能給大家一個(gè)參考,也希望大家多多支持腳本之家。
相關(guān)文章
k8s編排之Deployment知識(shí)點(diǎn)詳解
這篇文章主要為大家介紹了k8s編排之Deployment知識(shí)點(diǎn)詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2023-01-01
k8s?Service?實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)和負(fù)載均衡
這篇文章主要為大家介紹了k8s?Service?實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)和負(fù)載均衡的工作原理及使用方式詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2023-04-04
云原生技術(shù)kubernetes之volumes容器的使用
這篇文章主要為大家介紹了云原生技術(shù)kubernetes之volumes容器使用方式,?有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2022-03-03
使用kubeadm部署kubernetes1.27.1版本教程
文章概述了K8s集群搭建的準(zhǔn)備與兩種部署方式:kubeadm(快速)和二進(jìn)制(手動(dòng)),涵蓋單master配置、硬件要求、網(wǎng)絡(luò)設(shè)置及初始化流程,適用于測(cè)試環(huán)境,提供參考經(jīng)驗(yàn)2025-08-08
基于openEuler的Ceph分布式存儲(chǔ)集群部署指南
本文詳細(xì)介紹了如何在openEuler22.03LTS操作系統(tǒng)上部署Ceph分布式存儲(chǔ)集群,包括環(huán)境準(zhǔn)備、軟件倉庫配置、集群初始化、存儲(chǔ)節(jié)點(diǎn)部署、存儲(chǔ)池創(chuàng)建、監(jiān)控集成和性能優(yōu)化等步驟,感興趣的朋友一起看看吧2025-03-03
關(guān)于k8s?使用?Service?控制器對(duì)外暴露服務(wù)的問題
這篇文章主要介紹了k8s使用Service控制器對(duì)外暴露服務(wù),包括部署deploy,部署?service及查看?service?和?pod?的關(guān)系,本文給大家介紹的非常詳細(xì),需要的朋友可以參考下2022-03-03

