Kubernetes

簡介

  • Kubernetes(通常稱為k8s)是一個以容器為中心的基礎架構,可以實現在物理集群或虛擬機集群上調度和運行容器,提供容器自動部署、擴展和管理的開源平臺.滿足了應用程序在生產環(huán)境中的一些通用需求:應用實例副本、水平自動擴展、命名與發(fā)現、負載均衡、滾動升級、資源監(jiān)控等

特點

  • 可移植:支持公有云,私有云,混合云、多重云
  • 可擴展:模塊化、插件化、可掛載、可組合
  • 自動化:自動部署、自動重啟、自動復制、自動伸縮/擴展
  • 快速部署應用,快速擴展應用
  • 無縫對接新的應用功能
  • 節(jié)省資源,優(yōu)化硬件資源的使用

核心組件

  • Kubernetes遵循master-slave architecture.Kubernetes的組件可分為管理單個的node組件和控制平面的一部分組件
  • Kubernetes Master是集群的主要控制單元,用于管理其工作負載并指導整個系統的通信.Kubernetes控制平面由各自的進程組成,每個組件都可以在單個主節(jié)點上運行,也可以支持high-architecture clusters的多個主節(jié)點上運行
組件 說明
etcd 保存了整個集群的狀態(tài)
apiserver 提供了資源操作的唯一入口,并提供認證、授權、訪問控制、API注冊和發(fā)現等機制
controller manager 負責維護集群的狀態(tài),比如故障檢測、自動擴展、滾動更新等
scheduler 負責資源的調度,按照預定的調度策略將Pod調度到相應的機器上
kubelet 負責維護容器的生命周期,同時也負責Volume(CVI)和網絡(CNI)的管理
Container runtime 負責鏡像管理以及Pod和容器的真正運行(CRI)
kube-proxy 負責為Service提供cluster內部的服務發(fā)現和負載均衡
image.png
image.png
  • Add-ons
組件 說明
kube-dns 負責為整個集群提供DNS服務
Ingress Controller 為服務提供外網入口
Heapster 提供資源監(jiān)控
Dashboard 提供GUI
Federation 提供跨可用區(qū)的集群
Fluentd-elasticsearch 提供集群日志采集、存儲與查詢

部署Kubernetes

架構

角色 IP 主機名
master 10.0.0.111/172.16.12.111 k8s_master
node01 10.0.0.112/172.16.12.112 k8s_node01
node02 10.0.0.113/172.16.12.113 k8s_node02
master節(jié)點
  • 在master設置hosts解析
[root@k8s_master ~]# cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

10.0.0.11 k8s_master
10.0.0.12 k8s_node01
10.0.0.13 k8s_node02
  • 安裝軟件包
[root@k8s_master ~]# yum install etcd docker kubernetes flannel -y
[root@k8s_node01 ~]# yum install docker kubernetes flannel -y
[root@k8s_node02 ~]# yum install docker kubernetes flannel -y
  • 修改配置
    • yum安裝的etcd默認配置文件在/etc/etcd/etcd.conf
[root@k8s_master ~]# grep -Ev "^$|#" /etc/etcd/etcd.conf
ETCD_DATA_DIR="/var/lib/etcd/default.etcd"
ETCD_LISTEN_CLIENT_URLS="http://0.0.0.0:2379"
ETCD_NAME="default"
ETCD_ADVERTISE_CLIENT_URLS="http://10.0.0.111:2379"
  • 啟動etcd
[root@k8s_master ~]# systemctl start etcd
[root@k8s_master ~]# systemctl enable etcd
  • 測試etcd
[root@k8s_master ~]# etcdctl -C http://10.0.0.111:2379 cluster-health
member 8e9e05c52164694d is healthy: got healthy result from http://10.0.0.111:2379
cluster is healthy
  • 配置并啟動kubernetes
# /etc/kubernetes/apiserver配置文件內容
[root@k8s_master ~]# grep -Ev "^$|#" /etc/kubernetes/apiserver 
KUBE_API_ADDRESS="--insecure-bind-address=0.0.0.0"
KUBE_API_PORT="--port=8080"
KUBE_ETCD_SERVERS="--etcd-servers=http://10.0.0.111:2379"
KUBE_SERVICE_ADDRESSES="--service-cluster-ip-range=10.254.0.0/16"
KUBE_ADMISSION_CONTROL="--admission-control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ServiceAccount,ResourceQuota"
KUBE_API_ARGS=""

# /etc/kubernetes/config配置文件內容
[root@k8s_master ~]# grep -Ev "^$|#" /etc/kubernetes/config 
KUBE_LOGTOSTDERR="--logtostderr=true"
KUBE_LOG_LEVEL="--v=0"
KUBE_ALLOW_PRIV="--allow-privileged=false"
KUBE_MASTER="--master=http://10.0.0.111:8080"
  • 啟動服務
[root@k8s_master ~]# systemctl start kube-apiserver.service 
[root@k8s_master ~]# systemctl enable kube-apiserver.service 

[root@k8s_master ~]# systemctl start kube-controller-manager.service 
[root@k8s_master ~]# systemctl enable kube-controller-manager.service 

[root@k8s_master ~]# systemctl start kube-scheduler.service 
[root@k8s_master ~]# systemctl enable kube-scheduler.service
node節(jié)點
  • 部署配置node
# node01 /etc/kubernetes/config配置文件內容
[root@k8s_node01 ~]# grep -Ev "^$|#" /etc/kubernetes/config 
KUBE_LOGTOSTDERR="--logtostderr=true"
KUBE_LOG_LEVEL="--v=0"
KUBE_ALLOW_PRIV="--allow-privileged=false"
KUBE_MASTER="--master=http://10.0.0.111:8080"

# node01 /etc/kubernetes/kubelet配置文件內容
[root@k8s_node01 ~]# grep -Ev "^$|#" /etc/kubernetes/kubelet 
KUBELET_ADDRESS="--address=0.0.0.0"
KUBELET_HOSTNAME="--hostname-override=10.0.0.112"
KUBELET_API_SERVER="--api-servers=http://10.0.0.111:8080"
KUBELET_POD_INFRA_CONTAINER="--pod-infra-container-image=registry.access.redhat.com/rhel7/pod-infrastructure:latest"
KUBELET_ARGS=""

# node02 /etc/kubernetes/config配置文件內容
[root@k8s_node02 ~]# grep -Ev "^$|#" /etc/kubernetes/config 
KUBE_LOGTOSTDERR="--logtostderr=true"
KUBE_LOG_LEVEL="--v=0"
KUBE_ALLOW_PRIV="--allow-privileged=false"
KUBE_MASTER="--master=http://10.0.0.111:8080"
# node02 /etc/kubernetes/kubelet配置文件內容
[root@k8s_node02 ~]# grep -Ev "^$|#" /etc/kubernetes/kubelet 
KUBELET_ADDRESS="--address=0.0.0.0"
KUBELET_HOSTNAME="--hostname-override=10.0.0.113"
KUBELET_API_SERVER="--api-servers=http://10.0.0.111:8080"
KUBELET_POD_INFRA_CONTAINER="--pod-infra-container-image=registry.access.redhat.com/rhel7/pod-infrastructure:latest"
KUBELET_ARGS=""
  • 啟動
[root@k8s_node01 ~]# systemctl start kubelet.service 
[root@k8s_node01 ~]# systemctl enable kubelet.service 
[root@k8s_node01 ~]# systemctl start kube-proxy.service 
[root@k8s_node01 ~]# systemctl enable kube-proxy.service

[root@k8s_node02 ~]# systemctl start kubelet.service 
[root@k8s_node02 ~]# systemctl enable kubelet.service 
[root@k8s_node02 ~]# systemctl start kube-proxy.service 
[root@k8s_node02 ~]# systemctl enable kube-proxy.service
  • 在master上查看集群中節(jié)點及節(jié)點狀態(tài)
[root@k8s_master ~]# kubectl -s http://10.0.0.111:8080 get node
NAME         STATUS    AGE
10.0.0.112   Ready     1m
10.0.0.113   Ready     2m

[root@k8s_master ~]# kubectl get nodes
NAME         STATUS    AGE
10.0.0.112   Ready     2m
10.0.0.113   Ready     2m
創(chuàng)建覆蓋網絡--Flannel
  • 配置Flannel(所有節(jié)點操作)
[root@k8s_node02 ~]# grep "^[a-Z]" /etc/sysconfig/flanneld 
FLANNEL_ETCD_ENDPOINTS="http://10.0.0.111:2379"
FLANNEL_ETCD_PREFIX="/atomic.io/network"
  • 配置etcd中關于Flannel的key
    • Flannel使用Etcd進行配置,來保證多個Flannel實例之間的配置一致性,所以需要在etcd上進行配置
    • /atomic.io/network/config與/etc/sysconfig/flanneld中的FLANNEL_ETCD_PREFIX="/atomic.io/network"是相對應的
# 操作創(chuàng)建網絡
[root@k8s_master ~]# vim /etc/sysconfig/flanneld
[root@k8s_master ~]# etcdctl mk /atomic.io/network/config '{"Network":"172.16.0.0/16"}'
{"Network":"172.16.0.0/16"}

# master節(jié)點操作
[root@k8s_master ~]# systemctl enable flanneld.service
[root@k8s_master ~]# systemctl start flanneld.service 
[root@k8s_master ~]# systemctl restart docker
[root@k8s_master ~]# systemctl restart kube-apiserver.service 
[root@k8s_master ~]# systemctl restart kube-controller-manager.service 
[root@k8s_master ~]# systemctl restart kube-scheduler.service

# node節(jié)點操作
[root@k8s_node01 ~]# systemctl enable flanneld.service 
[root@k8s_node01 ~]# systemctl start flanneld.service 
[root@k8s_node01 ~]# systemctl restart docker
[root@k8s_node01 ~]# systemctl restart kubelet.service 
[root@k8s_node01 ~]# systemctl restart kube-proxy.service

Kubernetes其他安裝方法

Kubernetes核心概念

Pod

  • Pod是Kubernetes的基本操作單元,也是應用運行的載體.整個Kubernetes系統都是圍繞著Pod展開的,比如如何部署運行Pod、如何保證Pod的數量、如何訪問Pod等
image.png

基本操作

操作 指令
創(chuàng)建 kubectl create -f xxx.yaml
查詢 kubectl get yourPodName;kubectl describe pod youPodNAme
刪除 kubectl delete pod yourPodName
更新 kubectl replace /path/to/yourPodName

Pod與容器

  • 在Docker中,容器是最小的處理單元,增刪改查的對象是容器,容器是一種虛擬化技術,容器之間是隔離的,隔離是基于Linux Namespace實現的.而在kubernetes中,Pod包含一個或者多個相關的容器,Pod可以認為是容器的一種延伸,一個Pod也是一個隔離體,而Pod內部包含的一組容器又是共享的(包括PID、Network、IPC、UTS).除此之外,Pod中的容器可以訪問共同的數據卷來實現文件系統的共享

鏡像

  • 在kubernetes中,鏡像的下載策略為
    • Always:每次都下載最新的鏡像
    • Never:只使用本地鏡像,從不下載
    • IfNotPresent:只有當本地沒有的時候才下載鏡像
  • Pod被分配到Node之后會根據鏡像下載策略進行下載鏡像,可以根據自身集群的特點來決定采用何種下載策略.無論何種策略,都要確保Node上有正確的鏡像可用

其他設置

  • 通過yaml文件,可以在Pod中設置:
    • 啟動命令:spec-->containers-->command
    • 環(huán)境變量:spec-->containers-->env-->name/value
    • 端口橋接:spec-->containers-->ports-->containerPort/Protocol/hostIP/hostPort(使用hostPort時需要注意端口沖突的問題,不過kubernetes在調度Pod的時候回檢查宿主機端口是否沖突,比如當兩個Pod均要求綁定宿主機的80端口,kubernetes會將這兩個Pod分別調度到不同的機器上)
    • Host網絡:一些特殊場景下,容器必須要以host方式進行網絡設置(如接收物理機網絡才能夠接收到的組播流),在Pod中也支持host網絡的設置,spec-->hostNetwork=true
    • 數據持久化:spec-->containers-->volumeMounts-->mountPath
    • 重啟策略:當Pod中的容器終止退出后,重啟容器的策略.這里的Pod重啟,實際上的做法是容器的重建,之前容器中的數據將會丟失,如果需要持久化數據,那么需要使用數據卷進行持久化設置.Pod支持三種重啟策略
      • Always(默認策略,當容器終止退出后,總是重啟容器)
      • OnFailure(當容器終止且異常退出時,重啟)
      • Never(從不重啟)

Replication Controller

  • Replication Controller(RC)是Kubernetes的另一個核心概念,應用托管在Kubernetes之后,Kubernetes需要保證應用能夠持續(xù)運行,這是RC的工作內容,它會確保任何時間Kubernetes中都有指定數量的Pod在運行.在此基礎上,RC還提供了一些更高級的特性,比如滾動升級、升級回滾等

RC與Pod的關聯

  • RC與Pod的關聯是通過Label來實現的.Label機制是Kubernetes中的一個重要設計,通過Label進行對象的弱關聯,可以靈活地進行分類和選擇.對于Pod,需要設置其自身的Label來進行標識,Label是一些了的key/value對,在Pod-->metadata-->labeks中進行設置
  • Lable的定義時任意的,但是Label必須具有可標識性,比如設置Pod的應用名稱和版本號等.另外Label是不具有唯一性的,為了更準確的標識一個Pod,應該為Pod設置多個維度的Label
"release":"stable","release":"canary"
"environment":"dev","environment":"prod"
  • 當在RC的yaml文件中定義了該RC的selector中的label為app:myweb,那么這個RC就會去關注Pod-->metadata-->labeks中l(wèi)abel為app:myweb的Pod.修改了對應Pod的Label,就會使Pod脫離RC的控制.同樣,在RC運行正常的時候,若試圖繼續(xù)創(chuàng)建同樣Label的Pod,是創(chuàng)建不出來的.因為RC認為副本數已經正常了,再多起的話會被RC刪掉

彈性伸縮

  • 彈性伸縮是指適應負載變化,以彈性可伸縮的方式提供資源.反映到Kubernetes中,指的是可根據負載的高低動態(tài)調整Pod的副本數量.調整Pod的副本數是通過修改RC中Pod的副本來實現的
# 擴容Pod的副本數目到10
kubectl scale relicationcontroller youRcName --replicas=10
# 縮容Pod的副本數目到1
kubectl scale relicationcontroller youRcName --replicas=1

滾動升級

  • 滾動升級是一種平滑過渡的升級方式,通過逐步替換的策略,保證整體系統的穩(wěn)定,在初始升級的時候就可以及時發(fā)現、調整問題,以保證問題影響度不會擴大.Kubernetes中滾動升級的命令為:
    • kubectl rolling-update my-rcName-v1 -f my-rcName-v2-rc.yaml --update-period=10s
  • 升級開始后,首先依據提供的定義文件創(chuàng)建v2版本的RC,然后每隔10s(--update-period=10s)逐步增加v2版本的Pod副本數,逐步減少v1版本Pod的副本數.升級完成之后,刪除v1版本的RC,保留v2版本的RC,實現滾動升級
  • 升級過程中,發(fā)生了錯誤中途退出時,可以選擇繼續(xù)升級.Kubernetes能夠智能的判斷升級中斷之前的狀態(tài),然后緊接著繼續(xù)執(zhí)行升級,也可以進行回退
    • kubectl rolling-update my-rcName-v1 -f my-rcName-v2-rc.yaml --update-period=10s --rollback
  • 回退的方式實際就是升級的逆操作,逐步增加v1版本的Pod副本數,逐步減少v2版本Pod的副本數

新一代副本控制器replica set

  • replica set可以被認為是升級版的Replication Controller.replica set是用于保證與label selector匹配的pod數量維持在期望狀態(tài).區(qū)別在于,replica set引入了對基于自己的selector查詢條件,而Replication Controller僅支持基于值相等的selector條件查詢

Service

  • Kubernetes中的核心要素Service提供了一套簡化的服務代理和發(fā)現機制,天然適應微服務架構
原理

  • 在Kubernetes中,在受到RC調控的時候,Pod副本是變化的,對于虛擬IP也是變化的,比如發(fā)生遷移或者伸縮的時候.這對于Pod的訪問者來說是不可接受的.Kubernetes中的Service是一種抽象概念,它定義了一個Pod邏輯集合以及訪問它們的策略,Service同Pod的關聯同樣是基于Label來完成的.Service的目標是提供一種橋梁,它會為訪問者提供一個固定訪問地址,用于在訪問時重定向到相應的后端,這使得非Kubernetes原生應用程序,在無須為Kubernetes編寫特定代碼的前提下,輕松訪問后端

  • Service同RC一樣,都是通過Label來關聯Pod.當在Service的yaml文件中定義該Service的selector中的lable為app:myweb,那么這個Service會將Pod-->metadata-->labeks中的label為app:myweb的Pod作為分發(fā)請求的后端.當Pod發(fā)生變化時(增加、減少、重建等),Service會及時更新.這樣,Service就可以作為Pod的訪問入口,起到代理服務器的作用,而對于訪問者來說,通過Service進行訪問,無需直接感知Pod

  • 注意的是,Kubernetes分配給Service的固定IP是一個虛擬IP,并不是一個真實的IP,在外部是無法尋址的.真實的系統實現上,kubernetes是通過kube-proxy組件來實現的虛擬IP路由及轉發(fā).實現了kubernetes層級的虛擬轉發(fā)網絡

Service內部負載均衡
  • 當Service的Endpoints包含多個IP的時候,及服務器代理存在多個后端,將進行請求的負載均衡.默認的負載均衡策略是輪詢或者隨機(由kube-proxy的模式決定).同時,Service上通過設置Service-->spec-->sessionAffinity=ClientIP,來實現基于源IP地址的會話保持
發(fā)布Service
  • Service的虛擬IP是由Kubernetes虛擬出來的內部網絡,外部是無法尋址到的.有些服務需要被外部訪問到,例如Web前端.這時候需要加一層網絡轉發(fā),即外網到內網的轉發(fā),即外網到內網的轉發(fā).Kubernetes提供了NodePort、LoabBalancer、Ingress三種方式
    • NodePort:Kubernetes會在每一個Node上暴露一個端口:nodeport,外部網絡可以通過(任一node)[NodeIP]:[NodePort]訪問到后端的Service
    • LoadBalance:在NodePort基礎上,Kubernetes可以請求底層云平臺創(chuàng)建一個負載均衡器,將每個Node作為后端,進行服務分發(fā).該模式需要底層云平臺(例如GCE)支持
    • Ingress:是一種HTTP方式的路由轉發(fā)機制,由Ingress Controller和HTTP代理服務器組合而成.Ingress Controller實時監(jiān)控Kubernetes API,實時更新HTTP代理服務器的轉發(fā)規(guī)則.HTTP代理服務器有GCE Load-Balancer、Nginx、HaProxy等
Servicede自發(fā)性機制
  • Kubernetes中有一個重要的服務自發(fā)現特性.一旦一個Service被創(chuàng)建,該Service的Service IP和Service port等信息都可以被注入到Pod中供它們使用.Kubernetes主要支持兩種Service發(fā)現機制:環(huán)境變量和DNS
  • 環(huán)境變量方式:
    • Kubernetes創(chuàng)建Pod時會自動添加所有可用的Service環(huán)境變量到該Pod中,如有需要,這些環(huán)境變量就被注入Pod內的容器里,需要注意的是,環(huán)境變量的注入只發(fā)生在Pod創(chuàng)建時,且不會被自動更新.這個特點暗含了Service和訪問該Service的Pod的創(chuàng)建時間的先后順序,即任何想要訪問Service的Pod都需要在Service已經存在后創(chuàng)建,否則與Service相關的環(huán)境變量就無法注入該Pod的容器中,這樣先創(chuàng)建的容器就無法發(fā)現后創(chuàng)建的Service
  • DNS方式:
    • DNS服務器使用Kubernetes的watchAPI,不間斷的監(jiān)測新的Service的創(chuàng)建并為每個Service新建一個DNS記錄.如果DNS在整個集群范圍內都可用,那么所有的Pod都能夠自動解析Service的域名
多個Service避免地址和端口沖突
  • Kubernetes為每個Service分配一個唯一的ClusterIP,當時用ClusterIP:port的組合訪問一個Service的時候,不管port是什么,這個組合一定不會發(fā)生重復.另一方面,kube-proxy為每個Service真正打開的是一個不會重復的隨機端口,用戶在Service描述文件中指定的訪問端口會被映射到這個隨機端口上

Deployment

  • Kubernetes提供了一種更加簡單的更新RC和Pod的機制,Deployment.通過在Deployment中描述期望的集群狀態(tài),Deployment Controller會將現在的集群狀態(tài)在一個可控的速度下逐步更新成所期望的集群狀態(tài),Deployment主要功能是保證Pod的數量和健康,90%的功能與Replication Controller一致,具備了Replication Controller之外的新特性
  • 事件和狀態(tài)查看:可以查看Deployment的升級詳細進度和狀態(tài)
  • 回滾:當升級Pod鏡像或者相關參數的時候發(fā)現問題,可以使用回滾操作回滾到上一個穩(wěn)定的版本或者指定的版本
  • 版本記錄:每一次對Deployment的操作,都能保存下來,給予后續(xù)可能的回滾使用
  • 暫停和啟動:對于每一次升級,都能夠隨時暫停和啟動
  • 多種升級方案:Recreate--刪除所有已存在的Pod,重新創(chuàng)建新的;RollingUpdate--滾動升級,逐步替換的策略,同時滾動升級時,支持更多的附加參數,例如設置最大不可用Pod數量,最小升級間隔時間等
滾動升級
  • 相比于RC,Deployment直接使用kubectl edit Deployment/DeploymentName或者kubectl set方法就可以直接升級(原理是Pod的template發(fā)生變化,例如更新label、更新鏡像版本等操作會觸發(fā)Deployment的滾動升級)
Deployment命令
kubectl describe deployments # 查詢詳細信息,獲取進度升級
kubectl rollout pause deployment/nginx-deployment2 # 暫停升級
kubectl rollout resume deployment/nginx-deployment2 # 繼續(xù)升級
kubectl rollout undo deployment/nginx-deployment2 # 升級回滾
kubectl scale deployment nginx-deployment --replicas # 彈性伸縮Pod數量
多重升級
  • 關于多重升級,舉例,當創(chuàng)建了一個nginx1.7的Deployment,要求副本數量為5之后,Deployment Controller會逐步的將5個1.7的Pod啟動起來,當啟動到3個的時候,又發(fā)出更新Deployment中Nginx到1.9的命令;這時Deployment Controller會立即將已啟動的3個1.7Pod殺掉,然后逐步啟動1.9的Pod.Deployment Controller不會等到1.7的Pod都啟動完成之后,再次殺掉1.9,啟動1.9

Volume

  • 在Docker的設計實現中,容器中的數據是臨時的,即當容器被銷毀時,其中的數據會丟失.如果需要持久化數據,需要使用Docker數據卷掛載宿主機上的文件或者目錄到容器中.在Kubernetes中,當Pod重建的時候,數據是會丟失的,Kubernetes也是通過數據卷掛載來提供Pod數據的持久化.Kubernetes數據卷是對Docker數據卷的擴展,Kubernetes數據卷是Pod級別的,可以用來實現Pod中容器的文件共享.
  • Kubernetes支持的數據卷類型
    1. EmptyDir
    2. HostPath
    3. GCE Persistent Disk
    4. AWS Elastic Block Store
    5. NFS
    6. iSCSI
    7. Flocker
    8. GlusterFS
    9. RBD
    10. Git repo
    11. Secret
    12. Persistent Volume Claim
Persistent Volume和Persistent Volume Claim
  • Kubernetes提供了Persistent Volume和Persistent Volume Claim機制,這是存儲消費模式.Persistent Volume是由系統管理員配置創(chuàng)建的一個數據卷(HostPath、GCE Persistent Disk、AWS Elastic Block Store、NFS、iSCSI、GlusterFS、RBD),它代表了一類存儲插件實現,對于普通用戶來說,通過Persistent Volume Claim可請求并獲得合適的Persistent Volume,而無須感知后端的存儲實現.Persistent Volume和Persistent Volume Claim的關系類似于Pod和Node,Pod消費Node資源,Persistent Volume Claim則消費Persistent Volume資源.Persistent Volume和Persistent Volume Claim相互關聯,有著完整的生命周期管理
    1. 準備:系統管理員創(chuàng)建或規(guī)劃一批Persistent Volume
    2. 綁定:用戶通過創(chuàng)建Persistent Volume Claim來聲明存儲請求,Kubernetes發(fā)現有存儲請求的時候,就去查找符合條件的Persistent Volume(最小滿足策略).找到合適的就綁定上,找不到就一直處于等待狀態(tài)
    3. 使用:創(chuàng)建Pod的時候使用Persistent Volume Claim
    4. 釋放:當用戶刪除綁定在Persistent Volume上的Persistent Volume Claim時,Persistent Volume進入釋放狀態(tài),此時Persistent Volume中還殘留著上一個Persistent Volume Claim的數據,狀態(tài)還不可用
    5. 回收:Persistent Volume需要回收才能再次使用.回收策略可以是人工的也可以是Kubernetes自動進行清理(僅支持NFS和HostPath)
?著作權歸作者所有,轉載或內容合作請聯系作者
【社區(qū)內容提示】社區(qū)部分內容疑似由AI輔助生成，瀏覽時請結合常識與多方信息審慎甄別。
平臺聲明：文章內容（如有圖片或視頻亦包括在內）由作者上傳并發(fā)布，文章內容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務。

友情鏈接更多精彩內容