16個核心概念帶你入門 Kubernetes

2024-06-09 16:59:48

字體：大中小

來源：轉載

供稿：網友

　　Kubernetes是Google開源的容器集群管理系統，是Google多年⼤規模容器管理技術Borg的開源版本，主要功能包括:

　　基于容器的應用部署、維護和滾動升級
　　負載均衡和服務發現
　　跨機器和跨地區的集群調度
　　自動伸縮
　　無狀態服務和有狀態服務
　　廣泛的Volume支持
　　插件機制保證擴展性
　　Kubernetes發展非常迅速，已經成為容器編排領域的領導者，接下來我們將講解Kubernetes中涉及到的一些主要概念。

　　1、Pod

　　Pod是一組緊密關聯的容器集合，支持多個容器在一個Pod中共享網絡和文件系統，可以通過進程間通信和文件共享這種簡單高效的方式完成服務，是Kubernetes調度的基本單位。Pod的設計理念是每個Pod都有一個唯一的IP。

　　Pod具有如下特征：

　　包含多個共享IPC、Network和UTC namespace的容器，可直接通過localhost通信
　　所有Pod內容器都可以訪問共享的Volume，可以訪問共享數據
　　優雅終止:Pod刪除的時候先給其內的進程發送SIGTERM，等待一段時間(grace period)后才強制停止依然還在運行的進程
　　特權容器(通過SecurityContext配置)具有改變系統配置的權限(在網絡插件中大量應用)
　　支持三種重啟策略（restartPolicy），分別是：Always、OnFailure、Never
　　支持三種鏡像拉取策略（imagePullPolicy），分別是：Always、Never、IfNotPresent
　　資源限制，Kubernetes通過CGroup限制容器的CPU以及內存等資源，可以設置request以及limit值
　　健康檢查，提供兩種健康檢查探針，分別是livenessProbe和redinessProbe，前者用于探測容器是否存活，如果探測失敗，則根據重啟策略進行重啟操作，后者用于檢查容器狀態是否正常，如果檢查容器狀態不正常，則請求不會到達該Pod
　　Init container在所有容器運行之前執行，常用來初始化配置
　　容器生命周期鉤子函數，用于監聽容器生命周期的特定事件，并在事件發生時執行已注冊的回調函數，支持兩種鉤子函數：postStart和preStop，前者是在容器啟動后執行，后者是在容器停止前執行
　　2、Namespace

　　Namespace（命名空間）是對一組資源和對象的抽象集合，比如可以用來將系統內部的對象劃分為不同的項目組或者用戶組。常見的pod、service、replicaSet和deployment等都是屬于某一個namespace的(默認是default)，而node, persistentVolumes等則不屬于任何namespace。

　　常用namespace操作：

　　kubectlgetnamespace, 查詢所有namespace
　　kubectl createnamespacens-name，創建namespace
　　kubectldeletenamespacens-name, 刪除namespace
　　刪除命名空間時，需注意以下幾點：

　　刪除一個namespace會自動刪除所有屬于該namespace的資源。
　　default 和 kube-system 命名空間不可刪除。
　　PersistentVolumes是不屬于任何namespace的，但PersistentVolumeClaim是屬于某個特定namespace的。
　　Events是否屬于namespace取決于產生events的對象。
　　3、Node

　　Node是Pod真正運行的主機，可以是物理機也可以是虛擬機。Node本質上不是Kubernetes來創建的， Kubernetes只是管理Node上的資源。為了管理Pod，每個Node節點上至少需要運行container runtime（Docker）、kubelet和kube-proxy服務。

　　常用node操作：

　　kubectlgetnodes，查詢所有node
　　kubectl cordon $nodename, 將node標志為不可調度
　　 kubectl uncordon $nodename, 將node標志為可調度
　　taint(污點)

　　使用kubectl taint命令可以給某個Node節點設置污點，Node被設置上污點之后就和Pod之間存在了一種相斥的關系，可以讓Node拒絕Pod的調度執行，甚至將Node已經存在的Pod驅逐出去。每個污點的組成：key=value:effect，當前taint effect支持如下三個選項：

　　NoSchedule：表示k8s將不會將Pod調度到具有該污點的Node上
　　PreferNoSchedule：表示k8s將盡量避免將Pod調度到具有該污點的Node上
　　NoExecute：表示k8s將不會將Pod調度到具有該污點的Node上，同時會將Node上已經存在的Pod驅逐出去
　　常用命令如下：

　　kubectl taint node node0 key1=value1:NoShedule，為node0設置不可調度污點
　　 kubectl taint node node0 key-，將node0上key值為key1的污點移除
　　kubectl taint node node1 node-role.kubernetes.io/master=:NoSchedule，為kube-master節點設置不可調度污點
　　kubectl taint node node1 node-role.kubernetes.io/master=PreferNoSchedule，為kube-master節點設置盡量不可調度污點
　　容忍(Tolerations)

　　設置了污點的Node將根據taint的effect：NoSchedule、PreferNoSchedule、NoExecute和Pod之間產生互斥的關系，Pod將在一定程度上不會被調度到Node上。但我們可以在Pod上設置容忍(Toleration)，意思是設置了容忍的Pod將可以容忍污點的存在，可以被調度到存在污點的Node上。

　　4、Service

　　Service是對一組提供相同功能的Pods的抽象，并為他們提供一個統一的入口，借助 Service 應用可以方便的實現服務發現與負載均衡，并實現應用的零宕機升級。Service通過標簽(label)來選取后端Pod，一般配合ReplicaSet或者Deployment來保證后端容器的正常運行。

　　service 有如下四種類型，默認是ClusterIP：

　　ClusterIP: 默認類型，自動分配一個僅集群內部可以訪問的虛擬IP
　　NodePort: 在ClusterIP基礎上為Service在每臺機器上綁定一個端口，這樣就可以通過 NodeIP:NodePort 來訪問該服務
　　LoadBalancer: 在NodePort的基礎上，借助cloud provider創建一個外部的負載均衡器，并將請求轉發到 NodeIP:NodePort
　　ExternalName: 將服務通過DNS CNAME記錄方式轉發到指定的域名
　　另外，也可以將已有的服務以Service的形式加入到Kubernetes集群中來，只需要在創建 Service 的時候不指定Label selector，而是在Service創建好后手動為其添加endpoint。

　　5、Volume 存儲卷

　　默認情況下容器的數據是非持久化的，容器消亡以后數據也會跟著丟失，所以Docker提供了Volume機制以便將數據持久化存儲。Kubernetes提供了更強大的Volume機制和插件，解決了容器數據持久化以及容器間共享數據的問題。

　　Kubernetes存儲卷的生命周期與Pod綁定

　　容器掛掉后Kubelet再次重啟容器時，Volume的數據依然還在
　　Pod刪除時，Volume才會清理。數據是否丟失取決于具體的Volume類型，比如emptyDir的數據會丟失，而PV的數據則不會丟
　　目前Kubernetes主要支持以下Volume類型：

　　emptyDir：Pod存在，emptyDir就會存在，容器掛掉不會引起emptyDir目錄下的數據丟失，但是pod被刪除或者遷移，emptyDir也會被刪除
　　hostPath：hostPath允許掛載Node上的文件系統到Pod里面去
　　NFS（Network File System）：網絡文件系統，Kubernetes中通過簡單地配置就可以掛載NFS到Pod中，而NFS中的數據是可以永久保存的，同時NFS支持同時寫操作。
　　glusterfs：同NFS一樣是一種網絡文件系統，Kubernetes可以將glusterfs掛載到Pod中，并進行永久保存
　　cephfs：一種分布式網絡文件系統，可以掛載到Pod中，并進行永久保存
　　subpath：Pod的多個容器使用同一個Volume時，會經常用到
　　secret：密鑰管理，可以將敏感信息進行加密之后保存并掛載到Pod中
　　persistentVolumeClaim：用于將持久化存儲（PersistentVolume）掛載到Pod中
　　...
　　6、PersistentVolume(PV) 持久化存儲卷

　　PersistentVolume(PV)是集群之中的一塊網絡存儲。跟 Node 一樣，也是集群的資源。PersistentVolume (PV)和PersistentVolumeClaim (PVC)提供了方便的持久化卷: PV提供網絡存儲資源，而PVC請求存儲資源并將其掛載到Pod中。

　　PV的訪問模式(accessModes)有三種:

　　ReadWriteOnce(RWO):是最基本的方式，可讀可寫，但只支持被單個Pod掛載。
　　ReadOnlyMany(ROX):可以以只讀的方式被多個Pod掛載。
　　ReadWriteMany(RWX):這種存儲可以以讀寫的方式被多個Pod共享。
　　不是每一種存儲都支持這三種方式，像共享方式，目前支持的還比較少，比較常用的是 NFS。在PVC綁定PV時通常根據兩個條件來綁定，一個是存儲的大小，另一個就是訪問模式。

　　PV的回收策略(persistentVolumeReclaimPolicy)也有三種

　　Retain，不清理保留Volume(需要手動清理)
　　Recycle，刪除數據，即 rm -rf /thevolume/* (只有NFS和HostPath支持)
　　Delete，刪除存儲資源
　　7、Deployment 無狀態應用

　　一般情況下我們不需要手動創建Pod實例，而是采用更高一層的抽象或定義來管理Pod，針對無狀態類型的應用，Kubernetes使用Deloyment的Controller對象與之對應。其典型的應用場景包括：

　　定義Deployment來創建Pod和ReplicaSet
　　滾動升級和回滾應用
　　擴容和縮容
　　暫停和繼續Deployment
　　常用的操作命令如下：

　　 kubectl run www--image=10.0.0.183:5000/hanker/www:0.0.1--port=8080 生成一個Deployment對象
　　kubectlgetdeployment--all-namespaces 查找Deployment
　　kubectl describe deployment www 查看某個Deployment
　　kubectl edit deployment www 編輯Deployment定義
　　kubectldeletedeployment www 刪除某Deployment
　　kubectl scale deployment/www--replicas=2 擴縮容操作，即修改Deployment下的Pod實例個數
　　kubectlsetimage deployment/nginx-deployment nginx=nginx:1.9.1更新鏡像
　　kubectl rollout undo deployment/nginx-deployment 回滾操作
　　kubectl rollout status deployment/nginx-deployment 查看回滾進度
　　kubectl autoscale deployment nginx-deployment--min=10--max=15--cpu-percent=80 啟用水平伸縮（HPA - horizontal pod autoscaling），設置最小、最大實例數量以及目標cpu使用率
　　kubectl rollout pause deployment/nginx-deployment 暫停更新Deployment
　　kubectl rollout resume deploy nginx 恢復更新Deployment
　　更新策略

　　.spec.strategy 指新的Pod替換舊的Pod的策略，有以下兩種類型

　　RollingUpdate 滾動升級，可以保證應用在升級期間，對外正常提供服務。
　　Recreate 重建策略，在創建出新的Pod之前會先殺掉所有已存在的Pod。
　　Deployment和ReplicaSet兩者之間的關系

　　使用Deployment來創建ReplicaSet。ReplicaSet在后臺創建pod，檢查啟動狀態，看它是成功還是失敗。
　　當執行更新操作時，會創建一個新的ReplicaSet，Deployment會按照控制的速率將pod從舊的ReplicaSet移動到新的ReplicaSet中
　　8、StatefulSet 有狀態應用

　　Deployments和ReplicaSets是為無狀態服務設計的，那么StatefulSet則是為了有狀態服務而設計，其應用場景包括：

　　穩定的持久化存儲，即Pod重新調度后還是能訪問到相同的持久化數據，基于PVC來實現
　　穩定的網絡標志，即Pod重新調度后其PodName和HostName不變，基于Headless Service(即沒有Cluster IP的Service)來實現
　　有序部署，有序擴展，即Pod是有順序的，在部署或者擴展的時候要依據定義的順序依次進行操作(即從0到N-1，在下一個Pod運行之前所有之前的Pod必須都是Running和Ready狀態)，基于init containers來實現
　　有序收縮，有序刪除(即從N-1到0)
　　支持兩種更新策略：

　　OnDelete:當 .spec.template更新時，并不立即刪除舊的Pod，而是等待用戶手動刪除這些舊Pod后自動創建新Pod。這是默認的更新策略，兼容v1.6版本的行為
　　RollingUpdate:當 .spec.template 更新時，自動刪除舊的Pod并創建新Pod替換。在更新時這些Pod是按逆序的方式進行，依次刪除、創建并等待Pod變成Ready狀態才進行下一個Pod的更新。
　　9、DaemonSet 守護進程集

　　DaemonSet保證在特定或所有Node節點上都運行一個Pod實例，常用來部署一些集群的日志采集、監控或者其他系統管理應用。典型的應用包括:

　　日志收集，比如fluentd，logstash等
　　系統監控，比如Prometheus Node Exporter，collectd等
　　系統程序，比如kube-proxy, kube-dns, glusterd, ceph，ingress-controller等
　　指定Node節點

　　DaemonSet會忽略Node的unschedulable狀態，有兩種方式來指定Pod只運行在指定的Node節點上:

　　nodeSelector:只調度到匹配指定label的Node上
　　nodeAffinity:功能更豐富的Node選擇器，比如支持集合操作
　　podAffinity:調度到滿足條件的Pod所在的Node上
　　目前支持兩種策略

　　OnDelete: 默認策略，更新模板后，只有手動刪除了舊的Pod后才會創建新的Pod
　　RollingUpdate: 更新DaemonSet模版后，自動刪除舊的Pod并創建新的Pod
　　10、Ingress

　　Kubernetes中的負載均衡我們主要用到了以下兩種機制：

　　Service：使用Service提供集群內部的負載均衡，Kube-proxy負責將service請求負載均衡到后端的Pod中
　　Ingress Controller：使用Ingress提供集群外部的負載均衡
　　Service和Pod的IP僅可在集群內部訪問。集群外部的請求需要通過負載均衡轉發到service所在節點暴露的端口上，然后再由kube-proxy通過邊緣路由器將其轉發到相關的Pod，Ingress可以給service提供集群外部訪問的URL、負載均衡、HTTP路由等，為了配置這些Ingress規則，集群管理員需要部署一個Ingress Controller，它監聽Ingress和service的變化，并根據規則配置負載均衡并提供訪問入口。

　　常用的ingress controller：

　　nginx
　　 traefik
　　Kong
　　Openresty
　　11、Job & CronJob 任務和定時任務

　　Job負責批量處理短暫的一次性任務 (short lived>CronJob即定時任務，就類似于Linux系統的crontab，在指定的時間周期運行指定的任務。

　　12、HPA（Horizontal Pod Autoscaling）水平伸縮

　　Horizontal Pod Autoscaling可以根據CPU、內存使用率或應用自定義metrics自動擴展Pod數量 (支持replication controller、deployment和replica set)。

　　控制管理器默認每隔30s查詢metrics的資源使用情況(可以通過 --horizontal-pod-autoscaler-sync-period 修改)
　　支持三種metrics類型
　　預定義metrics(比如Pod的CPU)以利用率的方式計算
　　自定義的Pod metrics，以原始值(raw value)的方式計算
　　自定義的object metrics
　　支持兩種metrics查詢方式:Heapster和自定義的REST API
　　支持多metrics
　　可以通過如下命令創建HPA：kubectl autoscale deployment php-apache--cpu-percent=50--min=1--max=10

　　13、Service Account

　　Service account是為了方便Pod里面的進程調用Kubernetes API或其他外部服務而設計的

　　授權

　　Service Account為服務提供了一種方便的認證機制，但它不關心授權的問題。可以配合RBAC(Role Based Access Control)來為Service Account鑒權，通過定義Role、RoleBinding、ClusterRole、ClusterRoleBinding來對sa進行授權。

　　14、Secret 密鑰

　　Sercert-密鑰解決了密碼、token、密鑰等敏感數據的配置問題，而不需要把這些敏感數據暴露到鏡像或者Pod Spec中。Secret可以以Volume或者環境變量的方式使用。有如下三種類型：

　　Service Account:用來訪問Kubernetes API，由Kubernetes自動創建，并且會自動掛載到Pod的 /run/secrets/kubernetes.io/serviceaccount 目錄中;
　　Opaque:base64編碼格式的Secret，用來存儲密碼、密鑰等;
　　kubernetes.io/dockerconfigjson: 用來存儲私有docker registry的認證信息。
　　15、ConfigMap 配置中心

　　ConfigMap用于保存配置數據的鍵值對，可以用來保存單個屬性，也可以用來保存配置文件。ConfigMap跟secret很類似，但它可以更方便地處理不包含敏感信息的字符串。ConfigMap可以通過三種方式在Pod中使用，三種分別方式為:設置環境變量、設置容器命令行參數以及在Volume中直接掛載文件或目錄。

　　可以使用 kubectl create configmap從文件、目錄或者key-value字符串創建等創建 ConfigMap。也可以通過 kubectl create-f value.yaml 創建。

　　16、Resource Quotas 資源配額

　　資源配額(Resource Quotas)是用來限制用戶資源用量的一種機制。

　　資源配額有如下類型：

　　計算資源，包括cpu和memory
　　 cpu, limits.cpu, requests.cpu
　　 memory, limits.memory, requests.memory
　　存儲資源，包括存儲資源的總量以及指定storage class的總量
　　 requests.storage:存儲資源總量，如500Gi
　　 persistentvolumeclaims:pvc的個數
　　 storageclass.storage.k8s.io/requests.storage
　　 storageclass.storage.k8s.io/persistentvolumeclaims
　　對象數，即可創建的對象的個數
　　 pods, replicationcontrollers, configmaps, secrets
　　 resourcequotas, persistentvolumeclaims
　　 services, services.loadbalancers, services.nodeports
　　它的工作原理為:

　　資源配額應用在Namespace上，并且每個Namespace最多只能有一個 ResourceQuota 對象
　　開啟計算資源配額后，創建容器時必須配置計算資源請求或限制(也可以用LimitRange設置默認值)，用戶超額后禁止創建新的資源。

（編輯：武林網）

上一篇：CentOS Stream 9在下一代服務器CPU上表現優秀

下一篇：LNMP環境給PHP安裝APC擴展模塊