關于 Kubernetes中一些基本概念和術語筆記（二）

寫在前面

學習K8s，所以整理記憶

一個不欣賞自己的人，是難以快樂的。-------三毛

7、 Horizontal Pod Autoscaler

HPA與之前的RC、 Deployment一樣,也屬于一種Kubernetes資源對象

。通過

追蹤分析RC控制的所有目標Pod的負載變化情況,來確定是否需要針對性地調整目標Pod的副本數,這是HPA的實現原理

。當前, HPA可以有以下兩種方式作為Pod負載的度量指標。

apiversion: autoscaling/v1 kind: HorizontalPodAutoscaler metadata: name: php-apache namespace: default spec maxReplicas: 10 minReplicas: 1 scaleTargetRef: kind: Deployment name: php-apache targetcpuutilizationPercentage: 90

CPUUtilizationPercentage是一個算術平均值,即目標Pod所有副本自身的CPU利用率的平均值。一個Pod自身的CPU利用率是該Pod當前CPU的使用量除以它的Pod Request的值,比,如我們定義一個Pod的Pod Request為0.4,而當前Pod的CPU使用量為0.2,則它的CPU使用率為50%

根據上面的定義,我們可以知道這個HPA控制的目標對象為一個名叫php-apache Deployment里的Pod副本,當這些Pod副本的CPUUtilizationPercentage的值超過90%時會觸發自動動態擴容行為,擴容或縮容時必須滿足的一個約束條件是Pod的副本數要介于1與10之間。

除了可以通過直接定義yaml文件并且調用kubectrl create的命令來創建一個HPA資源對象的方式,我們還能通過下面的簡單命令行直接創建等價的HPA對象:

kubectl autoscale deployment php-apache --cpu-percent=90--min-1 --max=10

8、 StatefulSet

在Kubernetes系統中, Pod的管理對象RC， Deployment, DaemonSet和Job都是面向無狀態的服務。

但現實中有很多服務是有狀態的,特別是一些復雜的中間件集群,例如MysQL集·群、MongoDB集群、ZooKeeper集群等,這些應用集群有以下一些共同點:

如果用RC/Deployment控制Pod副本數的方式來實現上述有狀態的集群,則我們會發現第1點是無法滿足的,因為Pod的名字是隨機產生的, Pod的IP地址也是在運行期才確定且可能有變動的,我們事先無法為每個Pod確定唯一不變的ID,

為了能夠在其他節點上恢復某個失敗的節點,

這種集群中的Pod需要掛接某種共享存儲

,為了解決這個問題, Kubernetes從v1.4版本開始引入了PetSet這個新的資源對象,并且在v1.5版本時更名為StatefulSet, StatefulSet從本質上來說,可以看作DeploymentRC的一個特殊變種,它有如下一些特性。)

statefulSet除了要與PV卷捆綁使用以存儲Pod的狀態數據,還要與Headless Service配合使用,

即在每個StatefulSet的定義中要聲明它屬于哪個Headless Service

.

Headless Service與普通Service的關鍵區別在于,它沒有Cluster IP

,如果解析Headless Service的DNS域名,則返回的是該Service對應的全部Pod的Endpoint列表。StatefulSet在Headless Service的基礎上又為StatefulSet控制的每個Pod實例創建了一個DNS域名,這個域名的格式為:

$(podname).$(headless service name)

9、 Service （服務）

Service也是Kubernetes里的最核心的資源對象之一,

Kubernetes里的每個Service其實就是我們經常提起的微服務架構中的一個“微服務”,之前我們所說的Pod, RC等資源對象其實都是為這節所說的“服務”-Kubernetes Service作“嫁衣”的

。

Pod,RC與Service的邏輯關系

。

Kubernetes的Service定義了一個服務的訪問入口地址,前端的應用(Pod)通過這個入口地址訪問其背后的一組由Pod副本組成的集群實例, Service與其后端Pod副本集群之間則是通過Label Selector來實現“無縫對接”的。而RC的作用實際上是保證Service的服務能力和服務質量始終處干預期的標準。

每個Pod都會被分配一個單獨的IP地址,而且每個Pod都提供了一個獨立的Endpoint(Pod IP+ContainerPort)以被客戶端訪問,現在多個Pod副本組成了一個集群來提供服務.客戶端如何來訪問它們呢?一般的做法是部署一個負載均衡器(軟件或硬件),

Kubernetes中運行在每個Node上的kube-proxy進程其實就是一個智能的軟件負載均衡器,它負責把對Service的請求轉發到后端的某個Pod實例上,并在內部實現服務的負載均衡與會話保持機制

。

Kubernetes發明了一種很巧妙又影響深遠的設計:

Service不是共用一個負載均衡器的IP地址,而是每個Service分配了一個全局唯一的虛擬IP地址,這個虛擬IP被稱為Cluster IP,這樣一來,每個服務就變成了具備唯一IP地址的“通信節點”,服務調用就變成了最基礎的TCP網絡通信問題。

我們知道, Pod的Endpoint地址會隨著Pod的銷毀和重新創建而發生改變,因為新Pod的IP地址與之前舊Pod的不同。而

Service一旦被創建, Kubernetes就會自動為它分配一個可用的Cluster IP,而且在Service的整個生命周期內,它的Cluster IP不會發生改變

。于是,服務發現這個棘手的問題在Kubernetes的架構里也得以輕松解決:只要用Service的Name與Service的Cluster IP地址做一個DNS域名映射即可完美解決問題。

┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-pod-create] └─$kubectl get svc myweb -o yaml apiVersion: v1 kind: Service metadata: creationTimestamp: "2021-10-16T14:25:08Z" name: myweb namespace: liruilong-pod-create resourceVersion: "339816" uid: 695aa461-166c-4937-89ed-7b16ac49c96b spec: clusterIP: 10.109.233.35 clusterIPs: - 10.109.233.35 externalTrafficPolicy: Cluster ipFamilies: - IPv4 ipFamilyPolicy: SingleStack ports: - nodePort: 30001 port: 8080 protocol: TCP targetPort: 8080 selector: app: myweb sessionAffinity: None type: NodePort status: loadBalancer: {}

Kubernetes Service支持多個Endpoint（端口）,

在存在多個Endpoint的情況下,要求每個Endpoint定義一個名字來區分

。下面是Tomcat多端口的Service定義樣例:

spec: ports: - port: 8080 name: service-port - port: 8005 name: shutdown-port

多端口為什么需要給每個端口命名呢?這就涉及Kubernetes的服務發現機制了

外部系統訪問 Service,采用NodePort是解決上述問題的最直接、最有效、最常用的做法。具體做法如下,以tomcat-service為例,我們在Service的定義里做如下擴展即可:

... spec: type: NodePort posts： - port: 8080 nodePort: 31002 selector: tier: frontend ...

即這里我們可以通過nodePort:31002 來訪問Service,NodePort的實現方式是在Kubernetes集群里的每個Node上為需要外部訪問的Service開啟個對應的TCP監聽端口,外部系統只要用任意一個Node的IP地址+具體的NodePort端口即可訪問此服務,在任意Node上運行netstat命令,我們就可以看到有NodePort端口被監聽:

Service 負載均衡問題

但NodePort還沒有完全解決外部訪問Service的所有問題,比如負載均衡問題,假如我們的集群中有10個Node,則此時最好有一個負載均衡器,外部的請求只需訪問此負載均衡器的IP地址,由負載均衡器負責轉發流量到后面某個Node的NodePort上。如圖

10、 Volume (存儲卷)

Volume是Pod中能夠被多個容器訪問的共享目錄。Kuberetes的Volume概念、用途和目的與Docker的Volume比較類似,但兩者不能等價。

Volume的使用也比較簡單,在大多數情況下,我們先在Pod上聲明一個Volume,然后在容器里引用該Volume并Mount到容器里的某個目錄上。舉例來說,我們要給之前的Tomcat Pod增加一個名字為datavol的Volume,并且Mount到容器的/mydata-data目錄上,則只要對Pod的定義文件做如下修正即可(注意黑體字部分):

template: metadata: labels: app: app-demo tier: frontend spec: volumes: - name: datavol emptyDir: {} containers: - name: tomcat-demo image: tomcat volumeMounts: - mountPath: /myddata-data name: datavol imagePullPolicy: IfNotPresent

除了可以讓一個Pod里的多個容器共享文件、讓容器的數據寫到宿主機的磁盤上或者寫文件到網絡存儲中, Kubernetes的Volume還擴展出了一種非常有實用價值的功能,即

容器配置文件集中化定義與管理

,這是通過ConfigMap這個新的資源對象來實現的.

Kubernetes提供了非常豐富的Volume類型,下面逐一進行說明。

一個emptyDir Volume是在Pod分配到Node時創建的

。從它的名稱就可以看出,它的初始內容為空,并且無須指定宿主機上對應的目錄文件,因為這是

Kubernetes自動分配的一個目錄

,當Pod從Node上移除時, emptyDir中的數據也會被永久刪除。emptyDir的一些用途如下。

hostPath為在Pod上掛載宿主機上的文件或目錄,它通常可以用于以下幾方面。

|容器應用程序生成的日志文件需要永久保存時,可以使用宿主機的高速文件系統進行存儲。|

需要訪問宿主機上Docker引擎內部數據結構的容器應用時,可以通過定義hostPath為宿主機/var/lib/docker目錄,使容器內部應用可以直接訪問Docker的文件系統。

在使用這種類型的Volume時,需要注意以下幾點。

在不同的Node上具有相同配置的Pod可能會因為宿主機上的目錄和文件不同而導致對Volume上目錄和文件的訪問結果不一致。)

如果使用了資源配額管理,則Kubernetes無法將hostPath在宿主機上使用的資源納入管理。在下面的例子中使用宿主機的/data目錄定義了一個hostPath類型的Volume:

volumes: - name: "persistent-storage" hostPath: path: "/data"

使用這種類型的Volume表示使用谷歌公有云提供的永久磁盤(PersistentDisk, PD)存放Volume的數據,它與emptyDir不同, PD上的內容會被永久存,當Pod被刪除時, PD只是被卸載(Unmount),但不會被刪除。需要注意是,你需要先創建一個永久磁盤(PD),才能使用gcePersistentDisk.

與GCE類似,該類型的Volume使用亞馬遜公有云提供的EBS Volume存儲數據,需要先創建一個EBS Volume才能使用awsElasticBlockStore.

使用NFS網絡文件系統提供的共享目錄存儲數據時,我們需要在系統中部署一個NFSServer,定義NES類型的Volume的示例如下

yum -y install nfs-utils

... volumes: - name: test-volume nfs: server: nfs.server.locathost path: "/" ....

11、 Persistent Volume

Volume是定義在Pod上的,屬于“計算資源”的一部分,而實際上, “網絡存儲”是相對獨立于“計算資源”而存在的一種實體資源。比如在使用虛擬機的情況下,我們通常會先定義一個網絡存儲,然后從中劃出一個“網盤”并掛接到虛擬機上

Persistent Volume(簡稱PV)和與之相關聯的Persistent Volume Claim (簡稱PVC)也起到了類似的作用。PV可以理解成

Kubernetes集群中的某個網絡存儲中對應的一塊存儲

,它與Volume很類似,但有以下區別。

apiversion: v1 kind: PersistentVolume metadata: name: pv0003 spec: capacity: storage: 5Gi accessModes: - ReadWriteOnce nfs: path: /somepath server: 172.17.0.2

PV的accessModes屬性

, 目前有以下類型:

ReadWriteOnce:讀寫權限、并且只能被單個Node掛載。

ReadOnlyMany:只讀權限、允許被多個Node掛載。

ReadWriteMany:讀寫權限、允許被多個Node掛載。

如果某個Pod想申請某種類型的PV,則首先需要定義一個PersistentVolumeClaim (PVC)對象:

kind: Persistentvolumeclaim apiversion: v1 metadata: name: myclaim spec: accessModes: - Readwriteonce resources: requests: storage: BGi

引用PVC

volumes: - name: mypd persistentvolumeclaim: claimName: myclaim

12、 Namespace (命名空間)

Namespace (命名空間)是Kubernetes系統中非常重要的概念

, Namespace在很多情況下用于實現

多租戶的資源隔離

。Namespace通過將集群內部的資源對象“分配”到不同的Namespace 中,形成邏輯上分組的不同項目、小組或用戶組,便于不同的分組在共享使用整個集群的資源的同時還能被分別管理。Kubernetes集群在啟動后,會創建一個名為"default"的Namespace,通過kubectl可以查看到:

kub-system 本身的各種 pod，是kubamd默認的空間。pod使用命名空間相互隔離

┌──[root@vms81.liruilongs.github.io]-[~/ansible] └─$kubectl get namespaces NAME STATUS AGE default Active 13h kube-node-lease Active 13h kube-public Active 13h kube-system Active 13h ┌──[root@vms81.liruilongs.github.io]-[~/ansible] └─$kubectl get ns NAME STATUS AGE default Active 13h kube-node-lease Active 13h kube-public Active 13h kube-system Active 13h ┌──[root@vms81.liruilongs.github.io]-[~/ansible] └─$

命名空間基本命令

┌──[root@vms81.liruilongs.github.io]-[~/ansible] └─$kubectl create ns liruilong namespace/liruilong created ┌──[root@vms81.liruilongs.github.io]-[~/ansible] └─$kubectl get ns NAME STATUS AGE default Active 13h kube-node-lease Active 13h kube-public Active 13h kube-system Active 13h liruilong Active 4s ┌──[root@vms81.liruilongs.github.io]-[~/ansible] └─$kubectl create ns k8s-demo namespace/k8s-demo created ┌──[root@vms81.liruilongs.github.io]-[~/ansible] └─$kubectl get ns NAME STATUS AGE default Active 13h k8s-demo Active 3s kube-node-lease Active 13h kube-public Active 13h kube-system Active 13h liruilong Active 20s ┌──[root@vms81.liruilongs.github.io]-[~/ansible] └─$kubectl delete ns k8s-demo namespace "k8s-demo" deleted ┌──[root@vms81.liruilongs.github.io]-[~/ansible] └─$kubectl get ns NAME STATUS AGE default Active 13h kube-node-lease Active 13h kube-public Active 13h kube-system Active 13h liruilong Active 54s ┌──[root@vms81.liruilongs.github.io]-[~/ansible] └─$

命名空間切換

┌──[root@vms81.liruilongs.github.io]-[~/.kube] └─$vim config ┌──[root@vms81.liruilongs.github.io]-[~/.kube] └─$kubectl config get-contexts CURRENT NAME CLUSTER AUTHINFO NAMESPACE * context1 cluster1 kubernetes-admin1 context2 cluster2 kubernetes-admin2 ┌──[root@vms81.liruilongs.github.io]-[~/.kube] └─$kubectl config set-context context2 --namespace=kube-system Context "context2" modified. ┌──[root@vms81.liruilongs.github.io]-[~/.kube] └─$kubectl config get-contexts CURRENT NAME CLUSTER AUTHINFO NAMESPACE * context1 cluster1 kubernetes-admin1 context2 cluster2 kubernetes-admin2 kube-system ┌──[root@vms81.liruilongs.github.io]-[~/.kube] └─$kubectl config set-context context1 --namespace=kube-public Context "context1" modified.

或者可以這樣切換名稱空間

kubectl config set-context $(kubectl config current-context) --namespace= kubectl config view | grep namespace kubectl get pods

創建pod時指定命名空間

apiVersion: v1 kind: Pod metadata: creationTimestamp: null labels: run: pod-static name: pod-static namespeace: default spec: containers: - image: nginx imagePullPolicy: IfNotPresent name: pod-demo resources: {} dnsPolicy: ClusterFirst restartPolicy: Always status: {}

當我們給每個租戶創建一個Namespace來實現多租戶的資源隔離時,還能結合Kubernetes"的資源配額管理,限定不同租戶能占用的資源,例如CPU使用量、內存使用量等。

13、 Annotation (注解)

Annotation與Label類似,也使用key/value鍵值對的形式進行定義。

不同的是Label具有嚴格的命名規則,它定義的是Kubernetes對象的元數據(Metadata),并且用于Label Selector.

Annotation則是用戶任意定義的“附加”信息,以便于外部工具進行查找, Kubernetes的模塊自身會通過Annotation的方式標記資源對象的一些特殊信息。

┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-pod-create] └─$kubectl annotate nodes vms82.liruilongs.github.io "dest=這是一個工作節點" node/vms82.liruilongs.github.io annotated ┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-pod-create] └─$kubectl describe nodes vms82.liruilongs.github.io Name: vms82.liruilongs.github.io Roles: worker1 Labels: beta.kubernetes.io/arch=amd64 beta.kubernetes.io/os=linux disktype=node1 kubernetes.io/arch=amd64 kubernetes.io/hostname=vms82.liruilongs.github.io kubernetes.io/os=linux node-role.kubernetes.io/worker1= Annotations: dest: 這是一個工作節點 kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock node.alpha.kubernetes.io/ttl: 0 projectcalico.org/IPv4Address: 192.168.26.82/24 projectcalico.org/IPv4IPIPTunnelAddr: 10.244.171.128 volumes.kubernetes.io/controller-managed-attach-detach: true .....................

Kubernetes

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。