Kubernetes

• Kubernetes主要由以下幾個(gè)核心組件組成：

  • etcd：保存了整個(gè)集群的狀態(tài)；
  • apiserver：提供了資源操作的唯一入口，并提供認(rèn)證、授權(quán)、訪問(wèn)控制、API注冊(cè)和發(fā)現(xiàn)等機(jī)制；
  • controller manager：負(fù)責(zé)維護(hù)集群的狀態(tài)，比如故障檢測(cè)、自動(dòng)擴(kuò)展、滾動(dòng)更新等；
  • scheduler：負(fù)責(zé)資源的調(diào)度，按照預(yù)定的調(diào)度策略將Pod調(diào)度到相應(yīng)的機(jī)器上；
  • kubelet：負(fù)責(zé)維護(hù)容器的生命周期，同時(shí)也負(fù)責(zé)Volume（CVI）和網(wǎng)絡(luò)（CNI）的管理；
  • Container runtime：負(fù)責(zé)鏡像管理以及Pod和容器的真正運(yùn)行（CRI）；
  • kube-proxy：負(fù)責(zé)為Service提供cluster內(nèi)部的服務(wù)發(fā)現(xiàn)和負(fù)載均衡；

• 除了核心組件，還有一些推薦的Add-ons：

  • kube-dns負(fù)責(zé)為整個(gè)集群提供DNS服務(wù)
  • Ingress Controller為服務(wù)提供外網(wǎng)入口
  • Heapster提供資源監(jiān)控
  • Dashboard提供GUI
  • Federation提供跨可用區(qū)的集群
  • Fluentd-elasticsearch提供集群日志采集、存儲(chǔ)與查詢

Pod

Pod 概述

• Pod 是 k8s 系統(tǒng)中可以創(chuàng)建和管理的最小單元，是資源對(duì)象模型中由用戶創(chuàng)建或部署的最小資源對(duì)象模型，也是在 k8s 上運(yùn)行容器化應(yīng)用的資源對(duì)象，其他的資源對(duì)象都是用來(lái)支撐或者擴(kuò)展 Pod 對(duì)象功能的，比如控制器對(duì)象是用來(lái)管控 Pod 對(duì)象的，Service 或者Ingress 資源對(duì)象是用來(lái)暴露 Pod 引用對(duì)象的，PersistentVolume 資源對(duì)象是用來(lái)為Pod提供存儲(chǔ)等等，k8s 不會(huì)直接處理容器，而是 Pod，Pod 是由一個(gè)或多個(gè)container 組成。
• Pod 是 Kubernetes 的最重要概念，每一個(gè) Pod 都有一個(gè)特殊的被稱為”根容器“的Pause容器。Pause 容器對(duì)應(yīng)的鏡像屬于 Kubernetes 平臺(tái)的一部分，除了Pause 容器，每個(gè)Pod還包含一個(gè)或多個(gè)緊密相關(guān)的用戶業(yè)務(wù)容器。

Pod 的分類

普通 Pod

• 普通 Pod 一旦被創(chuàng)建，就會(huì)被放入到 etcd 中存儲(chǔ)，隨后會(huì)被 Kubernetes Master 調(diào)度到某個(gè)具體的 Node 上并進(jìn)行綁定，隨后該 Pod 對(duì)應(yīng)的 Node 上的 kubelet 進(jìn)程實(shí)例化成一組相關(guān)的 Docker 容器并啟動(dòng)起來(lái)。在默認(rèn)情 況下，當(dāng) Pod 里某個(gè)容器停止時(shí)，Kubernetes 會(huì)自動(dòng)檢測(cè)到這個(gè)問(wèn)題并且重新啟動(dòng)這個(gè) Pod 里某所有容器， 如果 Pod 所在的Node 宕機(jī)，則會(huì)將這個(gè) Node 上的所有 Pod 重新調(diào)度到其它節(jié)點(diǎn)上。

靜態(tài) Pod

• 靜態(tài) Pod 是由 kubelet 進(jìn)行管理的僅存在于特定 Node 上的 Pod,它們不能通過(guò)API Server進(jìn)行管理，無(wú)法與 ReplicationController、Deployment 或 DaemonSet 進(jìn)行關(guān)聯(lián)，并且kubelet 也無(wú)法對(duì)它們進(jìn)行健康檢查。

Pod 生命周期和重啟策略

Pod 的狀態(tài)

2515f0ff002849098babb4e5f417fd19.png

Pod 重啟策略

2.png

常見(jiàn)狀態(tài)轉(zhuǎn)換

3.png

Label

Label 概述

• Label 是 Kubernetes 系統(tǒng)中另一個(gè)核心概念。一個(gè) Label 是一個(gè) key=value 的鍵值對(duì)，其中 key 與 value 由用戶自己指 定。Label 可以附加到各種資源對(duì)象上，如Node、Pod、Service、RC，一個(gè)資源對(duì)象可以定義任意數(shù)量的 Label， 同一個(gè) Label 也可以被添加到任意數(shù)量的資源對(duì)象上，Label 通常在資源對(duì)象定義時(shí)確定，也可以在對(duì)象創(chuàng)建后動(dòng)態(tài)添加或刪除。
• Label 的最常見(jiàn)的用法是使用 metadata.labels 字段，來(lái)為對(duì)象添加Label，通過(guò)spec.selector 來(lái)引用對(duì)象
• Label 附加到 Kubernetes 集群中各種資源對(duì)象上，目的就是對(duì)這些資源對(duì)象進(jìn)行分組管理，而分組管理的核心就 是 Label Selector。Label 與 Label Selector 都是不能單獨(dú)定義，必須附加在一些資源對(duì)象的定義文件上，一般附加 在 RC 和 Service 的資源定義文件中。

Controller 控制器

• Replication Controller(RC)是 Kubernetes 系統(tǒng)中核心概念之一，當(dāng)我們定義了一個(gè)RC并提交到 Kubernetes 集群中以后，Master 節(jié)點(diǎn)上的 Controller Manager 組件就得到通知，定期檢查系統(tǒng)中存活的 Pod,并確保目標(biāo) Pod 實(shí)例的數(shù)量剛好等于 RC 的預(yù)期值，如果有過(guò)多或過(guò)少的 Pod 運(yùn)行，系統(tǒng)就會(huì)停掉或創(chuàng)建一些 Pod。此外我們也可以通過(guò)修改RC 的副本數(shù)量，來(lái)實(shí)現(xiàn) Pod 的動(dòng)態(tài)縮放功能。

• Replication Controller 與 Kubernetes 代碼中的模塊 Replication Controller 同名，所以在 Kubernetes v1.2 時(shí)， 它就升級(jí)成了另外一個(gè)新的概念 Replica Sets,官方解釋為下一代的 RC，它與 RC 區(qū)別是:Replica Sets 支援基于集合的 Label selector,而RC 只支持基于等式的 Label Selector。我們很少單獨(dú)使用 Replica Set,它主要被Deployment 這個(gè)更高層面的資源對(duì)象所使用，從而形成一整套 Pod 創(chuàng)建、刪除、更新的編排機(jī)制。最好不要越過(guò) RC 直接創(chuàng)建 Pod， 因?yàn)?Replication Controller 會(huì)通過(guò)RC 管理Pod 副本，實(shí)現(xiàn)自動(dòng)創(chuàng)建、補(bǔ)足、替換、刪除 Pod 副本，這樣就能提高應(yīng)用的容災(zāi)能力，減少由于節(jié)點(diǎn)崩潰等意外狀況造成的損失。即使應(yīng)用程序只有一個(gè) Pod 副本，也強(qiáng)烈建議使用RC 來(lái)定義 Pod。

• Replica Sets 支援基于集合的 Label selector,而RC 只支持基于等式的 Label Selector。我們很少單獨(dú)使用 Replica Set,它主要被Deployment 這個(gè)更高層面的資源對(duì)象所使用，從而形成一整套 Pod 創(chuàng)建、刪除、更新的編排機(jī)制。最好不要越過(guò) RC 直接創(chuàng)建 Pod， 因?yàn)?Replication Controller 會(huì)通過(guò)RC 管理Pod 副本，實(shí)現(xiàn)自動(dòng)創(chuàng)建、補(bǔ)足、替換、刪除 Pod 副本，這樣就能提高應(yīng)用的容災(zāi)能力，減少由于節(jié)點(diǎn)崩潰等意外狀況造成的損失。即使應(yīng)用程序只有一個(gè) Pod 副本，也強(qiáng)烈建議使用RC 來(lái)定義 Pod。

• Kubernetes 對(duì) Pod 擴(kuò)容與縮容提供了手動(dòng)和自動(dòng)兩種模式，手動(dòng)模式通過(guò)kubectl scale命令對(duì)一個(gè) Deployment/RC 進(jìn)行 Pod 副本數(shù)量的設(shè)置。自動(dòng)模式則需要用戶根據(jù)某個(gè)性能指標(biāo)或者自定義業(yè)務(wù)指標(biāo)，并指定 Pod 副本數(shù)量的范圍，系統(tǒng)將自動(dòng)在這個(gè)范圍內(nèi)根據(jù)性能指標(biāo)的變化進(jìn)行調(diào)整。

Volume

Volume 概述

• Volume 是 Pod 中能夠被多個(gè)容器訪問(wèn)的共享目錄。Kubernetes 的 Volume 定義在Pod 上，它被一個(gè) Pod 中的多個(gè)容器掛載到具體的文件目錄下。Volume 與 Pod 的生命周期相同，但與容器的生命周期不相關(guān)，當(dāng)容器終止或重啟時(shí)，Volume 中的數(shù)據(jù)也不會(huì)丟失。要使用volume，pod 需要指定 volume 的類型和內(nèi)容（ 字段），和映射到容器的位置（字段）。
• Kubernetes 支持多種類型的 Volume,包括：emptyDir、hostPath、gcePersistentDisk、awsElasticBlockStore、nfs、iscsi、flocker、glusterfs、rbd、cephfs、gitRepo、secret、persistentVolumeClaim、downwardAPI、azureFileVolume、azureDisk、vsphereVolume、Quobyte、PortworxVolume、ScaleIO。
  • emptyDirEmptyDir 類型的volume創(chuàng)建于 pod 被調(diào)度到某個(gè)宿主機(jī)上的時(shí)候，而同一個(gè) pod 內(nèi)的容器都能讀寫(xiě)EmptyDir 中的同一個(gè)文件。一旦這個(gè) pod 離開(kāi)了這個(gè)宿主機(jī)，EmptyDir 中的數(shù)據(jù)就會(huì)被永久刪除。所以目前 EmptyDir 類型的 volume 主要用作臨時(shí)空間，比如 Web 服務(wù)器寫(xiě)日志或者tmp 文件需要的臨時(shí)目錄。
  • HostPath 屬性的 volume 使得對(duì)應(yīng)的容器能夠訪問(wèn)當(dāng)前宿主機(jī)上的指定目錄。例如，需要運(yùn)行一個(gè)訪問(wèn) Docker 系統(tǒng)目錄的容器，那么就使用/var/lib/docker 目錄作為一個(gè)HostDir 類型的 volume；或者要在一個(gè)容器內(nèi)部運(yùn)行 CAdvisor，那么就使用/dev/cgroups目錄作為一個(gè) HostDir 類型的 volume。一旦這個(gè) pod 離開(kāi)了這個(gè)宿主機(jī)，HostDir 中的數(shù)據(jù)雖然不會(huì)被永久刪除，但數(shù)據(jù)也不會(huì)隨 pod 遷移到其他宿主機(jī)上。因此，需要注意的是，由于各個(gè)宿主機(jī)上的文件系統(tǒng)結(jié)構(gòu)和內(nèi)容并不一定完全相同，所以相同pod 的HostDir 可能會(huì)在不 同的宿主機(jī)上表現(xiàn)出不同的行為。
  • NFS 類型 volume,允許一塊現(xiàn)有的網(wǎng)絡(luò)硬盤(pán)在同一個(gè) pod 內(nèi)的容器間共享。

PVC 和 PV

基本概述

管理存儲(chǔ)是管理計(jì)算的一個(gè)明顯問(wèn)題。PersistentVolume 子系統(tǒng)為用戶和管理員提供了一個(gè) API，用于抽象如何根據(jù)消費(fèi)方式提供存儲(chǔ)的詳細(xì)信息。兩個(gè)新的API 資源：PersistentVolume 和 PersistentVolumeClaim。

• PersistentVolume（PV）是集群中由管理員配置的一段網(wǎng)絡(luò)存儲(chǔ)。 它是集群中的資源，就像節(jié)點(diǎn)是集群資源一樣。 PV 是容量插件，如 Volumes，但其生命周期獨(dú)立于使用PV 的任何單個(gè) pod。 此 API 對(duì)象捕獲存儲(chǔ)實(shí)現(xiàn)的詳細(xì)信息，包括 NFS，iSCSI 或特定于云提供程序的存儲(chǔ)系統(tǒng)。
• PersistentVolumeClaim（PVC）是由用戶進(jìn)行存儲(chǔ)的請(qǐng)求。 它類似于pod。Pod 消耗節(jié)點(diǎn)資源，PVC 消耗 PV 資源。Pod 可以請(qǐng)求特定級(jí)別的資源（CPU 和內(nèi)存）。聲明可以請(qǐng)求特定的大小和訪問(wèn)模式（例如，可以一次讀/寫(xiě)或多次只讀）。
• 雖然 PersistentVolumeClaims 允許用戶使用抽象存儲(chǔ)資源，但是 PersistentVolumes 對(duì)于不同的問(wèn)題，用戶通常需要具有不同屬性（例如性能）。群集管理員需要能夠提供各種PersistentVolumes 不同的方式，而不僅僅是大小和訪問(wèn)模式，而不會(huì)讓用戶了解這些卷的實(shí)現(xiàn)方式。對(duì)于這些需求，有 StorageClass 資源。
• StorageClass 為管理員提供了一種描述他們提供的存儲(chǔ)的“類”的方法。不同的類可能映射到服務(wù)質(zhì)量級(jí)別，或備份策略，或者由群集管理員確定的任意策略。Kubernetes 本身對(duì)于什么類別代表是不言而喻的。 這個(gè)概念有時(shí)在其他存儲(chǔ)系統(tǒng)中稱為“配置文件”。PVC 和 PV 是一一對(duì)應(yīng)的。

Secret

Secret 解決了密碼、token、密鑰等敏感數(shù)據(jù)的配置問(wèn)題，而不需要把這些敏感數(shù)據(jù)暴露到鏡像或者 Pod Spec 中。Secret 可以以 Volume 或者環(huán)境變量的方式使用。

Secret 有三種類型

• Service Account :用來(lái)訪問(wèn) Kubernetes API,由 Kubernetes 自動(dòng)創(chuàng)建，并且會(huì)自動(dòng)掛載到 Pod 的/run/secrets/kubernetes.io/serviceaccount 目錄中。
• Opaque : base64 編碼格式的 Secret,用來(lái)存儲(chǔ)密碼、密鑰等。
• kubernetes.io/dockerconfigjson ：用來(lái)存儲(chǔ)私有 docker registry 的認(rèn)證信息。

configMap

ConfigMap 概述

• ConfigMap 功能在 Kubernetes1.2 版本中引入，許多應(yīng)用程序會(huì)從配置文件、命令行參數(shù)或環(huán)境變量中讀取配 置信息。ConfigMap AP 丨給我們提供了向容器中注入配置信息的機(jī)制，ConfigMap 可以被用來(lái)保存單個(gè)屬性，也 可以用來(lái)保存整個(gè)配置文件或者JSON 二進(jìn)制大對(duì)象

Namespace

Namespace 概述

• Namespace 在很多情況下用于實(shí)現(xiàn)多用戶的資源隔離，通過(guò)將集群內(nèi)部的資源對(duì)象分配到不同的 Namespace 中， 形成邏輯上的分組，便于不同的分組在共享使用整個(gè)集群的資源同時(shí)還能被分別管理。Kubernetes 集群在啟動(dòng)后，會(huì)創(chuàng)建一個(gè)名為"default"的Namespace，如果不特別指明 Namespace,則用戶創(chuàng)建的 Pod，RC，Service 都將 被系統(tǒng)創(chuàng)建到這個(gè)默認(rèn)的名為 default 的 Namespace 中。

Namespace 查看

kubectl get pods --namespace=development

Service

Service 概述

• Service 是 Kubernetes 最核心概念，通過(guò)創(chuàng)建 Service,可以為一組具有相同功能的容器應(yīng)用提供一個(gè)統(tǒng)一的入口地 址，并且將請(qǐng)求負(fù)載分發(fā)到后端的各個(gè)容器應(yīng)用上。

探針

探針類型

• K8s 中存在兩種類型的探針：liveness probe 和 readiness probe。

liveness probe（存活探針）

• 用于判斷容器是否存活，即 Pod 是否為 running 狀態(tài)，如果 LivenessProbe 探針探測(cè)到容器不健康，則 kubelet 將 kill 掉容器，并根據(jù)容器的重啟策略是否重啟。如果一個(gè)容器不包含 LivenessProbe 探針，則 Kubelet 認(rèn)為容器的 LivenessProbe 探針的返回值永遠(yuǎn)成功。有時(shí)應(yīng)用程序可能因?yàn)槟承┰颍ê蠖朔?wù)故障等）導(dǎo)致暫時(shí)無(wú)法對(duì)外提供服務(wù)，但應(yīng)用軟件沒(méi)有終止，導(dǎo)致 K8S 無(wú)法隔離有故障的 pod，調(diào)用者可能會(huì)訪問(wèn)到有故障的pod，導(dǎo)致業(yè)務(wù)不穩(wěn)定。K8S 提供 livenessProbe 來(lái)檢測(cè)應(yīng)用程序是否正常運(yùn)行，并且對(duì)相應(yīng)狀況進(jìn)行相應(yīng)的補(bǔ)救措施。

readiness probe（就緒探針）

• 用于判斷容器是否啟動(dòng)完成，即容器的 Ready 是否為 True，可以接收請(qǐng)求，如果ReadinessProbe 探測(cè)失敗，則容器的 Ready 將為 False，控制器將此Pod 的Endpoint 從對(duì)應(yīng)的 service 的 Endpoint 列表中移除，從此不再將任何請(qǐng)求調(diào)度此Pod 上，直到下次探測(cè)成功。通過(guò)使用 Readiness 探針，Kubernetes 能夠等待應(yīng)用程序完全啟動(dòng)，然后才允許服務(wù)將流量發(fā)送到新副本。
• 比如使用 tomcat 的應(yīng)用程序來(lái)說(shuō)，并不是簡(jiǎn)單地說(shuō) tomcat 啟動(dòng)成功就可以對(duì)外提供服務(wù)的，還需要等待 spring 容器初始化，數(shù)據(jù)庫(kù)連接沒(méi)連上等等。對(duì)于spring boot 應(yīng)用，默認(rèn)的 actuator 帶有/health 接口，可以用來(lái)進(jìn)行啟動(dòng)成功的判斷。

每類探針都支持三種探測(cè)方法：

• （1）exec：通過(guò)執(zhí)行命令來(lái)檢查服務(wù)是否正常，針對(duì)復(fù)雜檢測(cè)或無(wú)HTTP 接口的服務(wù)，命令返回值為 0 則表示容器健康。
• （2）httpGet：通過(guò)發(fā)送 http 請(qǐng)求檢查服務(wù)是否正常，返回 200-399 狀態(tài)碼則表明容器健康。
• （3）tcpSocket：通過(guò)容器的 IP 和 Port 執(zhí)行 TCP 檢查，如果能夠建立TCP 連接，則表明容器健康。

探針探測(cè)的結(jié)果

• （1）Success：Container 通過(guò)了檢查。
• （2）Failure：Container 未通過(guò)檢查。
• （3）Unknown：未能執(zhí)行檢查，因此不采取任何措施。

Pod 重啟策略：

• （1）Always: 總是重啟
• （2）OnFailure: 如果失敗就重啟
• （3）Never: 永遠(yuǎn)不重啟

調(diào)度器

概述

• 一個(gè)容器平臺(tái)的主要功能就是為容器分配運(yùn)行時(shí)所需要的計(jì)算，存儲(chǔ)和網(wǎng)絡(luò)資源。容器調(diào)度系統(tǒng)負(fù)責(zé)選擇在最合適的主機(jī)上啟動(dòng)容器，并且將它們關(guān)聯(lián)起來(lái)。它必須能夠自動(dòng)的處理容器故障并且能夠在更多的主機(jī)上自動(dòng)啟動(dòng)更多的容器來(lái)應(yīng)對(duì)更多的應(yīng)用訪問(wèn)。目前三大主流的容器平臺(tái) Swarm, Mesos 和 Kubernetes 具有不同的容器調(diào)度系統(tǒng)。
  1. Swarm 的特點(diǎn)是直接調(diào)度 Docker 容器，并且提供和標(biāo)準(zhǔn) Docker API 一致的API。
  2. Mesos 針對(duì)不同的運(yùn)行框架采用相對(duì)獨(dú)立的調(diào)度系統(tǒng)，其中 Marathon 框架提供了Docker容器的原生支持。
  3. Kubernetes 則采用了 Pod 和 Label 這樣的概念把容器組合成一個(gè)個(gè)的互相存在依賴關(guān)系的邏輯單元。相關(guān)容器被組合成 Pod 后被共同部署和調(diào)度，形成服務(wù)（Service）。這個(gè)是 Kubernetes 和 Swarm，Mesos 的主要區(qū)別。
• 相對(duì)來(lái)說(shuō)，Kubernetes 采用這樣的方式簡(jiǎn)化了集群范圍內(nèi)相關(guān)容器被共同調(diào)度管理的復(fù)雜性。換一種角度來(lái)看，Kubernetes 采用這種方式能夠相對(duì)容易的支持更強(qiáng)大，更復(fù)雜的容器調(diào)度算法。

k8s 調(diào)度工作方式

• Kubernetes 調(diào)度器作為集群的大腦，在如何提高集群的資源利用率、保證集群中服務(wù)的穩(wěn)定運(yùn)行中也會(huì)變得越來(lái)越重要

Kubernetes 的資源分為兩種屬性

1. 可壓縮資源（例如 CPU 循環(huán)，Disk I/O 帶寬）都是可以被限制和被回收的，對(duì)于一個(gè)Pod 來(lái)說(shuō)可以降低這些資源的使用量而不去殺掉 Pod。
2. 不可壓縮資源（例如內(nèi)存、硬盤(pán)空間）一般來(lái)說(shuō)不殺掉 Pod 就沒(méi)法回收。未來(lái)Kubernetes 會(huì)加入更多資源，如網(wǎng)絡(luò)帶寬，存儲(chǔ) IOPS 的支持。
3. k8s 調(diào)度器
   • （1）kube-scheduler 是 kubernetes 系統(tǒng)的核心組件之一，主要負(fù)責(zé)整個(gè)集群資源的調(diào)度功能，根據(jù)特定的調(diào)度算法和策略，將 Pod 調(diào)度到最優(yōu)的工作節(jié)點(diǎn)上面去，從而更加合理、更加充分的利用集群的資源，這也是選擇使用 kubernetes 一個(gè)非常重要的理由。如果一門新的技術(shù)不能幫助企業(yè)節(jié)約成本、提供效率，我相信是很難推進(jìn)的。
   • （2）調(diào)度流程：默認(rèn)情況下，kube-scheduler 提供的默認(rèn)調(diào)度器能夠滿足我們絕大多數(shù)的要求，之前接觸的示例也基本上用的默認(rèn)的策略，都可以保證我們的 Pod 可以被分配到資源充足的節(jié)點(diǎn)上運(yùn)行。但是在實(shí)際的線上項(xiàng)目中，可能我們自己會(huì)比 kubernetes 更加了解我們自己的應(yīng)用，比如我們希望一個(gè) Pod 只能運(yùn)行在特定的幾個(gè)節(jié)點(diǎn)上，或者這幾個(gè)節(jié)點(diǎn)只能用來(lái)運(yùn)行特定類型的應(yīng)用，這就需要我們的調(diào)度器能夠可控。
   • kube-scheduler 是 kubernetes 的調(diào)度器，它的主要作用就是根據(jù)特定的調(diào)度算法和調(diào)度策略將 Pod 調(diào)度到合適的 Node 節(jié)點(diǎn)上去，是一個(gè)獨(dú)立的二進(jìn)制程序，啟動(dòng)之后會(huì)一直監(jiān)聽(tīng) API Server，獲取到 PodSpec.NodeName 為空的 Pod，對(duì)每個(gè) Pod 都會(huì)創(chuàng)建一個(gè)binding。

調(diào)度主要分為以下幾個(gè)部分：

• 首先是預(yù)選過(guò)程，過(guò)濾掉不滿足條件的節(jié)點(diǎn)，這個(gè)過(guò)程稱為 Predicates
• 然后是優(yōu)選過(guò)程，對(duì)通過(guò)的節(jié)點(diǎn)按照優(yōu)先級(jí)排序，稱之為 Priorities
• 最后從中選擇優(yōu)先級(jí)最高的節(jié)點(diǎn)，如果中間任何一步驟有錯(cuò)誤，就直接返回錯(cuò)誤Predicates 階段首先遍歷全部節(jié)點(diǎn)，過(guò)濾掉不滿足條件的節(jié)點(diǎn)，屬于強(qiáng)制性規(guī)則，這一階段輸出的所有滿足要求的 Node 將被記錄并作為第二階段的輸入，如果所有的節(jié)點(diǎn)都不滿足條件，那么 Pod 將會(huì)一直處于 Pending 狀態(tài)，直到有節(jié)點(diǎn)滿足條件，在這期間調(diào)度器會(huì)不斷的重試。
• 所以我們?cè)诓渴饝?yīng)用的時(shí)候，如果發(fā)現(xiàn)有 Pod 一直處于 Pending 狀態(tài)，那么就是沒(méi)有滿足調(diào)度條件的節(jié)點(diǎn)，這個(gè)時(shí)候可以去檢查下節(jié)點(diǎn)資源是否可用。
• Priorities 階段即再次對(duì)節(jié)點(diǎn)進(jìn)行篩選，如果有多個(gè)節(jié)點(diǎn)都滿足條件的話，那么系統(tǒng)會(huì)按照節(jié)點(diǎn)的優(yōu)先級(jí)(priorites)大小對(duì)節(jié)點(diǎn)進(jìn)行排序，最后選擇優(yōu)先級(jí)最高的節(jié)點(diǎn)來(lái)部署Pod應(yīng)用。

集群安全機(jī)制 RBAC

基本概念

• RBAC(Role-Based Access Control，基于角色的訪問(wèn)控制)在 k8s v1.5 中引入，在v1.6 版本時(shí)升級(jí)為 Beta 版本，并成為 kubeadm 安裝方式下的默認(rèn)選項(xiàng)，相對(duì)于其他訪問(wèn)控制方式，新的 RBAC 具有如下優(yōu)勢(shì)：
  • （1）對(duì)集群中的資源和非資源權(quán)限均有完整的覆蓋
  • （2）整個(gè) RBAC 完全由幾個(gè) API 對(duì)象完成，同其他 API 對(duì)象一樣，可以用kubectl 或API進(jìn)行操作
  • （3）可以在運(yùn)行時(shí)進(jìn)行調(diào)整，無(wú)需重啟 API Server
• 要使用 RBAC 授權(quán)模式，需要在 API Server 的啟動(dòng)參數(shù)中加上--authorization-mode=RBAC

k8s kubectl

kubectl 是 Kubernetes 集群的命令行工具，通過(guò) kubectl 能夠?qū)罕旧磉M(jìn)行管理，并能夠在集群上進(jìn)行容器化應(yīng)用的安裝部署。

查看各個(gè)組件的簡(jiǎn)寫(xiě)

kubectl api-resources

查看所有node

kubectl get nodes

查看所有pod

kubectl get pods

kubectl create 生成yaml

kubectl create deployment web --image=nginx -o yaml --dry-run > nginx.yaml

kubectl get 導(dǎo)出yaml

kubectl get deploy nginx -o=yaml --export > nginx.yaml

創(chuàng)建新的deployment

kubectl create -f nginx.yaml

創(chuàng)建一個(gè)service

kubectl create service nodeport nginx --tcp 80:80

另一種方式創(chuàng)建service

kubectl expose deployment nginx --type=NodePort

查看某一個(gè)service的詳情

kubectl describe services/nginx

查看所有service

kubectl get svc

刪除pod和svc

kubectl delete deployments/nginx services/nginx

在master節(jié)點(diǎn)上查看slave node的ip

kubectl get nodes -o wide

在master節(jié)點(diǎn)上,查看所有pods

kubectl get pods -o wide

實(shí)現(xiàn) Pod 的動(dòng)態(tài)縮放功能

kubectl scale rc nginx --replicas=5

containerd

查看版本

ctr -v

查看已經(jīng)存在的images

crictl images list

重啟containerd服務(wù)

systemctl restart containerd

crictl 去 pull 鏡像

crictl pull harbor.kingsd.top/ksd/ubuntu:16.04

kubernetes 部署項(xiàng)目

發(fā)布 Java 項(xiàng)目

4.png

你知道的越多，你不知道的越多。