文章轉自 K8S中文社區!
我已經讀了一遍,非常到位,很詳細!
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設置默認值)
- 用戶超額後禁止創建新的資源
END
閱讀更多 IT程序員王者 的文章