最新国产好看的视频,伊人天堂AV在线,国产Aaaaaa视频,蜜臀视频在线观看一区,人妻av色图,密臀久久久精品影片,青青视频免费观看毛片,久草在线观看视,国产三级精品色情在线

k8s配置文件用法詳解

 更新時(shí)間:2025年10月30日 17:31:14   作者:_BugMan  
文章主要介紹了Kubernetes中的命名空間、資源操作、Deployment、Service、Ingress、Secret、PersistentVolumeClaim、StatefulSet等核心概念和配置文件的使用方法

namespace

k8s中有命名空間這個(gè)概念,用來(lái)做資源隔離,k8s的所有資源操作,諸如get、delete等,都是要跟上-n參數(shù)來(lái)表示命名空間的,如果沒(méi)有跟這個(gè)參數(shù)默認(rèn)是操作的default這個(gè)命名空間。

工程實(shí)踐一般是測(cè)試環(huán)境一個(gè)namespace,正式環(huán)境一個(gè)namespace,用來(lái)進(jìn)行隔離避免誤操作。

namespace.yaml:

用來(lái)創(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:
      # 更新過(guò)程中可以額外創(chuàng)建的Pod數(shù)量(相對(duì)于replicas)
      maxSurge: 1
      # 更新過(guò)程中最多允許不可用的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 本身不使用這些信息來(lái)識(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 份舊的訂單記錄,方便以后出問(wèn)題時(shí)回退到之前的版本。

strategy定義應(yīng)用的副本數(shù)更新策略,確保高可用和平滑升級(jí)。

k8s原生支持兩種部署策略:

RollingUpdate,滾動(dòng)更新,、逐步用新版本的 Pod 替換舊版本的 Pod,實(shí)現(xiàn)服務(wù)的無(wú)中斷。可以通過(guò)以下兩個(gè)關(guān)鍵參數(shù)來(lái)控制更新的節(jié)奏和可用性:

  • maxUnavailable:指定在更新過(guò)程中不可用 Pod 的最大數(shù)量或比例。這保證了在更新時(shí)至少有一定數(shù)量的舊版 Pod 仍能處理請(qǐng)求。
  • maxSurge:指定在更新過(guò)程中可以創(chuàng)建的超出期望 Pod 數(shù)量的最大數(shù)量或比例。這允許在刪除舊 Pod 的同時(shí)提前啟動(dòng)一些新 Pod 以加速更新過(guò)程47。

Recreate,先一次性終止所有舊版本的 Pod,等待它們被完全刪除后,再啟動(dòng)所有新版本的 Pod,在更新過(guò)程中服務(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è)鏡像文件來(lái)安裝這個(gè)容器?—— `nginx` 軟件的 `1.25.2` 版本。
        ports:             #   這個(gè)容器開放了哪個(gè)端口?—— 80 端口。(這主要是說(shuō)明文檔,不影響實(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í)最多不能超過(guò)多少資源?
            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)備好接待客戶”?如果沒(méi)準(zhǔn)備好,就先不讓流量進(jìn)來(lái)。
          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è)追蹤器,它說(shuō)“我要管理所有帶 app=nginx 標(biāo)簽的 Pod”。而 template 里定義的 Pod 在出生時(shí)就會(huì)被貼上 app=nginx 的標(biāo)簽。這樣,Deployment 就知道哪些 Pod 是歸它管的了。

service

deployment.yaml用來(lái)聲明配置部署相關(guān)的內(nèi)容,service用來(lái)聲明配置網(wǎng)絡(luò)相關(guān)的配置:

配置完service的name后,k8s內(nèi)部的服務(wù)之間可以相互通過(guò)這個(gè)service的name來(lái)訪問(wèn),避免了IP動(dòng)態(tài)變化帶來(lái)的問(wèn)題,k8s內(nèi)部自帶一個(gè)CoreDNS組件用來(lái)解析域名。

# service.yaml
apiVersion: v1
kind: Service
metadata:
  name: order-service # Service 的名稱,配置名稱后可以用配置的名稱來(lái)訪問(wèn)服務(wù),從而擺脫對(duì)IP的強(qiáng)依賴
  namespace: default   # 可指定命名空間,不指定則默認(rèn)為 default
spec:
  type: NodePort       # 服務(wù)類型,此處為 NodePort,允許從外部訪問(wèn)
  selector:            # 標(biāo)簽選擇器,用于選擇擁有以下標(biāo)簽的 Pod
    app: orderserver   # 必須與你的 Pod 的標(biāo)簽匹配
  ports:
    - name: http       # 端口名稱,可自定義,多端口時(shí)必須唯一
      protocol: TCP    # 協(xié)議
      port: 80         # Service 自身的端口,在集群內(nèi)部通過(guò)此端口訪問(wèn)
      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)部可以訪問(wèn)的虛擬IP地址。
  • 用途:用于集群內(nèi)部的服務(wù)間通信。例如,前端Pod需要訪問(wèn)后端的API服務(wù)。這是最常用的類型。

NodePort:

  • 功能:在 ClusterIP 的基礎(chǔ)上,在每個(gè)Node(節(jié)點(diǎn))上打開一個(gè)靜態(tài)端口(NodePort)。訪問(wèn)任何Node的IP地址的這個(gè)NodePort,流量都會(huì)被自動(dòng)轉(zhuǎn)發(fā)到該Service,最終到達(dá)后端Pod。
  • 用途:用于從集群外部直接訪問(wèn)服務(wù)。它是實(shí)現(xiàn)外部訪問(wèn)的最基礎(chǔ)方式。

LoadBalancer:

  • 功能:在 NodePort的基礎(chǔ)上,利用云服務(wù)商(如AWS, GCP, Azure, 阿里云等)的負(fù)載均衡器。云商會(huì)自動(dòng)創(chuàng)建一個(gè)外部的負(fù)載均衡器,并分配一個(gè)外部IP地址,所有訪問(wèn)這個(gè)外部IP的流量都會(huì)均衡到各個(gè)節(jié)點(diǎn)的NodePort上。
  • 用途:在公有云上對(duì)外暴露服務(wù)的最佳方式,通常需要付費(fèi)。

k8s對(duì)service的訪問(wèn)自帶負(fù)載均衡的能力:

ingress

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

【question】為什么配置service后,還需要擴(kuò)展組件來(lái)對(duì)外暴露網(wǎng)絡(luò)?

【answer】核心組件和概念組件都可以理解為是對(duì)k8s內(nèi)部的,擴(kuò)展組件才是對(duì)外部的,由于k8s是個(gè)復(fù)雜的集群,需要核心組件來(lái)維持集群的內(nèi)部工作,所以核心組件是不對(duì)外的。

由于ingress是擴(kuò)展組件,需要先下載

Secret

secret用來(lái)存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ǔ)的一種抽象,用它來(lái)定義物理機(jī)上的一塊存儲(chǔ)。

持久卷聲明(PVC,PersistentVolumeClaim),可以理解為應(yīng)用對(duì)要用到的存儲(chǔ)的一種聲明。

持久卷(PV,PersistentVolume)和持久卷聲明(PVC,PersistentVolumeClaim)它們之間的關(guān)系可以概括為:PV 是集群中的實(shí)際存儲(chǔ)資源,由管理員提供;PVC 是用戶對(duì)存儲(chǔ)資源的請(qǐng)求通過(guò) PVC,用戶無(wú)需關(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  # 訪問(wèn)模式:?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  # 訪問(wèn)模式:?jiǎn)喂?jié)點(diǎn)讀寫
  resources:
    requests:
      storage: 10Gi  # 請(qǐng)求的存儲(chǔ)容量:10GB

pv需要關(guān)注的配置

accessModes,訪問(wèn)模式,節(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,無(wú)法被新的 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)用之間可以通過(guò)service的name來(lái)相互訪問(wèn),從而應(yīng)對(duì)IP動(dòng)態(tài)變化的問(wèn)題,但是無(wú)法解決有狀態(tài)集群的問(wèn)題。因?yàn)閟ervice會(huì)結(jié)合coreDNS將請(qǐng)求負(fù)載均衡的給service下的所有pod,無(wú)法區(qū)分出各個(gè)pod的角色,流量會(huì)均分給master和slove。這時(shí)候就要用StatefulSet來(lái)做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。無(wú)論這個(gè) Pod 被調(diào)度到哪個(gè)節(jié)點(diǎn),甚至重啟后IP地址變了,這個(gè)域名都保持不變,并且總會(huì)解析到它當(dāng)前唯一的 IP 地址。

這樣k8s集群中的應(yīng)用就可以用每個(gè)pod自己獨(dú)特的DNS來(lái)訪問(wèn)對(duì)應(yīng)pod了。

Headless Service (無(wú)頭服務(wù))

StatefulSet必須配合無(wú)頭服務(wù)(Headless Service),它不同于service的其他type,是一個(gè)特殊的service它不提供負(fù)載均衡,允許直接通過(guò) 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必須通過(guò)這個(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è)新的、用于外部訪問(wèn)的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

查看出了什么問(wèn)題:

deployment、service這些資源出于pending狀態(tài)等非running狀態(tài)一般都是pod啟動(dòng)失敗了,這時(shí)候要去查看pod出了什么問(wèn)題。

  • running狀態(tài)的pod可以通過(guò):kubectl logs -f <pod>來(lái)查看日志
  • 非running狀態(tài)的pod只能通過(guò):kubectl describe pod -n <namespace> <pod>來(lái)查看具體情況

總結(jié)

以上為個(gè)人經(jīng)驗(yàn),希望能給大家一個(gè)參考,也希望大家多多支持腳本之家。

相關(guān)文章

  • 在CentOS上如何安裝Singularity高性能容器

    在CentOS上如何安裝Singularity高性能容器

    Singularity是勞倫斯伯克利國(guó)家實(shí)驗(yàn)室專門為大規(guī)模、跨節(jié)點(diǎn)HPC和DL工作負(fù)載而開發(fā)的容器化技術(shù),具備輕量級(jí)、快速部署、方便遷移等優(yōu)勢(shì),且支持從Docker鏡像格式轉(zhuǎn)換為Singularity鏡像格式,本文給大家介紹在CentOS上如何安裝Singularity高性能容器,感興趣的朋友一起看看吧
    2024-05-05
  • Rainbond使用Dockerfile構(gòu)建便捷應(yīng)用運(yùn)行流程

    Rainbond使用Dockerfile構(gòu)建便捷應(yīng)用運(yùn)行流程

    這篇文章主要為大家介紹了Rainbond使用Dockerfile構(gòu)建便捷應(yīng)用運(yùn)行流程,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪
    2022-04-04
  • k8s鏡像拉取方式選擇imagePullPolicy問(wèn)題

    k8s鏡像拉取方式選擇imagePullPolicy問(wèn)題

    本文解釋了Kubernetes中imagePullPolicy字段的默認(rèn)拉取策略,包括Always、IfNotPresent和Never,幫助ubernetes如何根據(jù)鏡像的標(biāo)簽和摘要自動(dòng)設(shè)置imagePullPolicy字段,以及如何手動(dòng)更改已有資源的拉取策略
    2026-05-05
  • 一文詳解如何高效查看k8s日志

    一文詳解如何高效查看k8s日志

    K8S是kubernetes的縮寫,是為解決容器服務(wù)編排而生的,在運(yùn)維K8S服務(wù)的過(guò)程中,經(jīng)常會(huì)遇到各種報(bào)錯(cuò)和診斷問(wèn)題,那么我們一般怎么查看K8S組件的日志,這篇文章主要給大家介紹了關(guān)于如何高效查看k8s日志的相關(guān)資料,需要的朋友可以參考下
    2023-10-10
  • CentOS 7下YUM 本地倉(cāng)庫(kù)的搭建詳細(xì)步驟

    CentOS 7下YUM 本地倉(cāng)庫(kù)的搭建詳細(xì)步驟

    這篇文章主要介紹了CentOS 7下YUM 本地倉(cāng)庫(kù)的搭建詳細(xì)步驟的相關(guān)資料,希望通過(guò)本文能幫助到大家實(shí)現(xiàn)這樣的功能,需要的朋友可以參考下
    2017-09-09
  • k8s?常見面試題集錦

    k8s?常見面試題集錦

    這篇文章主要為大家介紹了k8s?常見面試題集錦,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪
    2023-09-09
  • k8s dashboard安裝過(guò)程記錄

    k8s dashboard安裝過(guò)程記錄

    這篇文章主要介紹了k8s dashboard安裝過(guò)程記錄,本案例k8s版本為v1.22.17,所以安裝v2.7.0版本的dashboard,需要的朋友可以參考下
    2024-05-05
  • 一篇文章讀懂K8S的PV和PVC以及實(shí)踐攻略

    一篇文章讀懂K8S的PV和PVC以及實(shí)踐攻略

    本文詳細(xì)介紹了Kubernetes中的存儲(chǔ)卷(Volume)機(jī)制,包括PersistentVolume(PV)、PersistentVolumeClaim(PVC)及其與后端存儲(chǔ)的關(guān)系,文中通過(guò)代碼介紹的非常詳細(xì),需要的朋友可以參考下
    2024-10-10
  • 二進(jìn)制方式安裝?Kubernetes1.18.3版本實(shí)現(xiàn)腳本

    二進(jìn)制方式安裝?Kubernetes1.18.3版本實(shí)現(xiàn)腳本

    這篇文章主要為大家介紹了二進(jìn)制方式安裝Kubernetes1.18.3版本實(shí)現(xiàn)腳本,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪
    2022-03-03
  • ES業(yè)務(wù)數(shù)據(jù)遷移遇到的精度問(wèn)題BUG

    ES業(yè)務(wù)數(shù)據(jù)遷移遇到的精度問(wèn)題BUG

    這篇文章主要為大家介紹了ES業(yè)務(wù)數(shù)據(jù)遷移遇到的BUG精度問(wèn)題,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪
    2022-06-06

最新評(píng)論

龙口市| 牟定县| 深圳市| 山阳县| 松原市| 敖汉旗| 玉龙| 安图县| 延寿县| 兴城市| 安新县| 阳谷县| 错那县| 洛川县| 海原县| 抚顺市| 佛学| 清原| 百色市| 平南县| 临泉县| 福清市| 沙坪坝区| 阳江市| 贵南县| 依兰县| 扶绥县| 鄂温| 大城县| 方山县| 永兴县| 宁波市| 五大连池市| 白山市| 曲麻莱县| 高陵县| 老河口市| 南华县| 中江县| 罗平县| 荥阳市|