[toc]
k8s 入門之16個基本概念
Kubernetes是Google開源的容?集群管理系統(tǒng)趴乡,是Google多年?規(guī)模容?管理技術(shù)Borg的開源版本月而,主要功能包括:
- 基于容器的應(yīng)用部署、維護和滾動升級
- 負載均衡和服務(wù)發(fā)現(xiàn)
- 跨機器和跨地區(qū)的集群調(diào)度
- 自動伸縮
- 無狀態(tài)服務(wù)和有狀態(tài)服務(wù)
- 廣泛的Volume支持
- 插件機制保證擴展性
- Kubernetes發(fā)展非常迅速差购,已經(jīng)成為容器編排領(lǐng)域的領(lǐng)導(dǎo)者腰埂,接下來我們將講解Kubernetes中涉及到的一些主要概念
一. pod
Pod是一組緊密關(guān)聯(lián)的容器集合西饵,支持多個容器在一個Pod中共享網(wǎng)絡(luò)和文件系統(tǒng),可以通過進程間通信和文件共享這種簡單高效的方式完成服務(wù)躺翻,是Kubernetes調(diào)度的基本單位丧叽。Pod的設(shè)計理念是每個Pod都有一個唯一的IP。
Pod具有如下特征:
- 包含多個共享IPC公你、Network和UTC namespace的容器踊淳,可直接通過localhost通信
- 所有Pod內(nèi)容器都可以訪問共享的Volume,可以訪問共享數(shù)據(jù)
- 優(yōu)雅終止:Pod刪除的時候先給其內(nèi)的進程發(fā)送SIGTERM陕靠,等待一段時間(grace period)后才強制停止依然還在運行的進程
- 特權(quán)容器(通過SecurityContext配置)具有改變系統(tǒng)配置的權(quán)限(在網(wǎng)絡(luò)插件中大量應(yīng)用)
- 支持三種重啟策略(restartPolicy)迂尝,分別是:Always脱茉、OnFailure、Never
- 支持三種鏡像拉取策略(imagePullPolicy)垄开,分別是:Always琴许、Never、IfNotPresent
- 資源限制溉躲,Kubernetes通過CGroup限制容器的CPU以及內(nèi)存等資源榜田,可以設(shè)置request以及l(fā)imit值
- 健康檢查,提供兩種健康檢查探針签财,分別是livenessProbe和redinessProbe串慰,前者用于探測容器是否存活,如果探測失敗唱蒸,則根據(jù)重啟策略進行重啟操作邦鲫,后者用于檢查容器狀態(tài)是否正常,如果檢查容器狀態(tài)不正常神汹,則請求不會到達該Pod
- Init container在所有容器運行之前執(zhí)行庆捺,常用來初始化配置
- 容器生命周期鉤子函數(shù),用于監(jiān)聽容器生命周期的特定事件屁魏,并在事件發(fā)生時執(zhí)行已注冊的回調(diào)函數(shù)滔以,支持兩種鉤子函數(shù):postStart和preStop,前者是在容器啟動后執(zhí)行氓拼,后者是在容器停止前執(zhí)行
二. Namesace
Namespace(命名空間)是對一組資源和對象的抽象集合你画,比如可以用來將系統(tǒng)內(nèi)部的對象劃分為不同的項目組或者用戶組。常見的pod桃漾、service坏匪、replicaSet和deployment等都是屬于某一個namespace的(默認(rèn)是default),而node, persistentVolumes等則不屬于任何namespace撬统。
常用namespace操作:
- kubectl get namespace, 查詢所有namespace
- kubectl create namespacens-name适滓,創(chuàng)建namespace
- kubectl delete namespacens-name, 刪除namespace
刪除命名空間時,需注意以下幾點: - 刪除一個namespace會自動刪除所有屬于該namespace的資源恋追。
- default 和 kube-system 命名空間不可刪除凭迹。
- PersistentVolumes是不屬于任何namespace的,但PersistentVolumeClaim是屬于某個特定namespace的苦囱。
- Events是否屬于namespace取決于產(chǎn)生events的對象嗅绸。
三. Node
Node是Pod真正運行的主機,可以是物理機也可以是虛擬機沿彭。Node本質(zhì)上不是Kubernetes來創(chuàng)建的朽砰, Kubernetes只是管理Node上的資源。為了管理Pod,每個Node節(jié)點上至少需要運行container runtime(Docker)瞧柔、kubelet和kube-proxy服務(wù)漆弄。
常用node操作:
- kubectlgetnodes,查詢所有node
- kubectl cordon $nodename, 將node標(biāo)志為不可調(diào)度
- kubectl uncordon $nodename, 將node標(biāo)志為可調(diào)度
taint(污點)
使用kubectl taint命令可以給某個Node節(jié)點設(shè)置污點造锅,Node被設(shè)置上污點之后就和Pod之間存在了一種相斥的關(guān)系撼唾,可以讓Node拒絕Pod的調(diào)度執(zhí)行,甚至將Node已經(jīng)存在的Pod驅(qū)逐出去哥蔚。每個污點的組成:key=value:effect倒谷,當(dāng)前taint effect支持如下三個選項: - NoSchedule:表示k8s將不會將Pod調(diào)度到具有該污點的Node上
- PreferNoSchedule:表示k8s將盡量避免將Pod調(diào)度到具有該污點的Node上
- NoExecute:表示k8s將不會將Pod調(diào)度到具有該污點的Node上,同時會將Node上已經(jīng)存在的Pod驅(qū)逐出去
常用命令如下: - kubectl taint node node0 key1=value1:NoShedule糙箍,為node0設(shè)置不可調(diào)度污點
- kubectl taint node node0 key-渤愁,將node0上key值為key1的污點移除
- kubectl taint node node1 node-role.kubernetes.io/master=:NoSchedule,為kube-master節(jié)點設(shè)置不可調(diào)度污點
- kubectl taint node node1 node-role.kubernetes.io/master=PreferNoSchedule深夯,為kube-master節(jié)點設(shè)置盡量不可調(diào)度污點
容忍(Tolerations)
設(shè)置了污點的Node將根據(jù)taint的effect:NoSchedule抖格、PreferNoSchedule、NoExecute和Pod之間產(chǎn)生互斥的關(guān)系咕晋,Pod將在一定程度上不會被調(diào)度到Node上雹拄。 但我們可以在Pod上設(shè)置容忍(Toleration),意思是設(shè)置了容忍的Pod將可以容忍污點的存在掌呜,可以被調(diào)度到存在污點的Node上滓玖。
四. Service
Service是對一組提供相同功能的Pods的抽象,并為他們提供一個統(tǒng)一的入口质蕉,借助 Service 應(yīng)用可以方便的實現(xiàn)服務(wù)發(fā)現(xiàn)與負載均衡势篡,并實現(xiàn)應(yīng)用的零宕機升級。Service通過標(biāo)簽(label)來選取后端Pod模暗,一般配合ReplicaSet或者Deployment來保證后端容器的正常運行殊霞。
service 有如下四種類型,默認(rèn)是ClusterIP:
- ClusterIP: 默認(rèn)類型汰蓉,自動分配一個僅集群內(nèi)部可以訪問的虛擬IP
- NodePort: 在ClusterIP基礎(chǔ)上為Service在每臺機器上綁定一個端口,這樣就可以通過 NodeIP:NodePort 來訪問該服務(wù)
- LoadBalancer: 在NodePort的基礎(chǔ)上棒卷,借助cloud provider創(chuàng)建一個外部的負載均衡器顾孽,并將請求轉(zhuǎn)發(fā)到 NodeIP:NodePort
- ExternalName: 將服務(wù)通過DNS CNAME記錄方式轉(zhuǎn)發(fā)到指定的域名
另外,也可以將已有的服務(wù)以Service的形式加入到Kubernetes集群中來比规,只需要在創(chuàng)建 Service 的時候不指定Label selector若厚,而是在Service創(chuàng)建好后手動為其添加endpoint
五. Volume
默認(rèn)情況下容器的數(shù)據(jù)是非持久化的,容器消亡以后數(shù)據(jù)也會跟著丟失蜒什,所以Docker提供了Volume機制以便將數(shù)據(jù)持久化存儲测秸。Kubernetes提供了更強大的Volume機制和插件,解決了容器數(shù)據(jù)持久化以及容器間共享數(shù)據(jù)的問題。
Kubernetes存儲卷的生命周期與Pod綁定
- 容器掛掉后Kubelet再次重啟容器時霎冯,Volume的數(shù)據(jù)依然還在
- Pod刪除時铃拇,Volume才會清理。數(shù)據(jù)是否丟失取決于具體的Volume類型沈撞,比如emptyDir的數(shù)據(jù)會丟失慷荔,而PV的數(shù)據(jù)則不會丟
目前Kubernetes主要支持以下Volume類型: - emptyDir:Pod存在,emptyDir就會存在缠俺,容器掛掉不會引起emptyDir目錄下的數(shù)據(jù)丟失显晶,但是pod被刪除或者遷移,emptyDir也會被刪除
- hostPath:hostPath允許掛載Node上的文件系統(tǒng)到Pod里面去
- NFS(Network File System):網(wǎng)絡(luò)文件系統(tǒng)壹士,Kubernetes中通過簡單地配置就可以掛載NFS到Pod中磷雇,而NFS中的數(shù)據(jù)是可以永久保存的,同時NFS支持同時寫操作躏救。
- glusterfs:同NFS一樣是一種網(wǎng)絡(luò)文件系統(tǒng)唯笙,Kubernetes可以將glusterfs掛載到Pod中,并進行永久保存
- cephfs:一種分布式網(wǎng)絡(luò)文件系統(tǒng)落剪,可以掛載到Pod中睁本,并進行永久保存
- subpath:Pod的多個容器使用同一個Volume時,會經(jīng)常用到
- secret:密鑰管理忠怖,可以將敏感信息進行加密之后保存并掛載到Pod中
- persistentVolumeClaim:用于將持久化存儲(PersistentVolume)掛載到Pod中
…
六. PersistentVolume(PV)
PersistentVolume(PV)是集群之中的一塊網(wǎng)絡(luò)存儲呢堰。跟 Node 一樣,也是集群的資源凡泣。PersistentVolume (PV)和PersistentVolumeClaim (PVC)提供了方便的持久化卷: PV提供網(wǎng)絡(luò)存儲資源枉疼,而PVC請求存儲資源并將其掛載到Pod中。
PV的訪問模式(accessModes)有三種:
- ReadWriteOnce(RWO):是最基本的方式鞋拟,可讀可寫骂维,但只支持被單個Pod掛載。
- ReadOnlyMany(ROX):可以以只讀的方式被多個Pod掛載贺纲。
- ReadWriteMany(RWX):這種存儲可以以讀寫的方式被多個Pod共享航闺。
不是每一種存儲都支持這三種方式,像共享方式猴誊,目前支持的還比較少潦刃,比較常用的是 NFS。在PVC綁定PV時通常根據(jù)兩個條件來綁定懈叹,一個是存儲的大小乖杠,另一個就是 訪問模式。 - PV的回收策略(persistentVolumeReclaimPolicy)也有三種
- Retain澄成,不清理保留Volume(需要手動清理)
- Recycle胧洒,刪除數(shù)據(jù)畏吓,即 rm -rf /thevolume/* (只有NFS和HostPath支持)
- Delete,刪除存儲資源
七. Deployment
一般情況下我們不需要手動創(chuàng)建Pod實例卫漫,而是采用更高一層的抽象或定義來管理Pod菲饼,針對無狀態(tài)類型的應(yīng)用,Kubernetes使用Deloyment的Controller對象與之對應(yīng)汛兜。其典型的應(yīng)用場景包括:
- 定義Deployment來創(chuàng)建Pod和ReplicaSet
- 滾動升級和回滾應(yīng)用
- 擴容和縮容
- 暫停和繼續(xù)Deployment
常用的操作命令如下: - kubectl run www–image=10.0.0.183:5000/hanker/www:0.0.1–port=8080 生成一個Deployment對象
- kubectl get deployment –all-namespaces 查找Deployment
- kubectl describe deployment www 查看某個Deployment
- kubectl edit deployment www 編輯Deployment定義
- kubectl delete deployment www 刪除某Deployment
- kubectl scale deployment/www–replicas=2 擴縮容操作巴粪,即修改Deployment下的Pod實例個數(shù)
- kubectl set image 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),設(shè)置最小粥谬、最大實例數(shù)量以及目標(biāo)cpu使用率
- kubectl rollout pause deployment/nginx-deployment 暫停更新Deployment
- kubectl rollout resume deploy nginx 恢復(fù)更新Deployment
更新策略
.spec.strategy 指新的Pod替換舊的Pod的策略肛根,有以下兩種類型 - RollingUpdate 滾動升級,可以保證應(yīng)用在升級期間漏策,對外正常提供服務(wù)派哲。
- Recreate 重建策略,在創(chuàng)建出新的Pod之前會先殺掉所有已存在的Pod掺喻。
Deployment和ReplicaSet兩者之間的關(guān)系 - 使用Deployment來創(chuàng)建ReplicaSet芭届。ReplicaSet在后臺創(chuàng)建pod,檢查啟動狀態(tài)感耙,看它是成功還是失敗褂乍。
- 當(dāng)執(zhí)行更新操作時,會創(chuàng)建一個新的ReplicaSet即硼,Deployment會按照控制的速率將pod從舊的ReplicaSet移 動到新的ReplicaSet中
八. StatefulSet
Deployments和ReplicaSets是為無狀態(tài)服務(wù)設(shè)計的逃片,那么StatefulSet則是為了有狀態(tài)服務(wù)而設(shè)計,其應(yīng)用場景包括:
- 穩(wěn)定的持久化存儲只酥,即Pod重新調(diào)度后還是能訪問到相同的持久化數(shù)據(jù)褥实,基于PVC來實現(xiàn)
- 穩(wěn)定的網(wǎng)絡(luò)標(biāo)志,即Pod重新調(diào)度后其PodName和HostName不變裂允,基于Headless Service(即沒有Cluster IP的Service)來實現(xiàn)
- 有序部署损离,有序擴展,即Pod是有順序的绝编,在部署或者擴展的時候要依據(jù)定義的順序依次進行操作(即從0到N-1僻澎,在下一個Pod運行之前所有之前的Pod必須都是Running和Ready狀態(tài)),基于init containers來實現(xiàn)
- 有序收縮十饥,有序刪除(即從N-1到0)
支持兩種更新策略: - OnDelete:當(dāng) .spec.template更新時怎棱,并不立即刪除舊的Pod,而是等待用戶手動刪除這些舊Pod后自動創(chuàng)建新Pod绷跑。這是默認(rèn)的更新策略,兼容v1.6版本的行為
- RollingUpdate:當(dāng) .spec.template 更新時凡资,自動刪除舊的Pod并創(chuàng)建新Pod替換砸捏。在更新時這些Pod是按逆序的方式進行谬运,依次刪除、創(chuàng)建并等待Pod變成Ready狀態(tài)才進行下一個Pod的更新
九. DaemonSet
DaemonSet保證在特定或所有Node節(jié)點上都運行一個Pod實例垦藏,常用來部署一些集群的日志采集梆暖、監(jiān)控或者其他系統(tǒng)管理應(yīng)用。典型的應(yīng)用包括:
- 日志收集掂骏,比如fluentd轰驳,logstash等
- 系統(tǒng)監(jiān)控,比如Prometheus Node Exporter弟灼,collectd等
- 系統(tǒng)程序级解,比如kube-proxy, kube-dns, glusterd, ceph,ingress-controller等
指定Node節(jié)點
DaemonSet會忽略Node的unschedulable狀態(tài)田绑,有兩種方式來指定Pod只運行在指定的Node節(jié)點上: - nodeSelector:只調(diào)度到匹配指定label的Node上
- nodeAffinity:功能更豐富的Node選擇器勤哗,比如支持集合操作
- podAffinity:調(diào)度到滿足條件的Pod所在的Node上
目前支持兩種策略 - OnDelete: 默認(rèn)策略,更新模板后掩驱,只有手動刪除了舊的Pod后才會創(chuàng)建新的Pod
- RollingUpdate: 更新DaemonSet模版后芒划,自動刪除舊的Pod并創(chuàng)建新的Pod
十. Ingress
Kubernetes中的負載均衡我們主要用到了以下兩種機制:
- Service:使用Service提供集群內(nèi)部的負載均衡,Kube-proxy負責(zé)將service請求負載均衡到后端的Pod中
- Ingress Controller:使用Ingress提供集群外部的負載均衡
Service和Pod的IP僅可在集群內(nèi)部訪問欧穴。集群外部的請求需要通過負載均衡轉(zhuǎn)發(fā)到service所在節(jié)點暴露的端口上民逼,然后再由kube-proxy通過邊緣路由器將其轉(zhuǎn)發(fā)到相關(guān)的Pod,Ingress可以給service提供集群外部訪問的URL涮帘、負載均衡拼苍、HTTP路由等,為了配置這些Ingress規(guī)則焚辅,集群管理員需要部署一個Ingress Controller映屋,它監(jiān)聽Ingress和service的變化,并根據(jù)規(guī)則配置負載均衡并提供訪問入口同蜻。
常用的ingress controller: - nginx
- traefik
- Kong
- Openresty
十一. Job 和 CronJob
Job負責(zé)批量處理短暫的一次性任務(wù) (short lived>CronJob即定時任務(wù)棚点,就類似于Linux系統(tǒng)的crontab,在指定的時間周期運行指定的任務(wù)湾蔓。
十二. HPA
Horizontal Pod Autoscaling可以根據(jù)CPU敲街、內(nèi)存使用率或應(yīng)用自定義metrics自動擴展Pod數(shù)量 (支持replication controller、deployment和replica set)幌墓。
- 控制管理器默認(rèn)每隔30s查詢metrics的資源使用情況(可以通過 –horizontal-pod-autoscaler-sync-period 修改)
- 支持三種metrics類型
- 預(yù)定義metrics(比如Pod的CPU)以利用率的方式計算
- 自定義的Pod metrics句柠,以原始值(raw value)的方式計算
- 自定義的object metrics
- 支持兩種metrics查詢方式:Heapster和自定義的REST API
- 支持多metrics
可以通過如下命令創(chuàng)建HPA:kubectl autoscale deployment php-apache–cpu-percent=50–min=1–max=10
十三. Service Account
Service account是為了方便Pod里面的進程調(diào)用Kubernetes API或其他外部服務(wù)而設(shè)計的
授權(quán)
Service Account為服務(wù)提供了一種方便的認(rèn)證機制,但它不關(guān)心授權(quán)的問題桃序≌认海可以配合RBAC(Role Based Access Control)來為Service Account鑒權(quán),通過定義Role媒熊、RoleBinding奇适、ClusterRole坟比、ClusterRoleBinding來對sa進行授權(quán)
十四. Secret
Sercert-密鑰解決了密碼、token嚷往、密鑰等敏感數(shù)據(jù)的配置問題葛账,而不需要把這些敏感數(shù)據(jù)暴露到鏡像或者Pod Spec中。Secret可以以Volume或者環(huán)境變量的方式使用皮仁。有如下三種類型:
- Service Account:用來訪問Kubernetes API籍琳,由Kubernetes自動創(chuàng)建,并且會自動掛載到Pod的 /run/secrets/kubernetes.io/serviceaccount 目錄中;
- Opaque:base64編碼格式的Secret贷祈,用來存儲密碼趋急、密鑰等;
- kubernetes.io/dockerconfigjson: 用來存儲私有docker registry的認(rèn)證信息。
十五. ConfigMap
ConfigMap用于保存配置數(shù)據(jù)的鍵值對付燥,可以用來保存單個屬性宣谈,也可以用來保存配置文件。ConfigMap跟secret很類似键科,但它可以更方便地處理不包含敏感信息的字符串闻丑。ConfigMap可以通過三種方式在Pod中使用,三種分別方式為:設(shè)置環(huán)境變量勋颖、設(shè)置容器命令行參數(shù)以及在Volume中直接掛載文件或目錄嗦嗡。
可以使用 kubectl create configmap從文件、目錄或者key-value字符串創(chuàng)建等創(chuàng)建 ConfigMap饭玲。也可以通過 kubectl create-f value.yaml 創(chuàng)建侥祭。
十六. Resource Quotas
資源配額(Resource Quotas)是用來限制用戶資源用量的一種機制。
資源配額有如下類型:
- 計算資源茄厘,包括cpu和memory
- cpu, limits.cpu, requests.cpu
- memory, limits.memory, requests.memory
- 存儲資源矮冬,包括存儲資源的總量以及指定storage class的總量
- requests.storage:存儲資源總量,如500Gi
- persistentvolumeclaims:pvc的個數(shù)
- storageclass.storage.k8s.io/requests.storage
- storageclass.storage.k8s.io/persistentvolumeclaims
- 對象數(shù)次哈,即可創(chuàng)建的對象的個數(shù)
- pods, replicationcontrollers, configmaps, secrets
- resourcequotas, persistentvolumeclaims
- services, services.loadbalancers, services.nodeports
它的工作原理為:
- 資源配額應(yīng)用在Namespace上胎署,并且每個Namespace最多只能有一個 ResourceQuota 對象
- 開啟計算資源配額后,創(chuàng)建容器時必須配置計算資源請求或限制(也可以 用LimitRange設(shè)置默認(rèn)值)
- 用戶超額后禁止創(chuàng)建新的資源