下內(nèi)容整理自這本書(shū)的讀書(shū)筆記：《Kubernetes權(quán)威指南：從Docker到Kubernetes實(shí)踐全接觸(第4版)刑然，各大書(shū)店有售
一懦窘、無(wú)狀態(tài)的服務(wù)
1.pod
1）基本概念
2）配置文件樣例
apiVersion: v1
kind: Pod
metadata:
? name: myweb
? labels:
? ? app: myweb
spec:
? containers:
? - name: myweb
? ? image: kubeguide/tomcat-app:v1
? ? ports:
? ? - containerPort: 8080
? ? env:
? ? - name: MYSQL_SERVICE_HOST
? ? ? value: 'mysql'
? ? - name: MYSQL_SERVICE_PORT
? ? ? value: '3306'
3）命令行例子
kubectl get pod -o wide
kubectl describe pod?
里面的IP是POD的IP
kubectl describe pod frontend-5cb785b459-6cn6w
里面有個(gè)container可以查看pod里各個(gè)容器的情況：包括容器name千贯、image髓堪，服務(wù)端口等送朱，加上ip就可以獲取EndPoint
kubectl get endpoints
kubectl edit pod frontend-5cb785b459-6cn6w?
執(zhí)行pod內(nèi)容器的命令
kubectl exec -it frontend-5cb785b459-6cn6w -c tomcat-demo -- mkdir /tmp/abc
kubectl exec -it frontend-5cb785b459-6cn6w -c tomcat-demo -- bash
會(huì)出現(xiàn)shell提示符，可以使用env干旁，ls等命令
也可以在相應(yīng)的node節(jié)點(diǎn)執(zhí)行以下命令驶沼，進(jìn)入到docker中的容器
sudo docker exec -it 5e45393d667c bash
2.label
1）基本概念
一個(gè)Label是一個(gè)key=value的鍵值對(duì)，其中key與value由用戶(hù)自己指定争群。Label可以被附加到各種資源對(duì)象上回怜，例如Node、Pod、Service玉雾、RC等
YAML中的標(biāo)簽定義格式：
? labels:
? ? key: value
如
labels:
? ? app: myweb
給某個(gè)資源對(duì)象定義一個(gè)Label翔试，隨后可以通過(guò)Label Selector（標(biāo)簽選擇器）查詢(xún)和篩選擁有某些Label的資源對(duì)象，當(dāng)前有兩種Label Selector表達(dá)式：基于等式的（Equality-based）和基于集合的（Set-based）
基于等式的操作符：=复旬，!=
基于集合的操作符：in,notin,exists,doesnotexist
matchLabels用于定義一組Label垦缅，與直接寫(xiě)在Selector中的作用相同
selector:
? ? app: mysql
與下面的表達(dá)式等價(jià)
selector:
? ??matchLabels
? ? ? ? app: mysql
matchExpressions用于定義一組基于集合的篩選條件，可用的條件運(yùn)算符包括in,notin,exists,doesnotexist驹碍。
selector:?
? ? matchExpressions:?
? ? ? ? - {key: name1,? operator: In , values:[v1,v2]}
? ??????- {key: name2,? operator: In , values:[v3,v4]}
可以通過(guò)多個(gè)Label Selector表達(dá)式的組合實(shí)現(xiàn)復(fù)雜的條件選擇壁涎，多個(gè)表達(dá)式之間用“，”進(jìn)行分隔即可志秃，幾個(gè)條件之間是“AND”的關(guān)系怔球，即同時(shí)滿(mǎn)足多個(gè)條件
如果同時(shí)設(shè)置了matchLabels和matchExpressions，則兩組條件為AND關(guān)系
Label Selector在Kubernetes中的重要使用場(chǎng)景如下浮还。
◎ kube-controller進(jìn)程通過(guò)在資源對(duì)象RC上定義的Label Selector來(lái)篩選要監(jiān)控的Pod副本數(shù)量竟坛，使Pod副本數(shù)量始終符合預(yù)期設(shè)定的全自動(dòng)控制流程。
◎ kube-proxy進(jìn)程通過(guò)Service的Label Selector來(lái)選擇對(duì)應(yīng)的Pod钧舌，自動(dòng)建立每個(gè)Service到對(duì)應(yīng)Pod的請(qǐng)求轉(zhuǎn)發(fā)路由表担汤，從而實(shí)現(xiàn)Service的智能負(fù)載均衡機(jī)制。
◎ 通過(guò)對(duì)某些Node定義特定的Label延刘，并且在Pod定義文件中使用NodeSelector這種標(biāo)簽調(diào)度策略漫试，kube-scheduler進(jìn)程可以實(shí)現(xiàn)Pod定向調(diào)度的特性。
3.Replication Controller/Replica Set
注：Replica Set與Deployment這資源對(duì)象逐步替代了之前RC的作用
1）基本概念
定義了一個(gè)期望的場(chǎng)景碘赖，即聲明某種Pod的副本數(shù)量在任意時(shí)刻都符合某個(gè)預(yù)期值驾荣，所以RC的定義包括如下幾個(gè)部分。
◎ Pod期待的副本數(shù)量普泡。
◎ 用于篩選目標(biāo)Pod的Label Selector播掷。
◎ 當(dāng)Pod的副本數(shù)量小于預(yù)期數(shù)量時(shí)，用于創(chuàng)建新Pod的Pod模板（template）撼班。
在定義了一個(gè)RC并將其提交到Kubernetes集群中后歧匈，Master上的Controller Manager組件就得到通知，定期巡檢系統(tǒng)中當(dāng)前存活的目標(biāo)Pod砰嘁，并確保目標(biāo)Pod實(shí)例的數(shù)量剛好等于此RC的期望值件炉，如果有過(guò)多的Pod副本在運(yùn)行，系統(tǒng)就會(huì)停掉一些Pod矮湘，否則系統(tǒng)會(huì)再自動(dòng)創(chuàng)建一些Pod斟冕。可以說(shuō)缅阳，通過(guò)RC磕蛇，Kubernetes實(shí)現(xiàn)了用戶(hù)應(yīng)用集群的高可用性
Node 2上的Pod 2意外終止，則根據(jù)RC定義的replicas數(shù)量2，Kubernetes將會(huì)自動(dòng)創(chuàng)建并啟動(dòng)一個(gè)新的Pod秀撇，以保證在整個(gè)集群中始終有兩個(gè)redis-slave Pod運(yùn)行超棺。
在運(yùn)行時(shí)，我們可以通過(guò)修改RC的副本數(shù)量呵燕，來(lái)實(shí)現(xiàn)Pod的動(dòng)態(tài)縮放（Scaling）棠绘，這可以通過(guò)執(zhí)行kubectl scale命令來(lái)一鍵完成
kubectl scale rc redis-slave --replicas=3
Replication Controller由于與Kubernetes代碼中的模塊Replication Controller同名衷戈，同時(shí)“Replication Controller”無(wú)法準(zhǔn)確表達(dá)它的本意获三，所以在Kubernetes 1.2中，升級(jí)為另外一個(gè)新概念—Replica Set险毁，官方解釋其為“下一代的RC”霍衫。Replica Set與RC當(dāng)前的唯一區(qū)別是，Replica Sets支持基于集合的Label selector（Set based selector）侯养，而RC只支持基于等式的Label Selector（equality-based selector）敦跌，這使得Replica Set的功能更強(qiáng)。
2）配置文件樣例
apiVersion: v1
kind: ReplicationController
metadata:
? name: mysql
spec:
? replicas: 1
? selector:
? ? app: mysql
? template:
? ? metadata:
? ? ? labels:
? ? ? ? app: mysql
? ? spec:
? ? ? containers:
? ? ? - name: mysql
? ? ? ? image: mysql
? ? ? ? ports:
? ? ? ? - containerPort: 3306
? ? ? ? env:
? ? ? ? - name: MYSQL_ROOT_PASSWORD
? ? ? ? ? value: "123456"
上述的ReplicationController逛揩，可以替換為ReplicaSet關(guān)鍵字
3.Deployment
1）基本概念
Deployment在內(nèi)部使用了Replica Set來(lái)實(shí)現(xiàn)目的柠傍，無(wú)論從Deployment的作用與目的、YAML定義辩稽，還是從它的具體命令行操作來(lái)看惧笛，我們都可以把它看作RC的一次升級(jí)，兩者的相似度超過(guò)90%
Deployment的典型使用場(chǎng)景有以下幾個(gè)逞泄。
◎ 創(chuàng)建一個(gè)Deployment對(duì)象來(lái)生成對(duì)應(yīng)的Replica Set并完成Pod副本的創(chuàng)建患整。
◎ 檢查Deployment的狀態(tài)來(lái)看部署動(dòng)作是否完成（Pod副本數(shù)量是否達(dá)到預(yù)期的值）。
◎ 更新Deployment以創(chuàng)建新的Pod（比如鏡像升級(jí)）喷众。
◎ 如果當(dāng)前Deployment不穩(wěn)定各谚，則回滾到一個(gè)早先的Deployment版本。
◎ 暫停Deployment以便于一次性修改多個(gè)PodTemplateSpec的配置項(xiàng)到千，之后再恢復(fù)Deployment昌渤，進(jìn)行
新的發(fā)布。
◎ 擴(kuò)展Deployment以應(yīng)對(duì)高負(fù)載憔四。
◎ 查看Deployment的狀態(tài)膀息，以此作為發(fā)布是否成功的指標(biāo)。
◎ 清理不再需要的舊版本ReplicaSets了赵。
2）配置文件樣例
apiVersion: apps/v1
kind: Deployment
metadata:
? name: frontend
spec:
? replicas: 1
? selector:
? ? matchLabels:
? ? ? tier: frontend
? ? matchExpressions:
? ? ? - {key: tier, operator: In, values: [frontend]}
? template:
? ? metadata:
? ? ? labels:
? ? ? ? app: app-demo
? ? ? ? tier: frontend
? ? spec:
? ? ? containers:
? ? ? - name: tomcat-demo
? ? ? ? image: tomcat
? ? ? ? imagePullPolicy: IfNotPresent
? ? ? ? ports:
? ? ? ? - containerPort: 8080
3）命令行例子
創(chuàng)建deployment
kubectl create -f frontend-deployment.yaml
查看Deployment的信息
kubectl get deploy -o wide
查看相應(yīng)的Replica Set
kubectl get rs -o wide
kubectl describe rs?frontend-5cb785b459
查看相應(yīng)的Pod
kubectl get pod -o wide
kubectl describe pod frontend-5cb785b459-7trhb
注意這個(gè)pod的名稱(chēng)前綴潜支，與相應(yīng)的deploy和rs的名稱(chēng)是相同的
要是pod還處在Pulling image ...，還可以到相應(yīng)的node上查看images的pull狀態(tài)
sudo docker images
sudo docker pull tomcat
直到出現(xiàn)Running
基于deploy的伸縮
kubectl scale deploy frontend --replicas=2
5.Horizontal Pod Autoscaler
1）基本概念
通過(guò)手工執(zhí)行kubectl scale命令斟览，我們可以實(shí)現(xiàn)Pod擴(kuò)容或縮容毁腿。如果僅僅到此為止，顯然不符合谷歌對(duì)Kubernetes的定位目標(biāo)—自動(dòng)化、智能化已烤。在谷歌看來(lái)鸠窗，分布式系統(tǒng)要能夠根據(jù)當(dāng)前負(fù)載的變化自動(dòng)觸發(fā)水平擴(kuò)容或縮容，因?yàn)檫@一過(guò)程可能是頻繁發(fā)生的胯究、不可預(yù)料的稍计，所以手動(dòng)控制的方式是不現(xiàn)實(shí)的。
HPA有以下兩種方式作為Pod負(fù)載的度量指標(biāo)裕循。
◎ CPUUtilizationPercentage臣嚣。
◎ 應(yīng)用程序自定義的度量指標(biāo)，比如服務(wù)在每秒內(nèi)的相應(yīng)請(qǐng)求數(shù)（TPS或QPS）剥哑。
2）配置文件樣例
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
? name: frontend
? namespace: default
spec:
? maxReplicas: 10
? minReplicas: 1
? scaleTargetRef:
? ? kind: Deployment
? ? name: frontend
? targetCPUUtilizationPercentage: 90
3）命令行例子
命令行格式：kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [options]
kubectl autoscale deploy frontend --min=1?--max=10?--cpu-percent=90
二硅则、有狀態(tài)的服務(wù)
6.StatefulSet
1）基本概念
在Kubernetes系統(tǒng)中，Pod的管理對(duì)象RC株婴、Deployment怎虫、DaemonSet和Job都面向無(wú)狀態(tài)的服務(wù)。但現(xiàn)實(shí)中有很多服務(wù)是有狀態(tài)的困介，特別是一些復(fù)雜的中間件集群大审，例如MySQL集群、MongoDB集群座哩、Akka集群徒扶、ZooKeeper集群等，這些應(yīng)用集群有4個(gè)共同點(diǎn)根穷。
（1）每個(gè)節(jié)點(diǎn)都有固定的身份ID姜骡，通過(guò)這個(gè)ID，集群中的成員可以相互發(fā)現(xiàn)并通信缠诅。
（2）集群的規(guī)模是比較固定的溶浴，集群規(guī)模不能隨意變動(dòng)。
（3）集群中的每個(gè)節(jié)點(diǎn)都是有狀態(tài)的管引，通常會(huì)持久化數(shù)據(jù)到永久存儲(chǔ)中士败。
（4）如果磁盤(pán)損壞，則集群里的某個(gè)節(jié)點(diǎn)無(wú)法正常運(yùn)行褥伴，集群功能受損谅将。
StatefulSet，StatefulSet從本質(zhì)上來(lái)說(shuō)重慢，可以看作Deployment/RC的一個(gè)特殊變種饥臂，它有如下特性。
◎ StatefulSet里的每個(gè)Pod都有穩(wěn)定似踱、唯一的網(wǎng)絡(luò)標(biāo)識(shí)隅熙，可以用來(lái)發(fā)現(xiàn)集群內(nèi)的其他成員稽煤。假設(shè)StatefulSet的名稱(chēng)為kafka，那么第1個(gè)Pod叫kafka-0囚戚，第2個(gè)叫kafka-1酵熙，以此類(lèi)推。
◎ StatefulSet控制的Pod副本的啟停順序是受控的驰坊，操作第n個(gè)Pod時(shí)匾二，前n-1個(gè)Pod已經(jīng)是運(yùn)行且準(zhǔn)備好的狀態(tài)。
◎ StatefulSet里的Pod采用穩(wěn)定的持久化存儲(chǔ)卷拳芙，通過(guò)PV或PVC來(lái)實(shí)現(xiàn)察藐，刪除Pod時(shí)默認(rèn)不會(huì)刪除與StatefulSet相關(guān)的存儲(chǔ)卷（為了保證數(shù)據(jù)的安全）。
StatefulSet除了要與PV卷捆綁使用以存儲(chǔ)Pod的狀態(tài)數(shù)據(jù)舟扎，還要與Headless Service配合使用分飞，即在每個(gè)StatefulSet定義中都要聲明它屬于哪個(gè)Headless Service。Headless Service與普通Service的關(guān)鍵區(qū)別在于睹限，它沒(méi)有Cluster IP浸须，如果解析Headless Service的DNS域名，則返回的是該Service對(duì)應(yīng)的全部Pod的Endpoint列表邦泄。StatefulSet在Headless Service的基礎(chǔ)上又為StatefulSet控制的每個(gè)Pod實(shí)例都創(chuàng)建了一個(gè)DNS域名，這個(gè)域名的格式為：
$(podname).$(HeadlessServicename)
比如一個(gè)3節(jié)點(diǎn)的Kafka的StatefulSet集群對(duì)應(yīng)的Headless Service的名稱(chēng)為kafka裂垦，StatefulSet的名稱(chēng)為kafka顺囊，則StatefulSet里的3個(gè)Pod的DNS名稱(chēng)分別為kafka-0.kafka、kafka-1.kafka蕉拢、kafka-3.kafka特碳，這些DNS名稱(chēng)可以直接在集群的配置文件中固定下來(lái)。
7.Service
1）基本概念
Kubernetes里的每個(gè)Service其實(shí)就是我們經(jīng)常提起的微服務(wù)架構(gòu)中的一個(gè)微服務(wù)晕换，下圖顯示了Pod午乓、RC與Service的邏輯關(guān)系：Kubernetes的Service定義了一個(gè)服務(wù)的訪問(wèn)入口地址，前端的應(yīng)用（Pod）通過(guò)這個(gè)入口地址訪問(wèn)其背后的一組由Pod副本組成的集群實(shí)例闸准，Service與其后端Pod副本集群之間則是通過(guò)Label Selector來(lái)實(shí)現(xiàn)無(wú)縫對(duì)接的益愈。RC的作用實(shí)際上是保證Service的服務(wù)能力和服務(wù)質(zhì)量始終符合預(yù)期標(biāo)準(zhǔn)。
2）配置文件樣例
deploymentYAML文件
#nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
? name: nginx-web1
spec:
? replicas: 1
? selector:
? ? matchLabels:
? ? ? app: nginx-web1
? ? matchExpressions:
? ? ? - {key: tier, operator: In, values: [frontend]}
? template:
? ? metadata:
? ? ? labels:
? ? ? ? app: nginx-web1
? ? ? ? tier: frontend
? ? spec:
? ? ? containers:
? ? ? - name: nginx-web1
? ? ? ? image: nginx
? ? ? ? imagePullPolicy: IfNotPresent
? ? ? ? ports:
? ? ? ? - containerPort: 80
單端口svc版本
#nginx-service.yaml
apiVersion: v1
kind: Service
metadata:
? name: nginx-web1-svc-s
spec:
? ports:
? - port: 80
? selector:
? ? app: nginx-web1
? ? tier: frontend
在spec.ports的定義中夷家，targetPort屬性用來(lái)確定提供該服務(wù)的容器所暴露（EXPOSE）的端口號(hào)蒸其，即具體業(yè)務(wù)進(jìn)程在容器內(nèi)的targetPort上提供TCP/IP接入；port屬性則定義了Service的虛端口库快。前面定義Tomcat服務(wù)時(shí)沒(méi)有指定targetPort摸袁，則默認(rèn)targetPort與port相同，如下面的作用與上述是等價(jià)的
? ports:
? - port: 80
? ? targetPort: 80
（targetPort與port的縮進(jìn)要相同）
多端口版本
#nginx-service-multiple-ports.yaml
apiVersion: v1
kind: Service
metadata:
? name: nginx-web1-svc-m
spec:
? ports:
? - port: 81
? ? name: service-port
? ? targetPort: 80
? - port: 82? ?
? ? name: shutdown-port
? ? targetPort: 80
? selector:
? ? app: nginx-web1
? ? tier: frontend
nodePort svc版本
#nginx-service-nodeport.yaml
apiVersion: v1
kind: Service
metadata:
? name: nginx-web1-svc-n
spec:
type: NodePort
ports:
? - port: 83
? ? targetPort: 80
? ? nodePort: 31002
selector:
? ? app: nginx-web1
? ? tier: frontend
3）命令行例子
kubectl create -f nginx-deployment.yaml
kubectl create -f?nginx-service.yaml
kubectl create -f nginx-service-multiple-ports.yaml
kubectl create -f?nginx-service-nodeport.yaml
kubectl get svc -o wide
kubectl get pod -o wide
以下命令在master或者node上都可以執(zhí)行
#Pod IP:port
curl 10.244.36.73:80????
#單端口版本ClusterIP類(lèi)型Svc义屏，用 ClusterIP:port
curl 10.105.151.82:80????
#多端口版本ClusterIP類(lèi)型Svc靠汁，用 ClusterIP:port
curl 10.106.206.123:81
curl 10.106.206.123:82?
#NodePort類(lèi)型Svc蜂大，用 ClusterIP:port或者NodeIP:EXPOSE_PORT
curl 10.100.25.130:83? ??
curl 10.1.13.26:31002? ??
或者在瀏覽器里瀏覽：http://10.1.13.26:31002? ??
可以查看監(jiān)聽(tīng)端口
sudo netstat -tlp|grep 31002
查看svc詳情
kubectl describe svc nginx-web1-svc-m
可以看出svc的ip:port與pod的endpoints之間的對(duì)應(yīng)關(guān)系
8.Job（批處理任務(wù)）
1）基本概念
批處理任務(wù)通常并行（或者串行）啟動(dòng)多個(gè)計(jì)算進(jìn)程去處理一批工作項(xiàng)（work item），在處理完成后蝶怔，整個(gè)批處理任務(wù)結(jié)束奶浦。
Job是一種特殊的Pod副本自動(dòng)控制器，同時(shí)Job控制Pod副本與RC等控制器的工作機(jī)制有以下重要差別添谊。
（1）Job所控制的Pod副本是短暫運(yùn)行的财喳，可以將其視為一組Docker容器，其中的每個(gè)Docker容器都僅僅運(yùn)行一次斩狱。當(dāng)Job控制的所有Pod副本都運(yùn)行結(jié)束時(shí)耳高，對(duì)應(yīng)的Job也就結(jié)束了。Kubernetes在1.5版本之后又提供了類(lèi)似crontab的定時(shí)任務(wù)——CronJob所踊，解決了某些批處理任務(wù)需要定時(shí)反復(fù)執(zhí)行的問(wèn)題泌枪。
（2）Job所控制的Pod副本的工作模式能夠多實(shí)例并行計(jì)算，以TensorFlow框架為例秕岛，可以將一個(gè)機(jī)器學(xué)習(xí)的計(jì)算任務(wù)分布到10臺(tái)機(jī)器上碌燕，在每臺(tái)機(jī)器上都運(yùn)行一個(gè)worker執(zhí)行計(jì)算任務(wù)，這很適合通過(guò)Job生成10個(gè)Pod副本同時(shí)啟動(dòng)運(yùn)算继薛。
9.Volume（存儲(chǔ)卷）
1）基本概念
Volume（存儲(chǔ)卷）是Pod中能夠被多個(gè)容器訪問(wèn)的共享目錄修壕。
Kubernetes中的Volume被定義在Pod上，然后被一個(gè)Pod里的多個(gè)容器掛載到具體的文件目錄下
Kubernetes中的Volume與Pod的生命周期相同遏考，但與容器的生命周期不相關(guān)慈鸠，當(dāng)容器終止或者重啟時(shí)，Volume中的數(shù)據(jù)也不會(huì)丟失
Kubernetes支持多種類(lèi)型的Volume灌具，例如GlusterFS青团、Ceph等先進(jìn)的分布式文件系統(tǒng)
通過(guò)以下命令可以查看系統(tǒng)支持得存儲(chǔ)卷類(lèi)型
kubectl explain pods.spec.volumes
臨時(shí)存儲(chǔ):emptyDir
半持久化存儲(chǔ):hostPath
持久化存儲(chǔ):pvc，pv咖楣，nfs
分布式存儲(chǔ)： glusterfs督笆，rbd，cephfs诱贿，云存儲(chǔ)(EBS,等)
各種類(lèi)型的存儲(chǔ)卷配置方法參見(jiàn)下面的例子
1) emptyDir
volumes:
? ? ? - name: tmp
? ? ? ? emptyDir: {}
2) hostPath
volumes:
? ? ? - name: data
? ? ? ? hostPath:
? ? ? ? ? ? path: "/data"
2)?nfs
volumes:
- name: nfs
? ? ? ? nfs:
? ? ? ? ? ? server: 10.1.1.1?
? ? ? ? ? ? path: "/data"
2）配置文件樣例
#volume-deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
? name: web-volume
spec:
? replicas: 1
? selector:
? ? matchLabels:
? ? ? app: web-volume
? template:
? ? metadata:
? ? ? labels:
? ? ? ? app: web-volume
? ? spec:
? ? ? volumes:
? ? ? - name: data
? ? ? ? hostPath:
? ? ? ? ? ? path: "/data"
? ? ? - name: tmp
? ? ? ? emptyDir: {}
? ? ? containers:
? ? ? - name: web-volume
? ? ? ? image: nginx
? ? ? ? volumeMounts:
? ? ? ? - mountPath: /test/data
? ? ? ? ? name: data
? ? ? ? - mountPath: /test/tmp
? ? ? ? ? name: tmp
? ? ? ? imagePullPolicy: IfNotPresent
? ? ? ? ports:
? ? ? ? - containerPort: 80
3）命令行例子
kubectl explain pods.spec.volumes
kubectl create -f volume-deploy.yaml
kubectl?get pod
kubectl exec -it?web-volume-869968c6b-bqqvw -- bash
ls看看/test有沒(méi)有兩個(gè)子目錄
9.Persistent Volume（持久化?存儲(chǔ)卷）
1）基本概念
PV可以被理解成Kubernetes集群中的某個(gè)網(wǎng)絡(luò)存儲(chǔ)對(duì)應(yīng)的一塊存儲(chǔ)娃肿，它與Volume類(lèi)似，但有以下區(qū)別瘪松。
◎ PV只能是網(wǎng)絡(luò)存儲(chǔ)咸作，不屬于任何Node，但可以在每個(gè)Node上訪問(wèn)宵睦。
◎ PV并不是被定義在Pod上的记罚，而是獨(dú)立于Pod之外定義的。
◎ PV目前支持的類(lèi)型包括：gcePersistentDisk壳嚎、AWSElasticBlockStore桐智、AzureFile末早、AzureDisk、FC（Fibre Channel）说庭、Flocker然磷、NFS、iSCSI刊驴、RBD（Rados Block Device）姿搜、CephFS、Cinder捆憎、GlusterFS舅柜、VsphereVolume、Quobyte Volumes躲惰、VMware Photon致份、Portworx Volumes、ScaleIO Volumes和HostPath（僅供單機(jī)測(cè)試）础拨。
◎ 需要定義一個(gè)PersistentVolumeClaim對(duì)象,?PV 和 PVC 的 storageClassName 字段必須一樣氮块。
◎ 創(chuàng)建Pod是引用和mount
比較重要的是PV的accessModes屬性，目前有以下類(lèi)型诡宗。
◎ ReadWriteOnce：讀寫(xiě)權(quán)限滔蝉，并且只能被單個(gè)Node掛載。
◎ ReadOnlyMany：只讀權(quán)限塔沃，允許被多個(gè)Node掛載锰提。
◎ ReadWriteMany：讀寫(xiě)權(quán)限，允許被多個(gè)Node掛載芳悲。
2）配置文件樣例
#pv.yaml
kind: PersistentVolume
apiVersion: v1
metadata:
? name: pv-volume
? labels:
? ? type: local
spec:
? storageClassName: manual
? capacity:
? ? storage: 1Gi
? accessModes:
? ? - ReadWriteOnce
? hostPath:
? ? path: "/data/pv"
#pvc.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
? name: pv-claim
spec:
? storageClassName: manual
? accessModes:
? ? - ReadWriteOnce
? resources:
? ? requests:
? ? ? storage: 1Gi
#pv-pod.yaml
kind: Pod
apiVersion: v1
metadata:
? name: pv-pod
spec:
? volumes:
? ? - name: pv-storage
? ? ? persistentVolumeClaim:
? ? ? ? ? claimName: pv-claim
? containers:
? ? - name: pv-container
? ? ? image: nginx
? ? ? ports:
? ? ? ? - containerPort: 80
? ? ? ? ? name: "http-server"
? ? ? volumeMounts:
? ? ? ? - mountPath: "/usr/share/nginx/html"
? ? ? ? ? name: pv-storage
#pv-deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
? name: pv-web
spec:
? replicas: 1
? selector:
? ? matchLabels:
? ? ? app: pv-web
? template:
? ? metadata:
? ? ? labels:
? ? ? ? app: pv-web
? ? spec:
? ? ? volumes:
? ? ? - name: pv-storage
? ? ? ? persistentVolumeClaim:
? ? ? ? ? ? claimName: pv-claim
? ? ? containers:
? ? ? - name: pv-web
? ? ? ? image: nginx
? ? ? ? volumeMounts:
? ? ? ? - mountPath: /data
? ? ? ? ? name: pv-storage
? ? ? ? imagePullPolicy: IfNotPresent
? ? ? ? ports:
? ? ? ? - containerPort: 80
3）命令行例子
kubectl create -f pv.yaml
kubectl create -f pvc.yaml
kubectl create -f pv-pod.yaml
kubectl get pv
kubectl get pvc
#對(duì)應(yīng)的deploy掛載的卷
kubectl exec -it pv-pod bash
ls?/usr/share/nginx/html
#對(duì)應(yīng)的deploy掛載的卷
kubectl exec -it pv-web-66c4dc975c-q2mjp -- bash
ls /data
在node上/data/pv目錄下touch文件，回到容器中看看是否有這個(gè)文件
10.Namespace
1）基本概念
Namespace（命名空間）是Kubernetes系統(tǒng)中的另一個(gè)非常重要的概念边坤，Namespace在很多情況下用于實(shí)現(xiàn)多租戶(hù)的資源隔離名扛。Namespace通過(guò)將集群內(nèi)部的資源對(duì)象“分配”到不同的Namespace中，形成邏輯上分組的不同項(xiàng)目茧痒、小組或用戶(hù)組肮韧，便于不同的分組在共享使用整個(gè)集群的資源的同時(shí)還能被分別管理。
2）配置文件樣例
#ns.yaml
---
apiVersion: v1
kind: Namespace
metadata:
? name: dev
---
apiVersion: apps/v1
kind: Deployment
metadata:
? name: web-ns1
? namespace: dev
spec:
? replicas: 1
? selector:
? ? matchLabels:
? ? ? app: web-ns1
? template:
? ? metadata:
? ? ? labels:
? ? ? ? app: web-ns1
? ? spec:
? ? ? containers:
? ? ? - name: web-ns1
? ? ? ? image: nginx
? ? ? ? imagePullPolicy: IfNotPresent
? ? ? ? ports:
? ? ? ? - containerPort: 80
3）命令行例子
kubectl get ns
kubectl get pod -n dev
11.Annotation
Annotation（注解）與Label類(lèi)似旺订，也使用key/value鍵值對(duì)的形式進(jìn)行定義弄企。不同的是Label具有嚴(yán)格的命名規(guī)則，它定義的是Kubernetes對(duì)象的元數(shù)據(jù)（Metadata）区拳，并且用于Label Selector拘领。Annotation則是用戶(hù)任意定義的附加信息，以便于外部工具查找樱调。在很多時(shí)候约素，Kubernetes的模塊自身會(huì)通過(guò)Annotation標(biāo)記資源對(duì)象的一些特殊信息
12.ConfigMap
Docker通過(guò)將程序届良、依賴(lài)庫(kù)、數(shù)據(jù)及配置文件“打包固化”到一個(gè)不變的鏡像文件中的做法圣猎，解決了應(yīng)用的部署的難題士葫，但這同時(shí)帶來(lái)了棘手的問(wèn)題，即配置文件中的參數(shù)在運(yùn)行期如何修改的問(wèn)題送悔。我們不可能在啟動(dòng)Docker容器后再修改容器里的配置文件慢显，然后用新的配置文件重啟容器里的用戶(hù)主進(jìn)程。為了解決這個(gè)問(wèn)題欠啤，Docker提供了兩種方式：
◎ 在運(yùn)行時(shí)通過(guò)容器的環(huán)境變量來(lái)傳遞參數(shù)荚藻；
◎ 通過(guò)Docker Volume將容器外的配置文件映射到容器內(nèi)。
這兩種方式都有其優(yōu)勢(shì)和缺點(diǎn)跪妥，
◎ 在目標(biāo)主機(jī)上先創(chuàng)建好對(duì)應(yīng)的配置文件鞋喇，然后才能映射到容器里。
◎ 在分布式情況下變得更為嚴(yán)重眉撵，寫(xiě)入（修改）多臺(tái)服務(wù)器上的某個(gè)指定文件侦香，并確保這些文件保持一致
Kubernetes使用ConfigMap資源對(duì)象：把所有的配置項(xiàng)都當(dāng)作key-value字符串，比如password=123456纽疟、user=root罐韩，這些配置項(xiàng)可以作為Map表中的一個(gè)項(xiàng)，整個(gè)Map的數(shù)據(jù)可以被持久化存儲(chǔ)在Kubernetes的Etcd數(shù)據(jù)庫(kù)中污朽，然后提供API以方便Kubernetes相關(guān)組件或客戶(hù)應(yīng)用CRUD操作這些數(shù)據(jù)散吵。
2）配置文件樣例
#cm-appvars.yaml
appvars.yaml
apiVersion: v1
kind: ConfigMap
metadata:
? name: cm-appvars
data:
? apploglevel: info
? appdatadir: /var/data
#test-pod-envfrom-and-use-envvar.yaml
apiVersion: v1
kind: Pod
metadata:
? name: cm-test-pod
spec:
? containers:
? - name: cm-test
? ? image: nginx
? ? command: [ "/bin/sh", "-c", "env" ]
? ? envFrom:
? ? - configMapRef:
? ? ? name: cm-appvars
? ? env:
? ? - name: APPLOGLEVEL
? ? ? valueFrom:
? ? ? ? configMapKeyRef:
? ? ? ? ? name: cm-appvars
? ? ? ? ? key: apploglevel
? ? - name: APPDATADIR
? ? ? valueFrom:
? ? ? ? configMapKeyRef:
? ? ? ? ? name: cm-appvars
? ? ? ? ? key: appdatadir
? restartPolicy: Never
3）命令行例子
kubectl create -f?cm-appvars.yaml
kubectl create -f?test-pod-envfrom-and-use-envvar.yaml
kubectl log?cm-test-pod
就可以看到cm-appvars.yaml中定義的環(huán)境變量
