Kubernet?

Kubernetes 架構(gòu)原則和對(duì)象設(shè)計(jì)?

什么是云計(jì)算?

云計(jì)算平臺(tái)的分類?

以O(shè)penstack為典型的虛擬化平臺(tái)

• 虛擬機(jī)構(gòu)建和業(yè)務(wù)代碼部署分離。
• 可變的基礎(chǔ)架構(gòu)使后續(xù)維護(hù)風(fēng)險(xiǎn)變大。

以谷歌borg為典型的基于進(jìn)程的作業(yè)調(diào)度平臺(tái)

• 技術(shù)的迭代引發(fā)borg的換代需求。
• 早期的隔離依靠chrootjail實(shí)現(xiàn)，一些不合理的設(shè)計(jì)需要在新產(chǎn)品中改進(jìn)。
  • 對(duì)象之間的強(qiáng)依賴job和task是強(qiáng)包含關(guān)系，不利于重組。
  • 所有容器共享IP，會(huì)導(dǎo)致端口沖突，隔離困難等問題。
  • 為超級(jí)用戶添加復(fù)雜邏輯導(dǎo)致系統(tǒng)過于復(fù)雜。

Kubernetes 架構(gòu)基礎(chǔ)?

Google Borg 簡(jiǎn)介?

特性

• 物理資源利用率高。
• 服務(wù)器共享，在進(jìn)程級(jí)別做隔離。
• 應(yīng)用高可用，故障恢復(fù)時(shí)間短。
• 調(diào)度策略靈活。
• 應(yīng)用接入和使用方便，提供了完備的Job描述語(yǔ)言，服務(wù)發(fā)現(xiàn)，實(shí)時(shí)狀態(tài)監(jiān)控和診斷工具。

優(yōu)勢(shì)

• 對(duì)外隱藏底層資源管理和調(diào)度、故障處理等。
• 實(shí)現(xiàn)應(yīng)用的高可靠和高可用。
• 足夠彈性，支持應(yīng)用跑在成千上萬(wàn)的機(jī)器上。

基本概念?

Workload

• prod：在線任務(wù)，長(zhǎng) 期運(yùn)行、對(duì)延時(shí)敏感、 面向終端用戶等，比如 Gmail, Google Docs, WebSearch服務(wù)等。
• non-prod ：離線任 務(wù)，也稱為批處理任務(wù) （Batch），比如一些 分布式計(jì)算服務(wù)等。

Cell

• 一個(gè) Cell 上跑一個(gè)集 群管理系統(tǒng)Borg。
• 通過定義 Cell 可以讓 Borg 對(duì)服務(wù)器資源進(jìn) 行統(tǒng)一抽象，作為用戶 就無(wú)需知道自己的應(yīng)用 跑在哪臺(tái)機(jī)器上，也不 用關(guān)心資源分配、程序 安裝、依賴管理、健康 檢查及故障恢復(fù)等。

Job和Task Naming

• 用戶以 Job 的形式提 交應(yīng)用部署請(qǐng)求。一個(gè) Job 包含一個(gè)或多個(gè)相 同的Task，每個(gè)Task 運(yùn)行相同的應(yīng)用程序， Task 數(shù)量就是應(yīng)用的 副本數(shù)。
• 每個(gè) Job 可以定義屬 性、元信息和優(yōu)先級(jí)， 優(yōu)先級(jí)涉及到搶占式調(diào) 度過程。
  • Borg 的服務(wù)發(fā)現(xiàn)通過 BNS （ Borg Name Service）來實(shí)現(xiàn)。
  • 50 .jfoo.ubar.cc.borg .google.com 可表示 在一個(gè)名為 cc 的 Cell 中由用戶 uBar 部署的 一個(gè)名為 jFoo 的 Job 下的第 50 個(gè)Task。

Borg 架構(gòu)?

Borgmaster主進(jìn)程：

• 處理客戶端RPC請(qǐng)求，比如創(chuàng)建Job，查詢Job等。
• 維護(hù)系統(tǒng)組件和服務(wù)的狀態(tài)，比如服務(wù)器、Task等。
• 負(fù)責(zé)與Borglet通信。

Scheduler進(jìn)程：

• 調(diào)度策略
  • WorstFit
  • BestFit
  • Hybrid
• 調(diào)度優(yōu)化
  • Scorecaching: 當(dāng)服務(wù)器或者任務(wù)的狀態(tài)未發(fā)生變更或者變更很少時(shí)，直接采用緩存數(shù)據(jù)，避免重復(fù)計(jì)算。
  • Equivalenceclasses:調(diào)度同一Job下多個(gè)相同的Task只需計(jì)算一次。
  • Relaxedrandomization:引入一些隨機(jī)性，即每次隨機(jī)選擇一些機(jī)器，只要符合需求的服務(wù)器數(shù)量達(dá)到一定值時(shí)，就可 以停止計(jì)算，無(wú)需每次對(duì)Cell中所有服務(wù)器進(jìn)行feasibilitychecking。

Borglet： Borglet是部署在所有服務(wù)器上的Agent，負(fù)責(zé)接收Borgmaster進(jìn)程的指令。

應(yīng)用高可用?

• 被搶占的non-prod任務(wù)放回pendingqueue，等待重新調(diào)度。
• 多副本應(yīng)用跨故障域部署。所謂故障域有大有小，比如相同機(jī)器、相同機(jī)架或相同電源插座等，一掛全掛。
• 對(duì)于類似服務(wù)器或操作系統(tǒng)升級(jí)的維護(hù)操作，避免大量服務(wù)器同時(shí)進(jìn)行。
• 支持冪等性，支持客戶端重復(fù)操作。
• 當(dāng)服務(wù)器狀態(tài)變?yōu)椴豢捎脮r(shí)，要控制重新調(diào)度任務(wù)的速率。因?yàn)锽org 無(wú)法區(qū)分是節(jié)點(diǎn)故障還是出現(xiàn)了短暫的 網(wǎng)絡(luò)分區(qū)，如果是后者，靜靜地等待網(wǎng)絡(luò)恢復(fù)更利于保障服務(wù)可用性。
• 當(dāng)某種“任務(wù) @ 服務(wù)器”的組合出現(xiàn)故障時(shí)，下次重新調(diào)度時(shí)需避免這種組合再次出現(xiàn)，因?yàn)闃O大可能會(huì)再 次出現(xiàn)相同故障。
• 記錄詳細(xì)的內(nèi)部信息，便于故障排查和分析。
• 保障應(yīng)用高可用的關(guān)鍵性設(shè)計(jì)原則：無(wú)論何種原因，即使 Borgmaster 或者 Borglet 掛掉、失聯(lián)，都不能殺 掉正在運(yùn)行的服務(wù)（Task）。

Borg 系統(tǒng)自身高可用?

• Borgmaster組件多副本設(shè)計(jì)。
• 采用一些簡(jiǎn)單的和底層（low-level）的工具來部署B(yǎng)org系統(tǒng)實(shí)例，避免引入過多的外部依賴。
• 每個(gè)Cell的Borg均獨(dú)立部署，避免不同Borg系統(tǒng)相互影響。

資源利用率?

• 通過將在線任務(wù)（prod）和離線任務(wù)（non-prod，Batch）混合部署，空閑時(shí)，離線任務(wù)可以充分利用計(jì) 算資源；繁忙時(shí)，在線任務(wù)通過搶占的方式保證優(yōu)先得到執(zhí)行，合理地利用資源。
• 98 %的服務(wù)器實(shí)現(xiàn)了混部。
• 90 %的服務(wù)器中跑了超過 25 個(gè)Task和 4500 個(gè)線程。
• 在一個(gè)中等規(guī)模的 Cell 里，在線任務(wù)和離線任務(wù)獨(dú)立部署比混合部署所需的服務(wù)器數(shù)量多出約 20 %- 30 %。 可以簡(jiǎn)單算一筆賬，Google 的服務(wù)器數(shù)量在千萬(wàn)級(jí)別，按 20 % 算也是百萬(wàn)級(jí)別，大概能省下的服務(wù)器采 購(gòu)費(fèi)用就是百億級(jí)別了，這還不包括省下的機(jī)房等基礎(chǔ)設(shè)施和電費(fèi)等費(fèi)用。

Brog 調(diào)度原理?

隔離性?

安全性隔離：

• 早期采用Chrootjail，后期版本基于Namespace。 性能隔離：
• 采用基于Cgroup的容器技術(shù)實(shí)現(xiàn)。
• 在線任務(wù)（prod）是延時(shí)敏感（latency-sensitive）型的，優(yōu)先級(jí)高，而離線任務(wù)（non-prod， Batch）優(yōu)先級(jí)低。
• Borg通過不同優(yōu)先級(jí)之間的搶占式調(diào)度來優(yōu)先保障在線任務(wù)的性能，犧牲離線任務(wù)。
• Borg將資源類型分成兩類：
• 可壓榨的（compressible），CPU是可壓榨資源，資源耗盡不會(huì)終止進(jìn)程；
• 不可壓榨的（non-compressible），內(nèi)存是不可壓榨資源，資源耗盡進(jìn)程會(huì)被終止。

什么是 Kubernetes（K8s）?

Kubernetes是谷歌開源的容器集群管理系統(tǒng)，是Google多年大規(guī)模容器管理技術(shù)Borg的開源版本，主要功能包括：

• 基于容器的應(yīng)用部署、維護(hù)和滾動(dòng)升級(jí)；
• 負(fù)載均衡和服務(wù)發(fā)現(xiàn)；
• 跨機(jī)器和跨地區(qū)的集群調(diào)度；
• 自動(dòng)伸縮；
• 無(wú)狀態(tài)服務(wù)和有狀態(tài)服務(wù)；
• 插件機(jī)制保證擴(kuò)展性。

命令式（ Imperative）vs 聲明式（ Declarative）?

命令式系統(tǒng)關(guān)注 “如何做”

• 在軟件工程領(lǐng)域，命令式系統(tǒng)是寫出解決某個(gè)問題、 完成某個(gè)任務(wù)或者達(dá)到某個(gè)目標(biāo)的明確步驟。此方法 明確寫出系統(tǒng)應(yīng)該執(zhí)行某指令，并且期待系統(tǒng)返回期 望結(jié)果。

聲明式系統(tǒng)關(guān)注“做什么”

• 在軟件工程領(lǐng)域，聲明式系統(tǒng)指程序代碼描述系統(tǒng)應(yīng)該 做什么而不是怎么做。僅限于描述要達(dá)到什么目的，如 何達(dá)到目的交給系統(tǒng)。

聲明式（Declaritive）系統(tǒng)規(guī)范?

命令式：

• 我要你做什么，怎么做，請(qǐng)嚴(yán)格按照我說的做。

聲明式：

• 我需要你幫我做點(diǎn)事，但是我只告訴你我需要你做什么，不是你應(yīng)該怎么做。
• 直接聲明：我直接告訴你我需要什么。
• 間接聲明：我不直接告訴你我的需求，我會(huì)把我的需求放在特定的地方，請(qǐng)?jiān)诜奖愕臅r(shí)候拿出來處理。

冪等性：

• 狀態(tài)固定，每次我要你做事，請(qǐng)給我返回相同結(jié)果。

面向?qū)ο蟮模?/p>

• 把一切抽象成對(duì)象。

Kubernetes：聲明式系統(tǒng)?

Kubernetes的所有管理能力構(gòu)建在對(duì)象抽象的基礎(chǔ)上，核心對(duì)象包括：

• Node：計(jì)算節(jié)點(diǎn)的抽象，用來描述計(jì)算節(jié)點(diǎn)的資源抽象、健康狀態(tài)等。
• Namespace：資源隔離的基本單位，可以簡(jiǎn)單理解為文件系統(tǒng)中的目錄結(jié)構(gòu)。
• Pod：用來描述應(yīng)用實(shí)例，包括鏡像地址、資源需求等。 Kubernetes 中最核心 的對(duì)象，也是打通應(yīng)用和基礎(chǔ)架構(gòu)的秘密武器。
• Service：服務(wù)如何將應(yīng)用發(fā)布成服務(wù)，本質(zhì)上是負(fù)載均衡和域名服務(wù)的聲明。

Kubernetes 采用與 Borg 類似的架構(gòu)?

主要組件?

Kubernetes 的主節(jié)點(diǎn)（Master Node）?

API服務(wù)器API Server:

• 這是Kubernetes控制面板中唯一帶有用戶可訪問API以及用戶可交互的組件。API服 務(wù)器會(huì)暴露一個(gè)RESTful的Kubernetes API并使用JSON格式的清單文件（manifest files）。

群的數(shù)據(jù)存儲(chǔ)Cluster Data Store:

• Kubernetes 使用“etcd”。這是一個(gè)強(qiáng)大的、穩(wěn)定的、高可用的鍵值存儲(chǔ)，被 Kubernetes用于長(zhǎng)久儲(chǔ)存所有的API對(duì)象。

控制管理器ControllerManager:

• 被稱為“kube-controller manager”，它運(yùn)行著所有處理集群日常任務(wù)的控制器。包 括了節(jié)點(diǎn)控制器、副本控制器、端點(diǎn)（endpoint）控制器以及服務(wù)賬戶等。

調(diào)度器Scheduler:

• 調(diào)度器會(huì)監(jiān)控新建的pods（一組或一個(gè)容器）并將其分配給節(jié)點(diǎn)。

Kubernetes 的工作節(jié)點(diǎn)（Worker Node）?

Kubelet:

• 負(fù)責(zé)調(diào)度到對(duì)應(yīng)節(jié)點(diǎn)的Pod 的生命周期管理，執(zhí)行任務(wù)并將Pod狀態(tài)報(bào)告給主節(jié) 點(diǎn)的渠道，通過容器運(yùn)行時(shí)（拉取鏡像、啟動(dòng)和停止容器等）來運(yùn)行這些容器。它 還會(huì)定期執(zhí)行被請(qǐng)求的容器的健康探測(cè)程序。

Kube-proxy:

• 它負(fù)責(zé)節(jié)點(diǎn)的網(wǎng)絡(luò)，在主機(jī)上維護(hù)網(wǎng)絡(luò)規(guī)則并執(zhí)行連接轉(zhuǎn)發(fā)。它還負(fù)責(zé)對(duì)正在服務(wù) 的pods進(jìn)行負(fù)載平衡。

etcd?

etcd 是 CoreOS 基于 Raft 開發(fā)的分布式 key-value 存儲(chǔ)，可用于服務(wù)發(fā)現(xiàn)、共享配置以及一致性保障（如 數(shù)據(jù)庫(kù)選主、分布式鎖等）。

• 基本的key-value存儲(chǔ)；
• 監(jiān)聽機(jī)制；
• key的過期及續(xù)約機(jī)制，用于監(jiān)控和服務(wù)發(fā)現(xiàn)；
• 原子CAS和CAD，用于分布式鎖和leader選舉。

直接訪問 etcd 的數(shù)據(jù):

• 通過etcd進(jìn)程查看啟動(dòng)參數(shù)
• 進(jìn)入容器
  • ps-ef|grepetcd
  • sh: ps: command not found
• 怎么辦？到主機(jī)Namespace查看cert信息
• 進(jìn)入容器查詢數(shù)據(jù)

export ETCDCTL_API=3

etcdctl--endpoints https://localhost:2379 --cert /etc/kubernetes/pki/etcd/server.crt--key
/etc/kubernetes/pki/etcd/server.key--cacert/etc/kubernetes/pki/etcd/ca.crtget --keys-only --prefix /

• 監(jiān)聽對(duì)象變化

etcdctl--endpoints https://localhost:2379 --cert /etc/kubernetes/pki/etcd/server.crt--key
/etc/kubernetes/pki/etcd/server.key--cacert/etc/kubernetes/pki/etcd/ca.crtwatch --prefix
/registry/services/specs/default/mynginx

APIServer?

Kube-APIServer是Kubernetes最重要的核心組件之一，主要提供以下功能：

• 提供集群管理的RESTAPI接口，包括:
  • 認(rèn)證Authentication；
  • 授權(quán)Authorization；
  • 準(zhǔn)入Admission（Mutating&Valiating）。
• 提供其他模塊之間的數(shù)據(jù)交互和通信的樞紐（其他模塊通過APIServer查詢或 修改數(shù)據(jù)，只有APIServer才直接操作etcd）。
• APIServer提供etcd數(shù)據(jù)緩存以減少集群對(duì)etcd的訪問。

APISERVER 展開?

Controller Manager?

• ControllerManager是集群的大腦，是確保整個(gè)集群動(dòng)起來的關(guān)鍵；
• 作用是確保 Kubernetes遵循聲明式系統(tǒng)規(guī)范，確保系統(tǒng)的真實(shí)狀態(tài)（Actual State）與用戶定義的期望狀態(tài)（DesiredState）一致；
• Controller Manager是多個(gè)控制器的組合，每個(gè)Controller 事實(shí)上都是一個(gè) controlloop，負(fù)責(zé)偵聽其管控的對(duì)象，當(dāng)對(duì)象發(fā)生變更時(shí)完成配置；
• Controller 配置失敗通常會(huì)觸發(fā)自動(dòng)重試，整個(gè)集群會(huì)在控制器不斷重試的機(jī) 制下確保最終一致性（EventualConsistency）。

控制器的工作流程?

INFORMER 的內(nèi)部機(jī)制?

控制器的協(xié)同工作原理?

Scheduler?

特殊的Controller，工作原理與其他控制器無(wú)差別。

Scheduler 的特殊職責(zé)在于監(jiān)控當(dāng)前集群所有未調(diào)度的 Pod，并且獲取當(dāng)前集群所有節(jié)點(diǎn)的健康狀況和資源 使用情況，為待調(diào)度Pod選擇最佳計(jì)算節(jié)點(diǎn)，完成調(diào)度。

調(diào)度階段分為：

• Predict：過濾不能滿足業(yè)務(wù)需求的節(jié)點(diǎn)，如資源不足、端口沖突等。
• Priority：按既定要素將滿足調(diào)度需求的節(jié)點(diǎn)評(píng)分，選擇最佳節(jié)點(diǎn)。
• Bind：將計(jì)算節(jié)點(diǎn)與Pod綁定，完成調(diào)度。

Kubelet?

Kubernetes的初始化系統(tǒng)（initsystem）

• 從不同源獲取Pod清單，并按需求啟停Pod的核心組件：
• Pod清單可從本地文件目錄，給定的HTTPServer或Kube-APIServer等源頭獲取；
• Kubelet將運(yùn)行時(shí)，網(wǎng)絡(luò)和存儲(chǔ)抽象成了CRI，CNI，CSI。
• 負(fù)責(zé)匯報(bào)當(dāng)前節(jié)點(diǎn)的資源信息和健康狀態(tài)；
• 負(fù)責(zé)Pod的健康檢查和狀態(tài)匯報(bào)。

Kube-Proxy?

• 監(jiān)控集群中用戶發(fā)布的服務(wù)，并完成負(fù)載均衡配置。
• 每個(gè)節(jié)點(diǎn)的 Kube-Proxy 都會(huì)配置相同的負(fù)載均衡策略，使得整個(gè)集群的服務(wù)發(fā)現(xiàn)建立在分布式負(fù)載均衡器之上，服務(wù)調(diào)用無(wú)需經(jīng)過額外的網(wǎng)絡(luò)跳轉(zhuǎn)（NetworkHop）。
• 負(fù)載均衡配置基于不同插件實(shí)現(xiàn)：
• userspace。
• 操作系統(tǒng)網(wǎng)絡(luò)協(xié)議棧不同的Hooks點(diǎn)和插件：
  • iptables；
  • ipvs。

推薦的 Add-ons?

• kube-dns：負(fù)責(zé)為整個(gè)集群提供DNS服務(wù)；
• IngressController：為服務(wù)提供外網(wǎng)入口；
• MetricsServer：提供資源監(jiān)控；
• Dashboard：提供GUI；
• Fluentd-Elasticsearch：提供集群日志采集、存儲(chǔ)與查詢。

了解 kubectl?

Kubectl 命令和 kubeconfig?

• kubectl是一個(gè)Kubernetes的命令行工具，它允許Kubernetes用戶以命令行的方式與Kubernetes交 互，其默認(rèn)讀取配置文件~/.kube/config。

• kubectl會(huì)將接收到的用戶請(qǐng)求轉(zhuǎn)化為rest調(diào)用以rest client的形式與apiserver通訊。

• apiserver的地址，用戶信息等配置在 kubeconfig。

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: REDACTED
    server: https://127.0.0.1:54729
name: kind-kind
contexts:
- context:
    cluster: kind-kind
    user: kind-kind
    name: kind-kind
current-context: kind-kind
kind: Config
users:
- name: kind-kind
user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED

kubectl 常用命令?

kubectl get po –oyaml -w

kubectl 可查看對(duì)象。

• oyaml 輸出詳細(xì)信息為yaml格式。
• wwatch 該對(duì)象的后續(xù)變化。
• owide 以詳細(xì)列表的格式查看對(duì)象。

Kubectl describe?

kubectldescribe展示資源的詳細(xì)信息和相關(guān)Event。

kubectldescribe po ubuntu-6fcf6c67db-xvmjh
....
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 8m13s default-scheduler Successfully assigned ubuntu-6fcf6c67db-xvmjh to k8smaster
Normal Pulling 7m56s kubelet, k8smaster pulling image "ubuntu:16.04"
Normal Pulled 7m50s kubelet, k8smaster Successfully pulled image "ubuntu:16.04"
Normal Created 7m50s kubelet, k8smaster Created container
Normal Started 7m50s kubelet, k8smaster Started container

kubectl exec?

kubectlexec提供進(jìn)入運(yùn)行容器的通道，可以進(jìn)入容器進(jìn)行debug操作。

# kubectlexec -it ubuntu-6fcf6c67db-xvmjh bash
root@ubuntu-6fcf6c67db-xvmjh:/# hostname -f
ubuntu-6fcf6c67db-xvmjh
root@ubuntu-6fcf6c67db-xvmjh:/#
...

kubectl logs?

Kubectllogs可查看pod的標(biāo)準(zhǔn)輸入（stdout, stderr），與tail用法類似。

**jianqli:~# kubectl logs ubuntu-6fcf6c67db-xvmjh
Mon Mar 25 14:56:02 UTC 2019
Mon Mar 25 14:56:05 UTC 2019
Mon Mar 25 14:56:08 UTC 2019
Mon Mar 25 14:56:11 UTC 2019
Mon Mar 25 14:56:14 UTC 2019
...**

?

深入理解 Kubernetes?

云計(jì)算的傳統(tǒng)分類?

Kubernetes 生態(tài)系統(tǒng)?

Kubernetes 設(shè)計(jì)理念?

可擴(kuò)展性:

• 基于CRD的擴(kuò)展
• 插件化的生態(tài)系統(tǒng)

可移植性:

• 可移植性
• 多種基礎(chǔ)架構(gòu)的選擇
• 多云和混合云

高可用:

• 基于 replicaset，statefulset 的應(yīng)用高可用
• Kubernetes 組件本身高可用

安全:

• 基于 TLS 提供服務(wù)
• Serviceaccount 和 user
• 基于 Namespace 的隔離
• secret
• Taints，psp， networkpolicy

Kubernetes Master?

分層架構(gòu)?

• 核心層：Kubernetes最核心的功能，對(duì)外提供API構(gòu)建高層的應(yīng)用，對(duì)內(nèi)提供插件式應(yīng)用執(zhí)行環(huán)境。
• 應(yīng)用層：部署（無(wú)狀態(tài)應(yīng)用、有狀態(tài)應(yīng)用、批處理任務(wù)、集群應(yīng)用等）和路由（服務(wù)發(fā)現(xiàn)、DNS 解析 等）。
• 管理層：系統(tǒng)度量（如基礎(chǔ)設(shè)施、容器和網(wǎng)絡(luò)的度量）、自動(dòng)化（如自動(dòng)擴(kuò)展、動(dòng)態(tài) Provision 等）、 策略管理（RBAC、Quota、PSP、NetworkPolicy等）。
• 接口層：Kubectl命令行工具、客戶端SDK以及集群聯(lián)邦。
• 生態(tài)系統(tǒng)：在接口層之上的龐大容器集群管理調(diào)度的生態(tài)系統(tǒng)，可以劃分為兩個(gè)范疇：
• Kubernetes 外部：日志、監(jiān)控、配置管理、CI、CD、Workflow、FaaS、OTS 應(yīng)用、 ChatOps等；
• Kubernetes內(nèi)部：CRI、CNI、CVI、鏡像倉(cāng)庫(kù)、CloudProvider、集群自身的配置和管理等。

API 設(shè)計(jì)原則?

• 所有API都應(yīng)是聲明式的
  • 相對(duì)于命令式操作，聲明式操作對(duì)于重復(fù)操作的效果是穩(wěn)定的，這對(duì)于容易出現(xiàn)數(shù)據(jù)丟失或重復(fù)的分布式環(huán)境來說是很重要的。
  • 聲明式操作更易被用戶使用，可以使系統(tǒng)向用戶隱藏實(shí)現(xiàn)的細(xì)節(jié)，同時(shí)也保留了系統(tǒng)未來持續(xù)優(yōu)化的可能性。
  • 此外，聲明式的API還隱含了所有的API對(duì)象都是名詞性質(zhì)的，例如Service、Volume這些API都是名詞，這些名詞描述了用戶所 期望得到的一個(gè)目標(biāo)對(duì)象。
• API對(duì)象是彼此互補(bǔ)而且可組合的
  • 這實(shí)際上鼓勵(lì)A(yù)PI對(duì)象盡量實(shí)現(xiàn)面向?qū)ο笤O(shè)計(jì)時(shí)的要求，即“高內(nèi)聚，松耦合”，對(duì)業(yè)務(wù)相關(guān)的概念有一個(gè)合適的分解，提高分解出 來的對(duì)象的可重用性。

• 高層API以操作意圖為基礎(chǔ)設(shè)計(jì)

  • 如何能夠設(shè)計(jì)好 API，跟如何能用面向?qū)ο蟮姆椒ㄔO(shè)計(jì)好應(yīng)用系統(tǒng)有相通的地方，高層設(shè)計(jì)一定是從業(yè)務(wù)出發(fā)，而不是過早的從技術(shù) 實(shí)現(xiàn)出發(fā)。
  • 因此，針對(duì)Kubernetes的高層API設(shè)計(jì)，一定是以Kubernetes的業(yè)務(wù)為基礎(chǔ)出發(fā)，也就是以系統(tǒng)調(diào)度管理容器的操作意圖為基礎(chǔ) 設(shè)計(jì)。

• 低層 API根據(jù)高層API的控制需要設(shè)計(jì)

  • 設(shè)計(jì)實(shí)現(xiàn)低層 API 的目的，是為了被高層API 使用，考慮減少冗余、提高重用性的目的，低層API 的設(shè)計(jì)也要以需求為基礎(chǔ)，要盡量抵抗受技術(shù)實(shí)現(xiàn)影響的誘惑。

• 盡量避免簡(jiǎn)單封裝，不要有在外部API無(wú)法顯式知道的內(nèi)部隱藏的機(jī)制

  • 簡(jiǎn)單的封裝，實(shí)際沒有提供新的功能，反而增加了對(duì)所封裝API的依賴性。
  • 例如 StatefulSet 和 ReplicaSet，本來就是兩種Pod 集合，那么Kubernetes就用不同 API 對(duì)象 來定義它們，而不會(huì)說只用同一個(gè) ReplicaSet，內(nèi)部通過特殊的算法再來區(qū)分這個(gè) ReplicaSet 是 有狀態(tài)的還是無(wú)狀態(tài)。

• API操作復(fù)雜度與對(duì)象數(shù)量成正比

  • API的操作復(fù)雜度不能超過O(N)，否則系統(tǒng)就不具備水平伸縮性了。
• API對(duì)象狀態(tài)不能依賴于網(wǎng)絡(luò)連接狀態(tài)
  • 由于眾所周知，在分布式環(huán)境下，網(wǎng)絡(luò)連接斷開是經(jīng)常發(fā)生的事情，因此要保證API對(duì)象狀態(tài)能應(yīng) 對(duì)網(wǎng)絡(luò)的不穩(wěn)定，API對(duì)象的狀態(tài)就不能依賴于網(wǎng)絡(luò)連接狀態(tài)。
• 盡量避免讓操作機(jī)制依賴于全局狀態(tài)
  • 因?yàn)樵诜植际较到y(tǒng)中要保證全局狀態(tài)的同步是非常困難的。

Kubernetes 如何通過對(duì)象的組合完成業(yè)務(wù)描述?

架構(gòu)設(shè)計(jì)原則?

• 只有APIServer可以直接訪問etcd存儲(chǔ)，其他服務(wù)必須通過KubernetesAPI來訪問集群狀態(tài)；
• 單節(jié)點(diǎn)故障不應(yīng)該影響集群的狀態(tài)；
• 在沒有新請(qǐng)求的情況下，所有組件應(yīng)該在故障恢復(fù)后繼續(xù)執(zhí)行上次最后收到的請(qǐng)求比如網(wǎng)絡(luò)分區(qū)或服務(wù)重啟等）；
• 所有組件都應(yīng)該在內(nèi)存中保持所需要的狀態(tài)，APIServer將狀態(tài)寫入etcd存儲(chǔ)，而其他組件則通過APIServer更新并監(jiān)聽所有的變化；
• 優(yōu)先使用事件監(jiān)聽而不是輪詢。

引導(dǎo)（Bootstrapping）原則?

• Self-hosting是目標(biāo)。
• 減少依賴，特別是穩(wěn)態(tài)運(yùn)行的依賴。
• 通過分層的原則管理依賴。
• 循環(huán)依賴問題的原則：
  • 同時(shí)還接受其他方式的數(shù)據(jù)輸入（比如本地文件等），這樣在其他服務(wù)不可 用時(shí)還可以手動(dòng)配置引導(dǎo)服務(wù)；
  • 狀態(tài)應(yīng)該是可恢復(fù)或可重新發(fā)現(xiàn)的；
  • 支持簡(jiǎn)單的啟動(dòng)臨時(shí)實(shí)例來創(chuàng)建穩(wěn)態(tài)運(yùn)行所需要的狀態(tài)，使用分布式鎖或文 件鎖等來協(xié)調(diào)不同狀態(tài)的切換（通常稱為pivoting技術(shù)）；
  • 自動(dòng)重啟異常退出的服務(wù)，比如副本或者進(jìn)程管理器等。

核心技術(shù)概念和 API 對(duì)象?

API對(duì)象是Kubernetes集群中的管理操作單元。

Kubernetes集群系統(tǒng)每支持一項(xiàng)新功能，引入一項(xiàng)新技術(shù)，一定會(huì)新引入對(duì)應(yīng)的API對(duì)象，支持對(duì)該功能的管理操 作。

每個(gè)API對(duì)象都有四大類屬性：

• TypeMeta
• MetaData
• Spec
• Status

TypeMeta?

Kubernetes對(duì)象的最基本定義，它通過引入GKV（Group，Kind，Version）模型定義了一個(gè)對(duì)象的類型。

1.Group：

• Kubernetes定義了非常多的對(duì)象，如何將這些對(duì)象進(jìn)行歸類是一門學(xué)問，將對(duì)象依據(jù)其功能范圍歸入不同的分組， 比如把支撐最基本功能的對(duì)象歸入core組，把與應(yīng)用部署有關(guān)的對(duì)象歸入apps組，會(huì)使這些對(duì)象的可維護(hù)性和可 理解性更高。

2.Kind：

• 定義一個(gè)對(duì)象的基本類型，比如Node、Pod、Deployment等。

3.Version：

• 社區(qū)每個(gè)季度會(huì)推出一個(gè)Kubernetes版本，隨著Kubernetes版本的演進(jìn)，對(duì)象從創(chuàng)建之初到能夠完全生產(chǎn)化就 緒的版本是不斷變化的。與軟件版本類似，通常社區(qū)提出一個(gè)模型定義以后，隨著該對(duì)象不斷成熟，其版本可能會(huì) 從v1alpha1到v1alpha2，或者到v1beta1，最終變成生產(chǎn)就緒版本v1。

Metadata?

Metadata中有兩個(gè)最重要的屬性：Namespace和Name，分別定義了對(duì)象的 Namespace歸屬及名字，這兩個(gè)屬性唯一定義了某個(gè)對(duì)象實(shí)例。

Label： 顧名思義就是給對(duì)象打標(biāo)簽，一個(gè)對(duì)象可以有任意對(duì)標(biāo)簽，其存在形式是鍵值對(duì)。 Label定義了對(duì)象的可識(shí)別屬性，Kubernetes API支持以Label作為過濾條件 查詢對(duì)象。

• Label是識(shí)別Kubernetes對(duì)象的標(biāo)簽，以key/value的方式附加到對(duì)象上。
• key最長(zhǎng)不能超過 63 字節(jié)，value可以為空，也可以是不超過 253 字節(jié)的字符串。
• Label不提供唯一性，并且實(shí)際上經(jīng)常是很多對(duì)象（如Pods）都使用相同的label來標(biāo)志具 體的應(yīng)用。
• Label定義好后其他對(duì)象可以使用Label Selector來選擇一組相同label的對(duì)象
• Label Selector支持以下幾種方式：
  • 等式，如app=nginx和env!=production；
  • 集合，如env in (production, qa)；
  • 多個(gè)label（它們之間是AND關(guān)系），如app=nginx,env=test。

Annotation：

Annotation與Label一樣用鍵值對(duì)來定義，但Annotation是作為屬性擴(kuò)展， 更多面向于系統(tǒng)管理員和開發(fā)人員，因此需要像其他屬性一樣做合理歸類。

• Annotations是key/value形式附加于對(duì)象的注解。
• 不同于 Labels 用于標(biāo)志和選擇對(duì)象，Annotations 則是用來記錄一些附加信息，用來輔助應(yīng)用部署、安 全策略以及調(diào)度策略等。
• 比如deployment使用annotations來記錄rollingupdate的狀態(tài)。

Finalizer：

• Finalizer本質(zhì)上是一個(gè)資源鎖，Kubernetes在接收某對(duì)象的刪除請(qǐng)求時(shí)，會(huì)檢 查Finalizer是否為空，如果不為空則只對(duì)其做邏輯刪除，即只會(huì)更新對(duì)象中的 metadata.deletionTimestamp字段。

ResourceVersion：

• ResourceVersion可以被看作一種樂觀鎖，每個(gè)對(duì)象在任意時(shí)刻都有其 ResourceVersion，當(dāng)Kubernetes對(duì)象被客戶端讀取以后，ResourceVersion 信息也被一并讀取。此機(jī)制確保了分布式系統(tǒng)中任意多線程能夠無(wú)鎖并發(fā)訪問對(duì) 象，極大提升了系統(tǒng)的整體效率。

Spec 和 Status?

• Spec和Status才是對(duì)象的核心。
• Spec是用戶的期望狀態(tài)，由創(chuàng)建對(duì)象的用戶端來定義。
• Status是對(duì)象的實(shí)際狀態(tài)，由對(duì)應(yīng)的控制器收集實(shí)際狀態(tài)并更新。
• 與TypeMeta和Metadata等通用屬性不同，Spec和Status是每個(gè)對(duì)象獨(dú)有的。

常用 Kubernetes 對(duì)象及其分組?

核心對(duì)象概覽?

Node?

• Node是Pod真正運(yùn)行的主機(jī)，可以物理機(jī)，也可以是虛擬機(jī)。
• 為了管理Pod，每個(gè)Node節(jié)點(diǎn)上至少要運(yùn)行container runtime

（比如Docker或者Rkt）、Kubelet和Kube-proxy服務(wù)。

Namespace?

Namespace是對(duì)一組資源和對(duì)象的抽象集合，比如可以用來將系統(tǒng)內(nèi)部的對(duì) 象劃分為不同的項(xiàng)目組或用戶組。

常見的pods, services, replication controllers和deployments等都是屬于 某一個(gè)Namespace的（默認(rèn)是default），而Node, persistentVolumes 等則不屬于任何Namespace。

什么是 Pod?

• Pod是一組緊密關(guān)聯(lián)的容器集合，它們共享PID、IPC、Network和UTS namespace，是Kubernetes 調(diào)度的基本單位。
• Pod的設(shè)計(jì)理念是支持多個(gè)容器在一個(gè)Pod中共享網(wǎng)絡(luò)和文件系統(tǒng)，可以通過進(jìn)程間通信和文件共享這 種簡(jiǎn)單高效的方式組合完成服務(wù)。
• 同一個(gè)Pod中的不同容器可共享資源：
  • 共享網(wǎng)絡(luò)Namespace；
  • 可通過掛載存儲(chǔ)卷共享存儲(chǔ)；
  • 共享SecurityContext。

如何通過 Pod 對(duì)象定義支撐應(yīng)用運(yùn)行?

• 環(huán)境變量：
  • 直接設(shè)置值；
  • 讀取PodSpec的某些屬性；
  • 從ConfigMap讀取某個(gè)值；
  • 從Secret讀取某個(gè)值。

存儲(chǔ)卷?

• 通過存儲(chǔ)卷可以將外掛存儲(chǔ)掛載到Pod內(nèi)部使用。
• 存儲(chǔ)卷定義包括兩個(gè)部分: Volume和VolumeMounts。
  • Volume：定義Pod可以使用的存儲(chǔ)卷來源；
  • VolumeMounts：定義存儲(chǔ)卷如何Mount到容器內(nèi)部。

Pod 網(wǎng)絡(luò)?

Pod的多個(gè)容器是共享網(wǎng)絡(luò)Namespace的，這意味著：

• 同一個(gè)Pod中的不同容器可以彼此通過Loopback地址訪問：
  • 在第一個(gè)容器中起了一個(gè)服務(wù)http://127.0.0.1。
  • 在第二個(gè)容器內(nèi)，是可以通過httpGethttp://172.0.0.1訪問到該地址的。
• 這種方法常用于不同容器的互相協(xié)作。

資源限制?

Kubernetes通過Cgroups提供容器資源管理的功能，可以限制每個(gè)容器的 CPU和內(nèi)存使用，比如對(duì)于剛才創(chuàng)建的deployment，可以通過下面的命令限制 nginx容器最多只用50%的CPU和128MB的內(nèi)存：

$ kubectl set resources deployment nginx-app -c=nginx--
limits=cpu=500m,memory=128Mi

deployment "nginx" resource requirements updated

等同于在每個(gè) Pod 中設(shè)置 resources limits

apiVersion:v 1
kind:Pod
metadata:
    labels:
    app:nginx
    name:nginx
spec:
containers:
- image:nginx
    name:nginx
    resources:
       limits:
          cpu:" 500 m"
          memory:" 128 Mi"

健康檢查?

Kubernetes作為一個(gè)面向應(yīng)用的集群管理工具，需要確保容器在部署后確實(shí)處在正常的運(yùn)行狀態(tài)。

1.探針類型：

• LivenessProbe
  • 探測(cè)應(yīng)用是否處于健康狀態(tài)，如果不健康則刪除并重新創(chuàng)建容器。
• ReadinessProbe
  • 探測(cè)應(yīng)用是否就緒并且處于正常服務(wù)狀態(tài)，如果不正常則不會(huì)接收來自Kubernetes Service 的流量。
• StartupProbe
  • 探測(cè)應(yīng)用是否啟動(dòng)完成，如果在failureThreshold*periodSeconds周期內(nèi)未就緒，則會(huì)應(yīng)用進(jìn)程會(huì)被重啟。

2.探活方式：

• Exec
• TCP socket
• HTTP

健康檢查 spec

apiVersion:extensions/v 1 beta 1
kind:Deployment
metadata:
labels:
app:nginx
name:nginx-default
spec:
replicas: 3
selector:
matchLabels:
app:nginx
template:
metadata:
labels:
app:nginx

spec:
containers:
- image:nginx
    imagePullPolicy:Always
    name:http
    resources:{}
    terminationMessagePath:
/dev/termination-log
terminationMessagePolicy:File
resources:
limits:
cpu:" 500 m"
memory:" 128 Mi"

``` yaml
livenessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 15
timeoutSeconds: 1
readinessProbe:
httpGet:
path: /ping
port: 80
initialDelaySeconds: 5
timeoutSeconds: 1

ConfigMap?

• ConfigMap用來將非機(jī)密性的數(shù)據(jù)保存到鍵值對(duì)中。
• 使用時(shí)，Pods可以將其用作環(huán)境變量、命令行參數(shù)或者存儲(chǔ)卷中的配置文件。
• ConfigMap將環(huán)境配置信息和容器鏡像解耦，便于應(yīng)用配置的修改。

密鑰對(duì)象（Secret）?

• Secret是用來保存和傳遞密碼、密鑰、認(rèn)證憑證這些敏感信息的對(duì)象。
• 使用Secret的好處是可以避免把敏感信息明文寫在配置文件里。
• Kubernetes集群中配置和使用服務(wù)不可避免的要用到各種敏感信息實(shí)現(xiàn)登錄、認(rèn) 證等功能，例如訪問AWS存儲(chǔ)的用戶名密碼。
• 為了避免將類似的敏感信息明文寫在所有需要使用的配置文件中，可以將這些信息 存入一個(gè)Secret對(duì)象，而在配置文件中通過Secret對(duì)象引用這些敏感信息。
• 這種方式的好處包括：意圖明確，避免重復(fù)，減少暴漏機(jī)會(huì)。

用戶（User Account）& 服務(wù)帳戶（Service Account）?

• 顧名思義，用戶帳戶為人提供賬戶標(biāo)識(shí)，而服務(wù)賬戶為計(jì)算機(jī)進(jìn)程和Kubernetes集群中運(yùn)行的Pod提供 賬戶標(biāo)識(shí)。
• 用戶帳戶和服務(wù)帳戶的一個(gè)區(qū)別是作用范圍：
  • 用戶帳戶對(duì)應(yīng)的是人的身份，人的身份與服務(wù)的Namespace無(wú)關(guān)，所以用戶賬戶是跨 Namespace的；
  • 而服務(wù)帳戶對(duì)應(yīng)的是一個(gè)運(yùn)行中程序的身份，與特定Namespace是相關(guān)的。

Service?

Service是應(yīng)用服務(wù)的抽象，通過labels為應(yīng)用提供負(fù)載均衡和服務(wù)發(fā)現(xiàn)。匹 配labels的PodIP和端口列表組成endpoints，由Kube-proxy負(fù)責(zé)將服務(wù) IP負(fù)載均衡到這些endpoints上。

每個(gè) Service 都會(huì)自動(dòng)分配一個(gè) cluster IP（僅在集群內(nèi)部可訪問的虛擬地址） 和DNS名，其他容器可以通過該地址或DNS來訪問服務(wù)，而不需要了解后端 容器的運(yùn)行。文章來源地址http://www.zghlxwxcb.cn/news/detail-455201.html

Service Spec?

apiVersion: v1
kind: Service
metadata:
name: nginx
spec:
ports:
- port: 8078 # the port that this service should serve on
    name: http
    # the container on each pod to connect to, can be a name
    # (e.g. 'www') or a number (e.g. 80)
    targetPort: 80
    protocol: TCP
selector:
    app: nginx

副本集（Replica Set）?

• Pod只是單個(gè)應(yīng)用實(shí)例的抽象，要構(gòu)建高可用應(yīng)用，通常需要構(gòu)建多個(gè)同樣的副本，提供同一個(gè)服務(wù)。
• Kubernetes為此抽象出副本集ReplicaSet，其允許用戶定義Pod的副本數(shù)，每一個(gè)Pod都會(huì)被當(dāng)作一 個(gè)無(wú)狀態(tài)的成員進(jìn)行管理，Kubernetes保證總是有用戶期望的數(shù)量的Pod正常運(yùn)行。
• 當(dāng)某個(gè)副本宕機(jī)以后，控制器將會(huì)創(chuàng)建一個(gè)新的副本。
• 當(dāng)因業(yè)務(wù)負(fù)載發(fā)生變更而需要調(diào)整擴(kuò)縮容時(shí)，可以方便地調(diào)整副本數(shù)量。

部署（Deployment）?

• 部署表示用戶對(duì)Kubernetes集群的一次更新操作。
• 部署是一個(gè)比RS應(yīng)用模式更廣的API對(duì)象，可以是創(chuàng)建一個(gè)新的服務(wù)，更新一個(gè)新的服務(wù)，也可以是滾動(dòng)升級(jí)一個(gè)服務(wù)。
• 滾動(dòng)升級(jí)一個(gè)服務(wù)，實(shí)際是創(chuàng)建一個(gè)新的RS，然后逐漸將新RS中副本數(shù)增加到理想狀態(tài)，將舊RS中的副本數(shù)減小到 0 的 復(fù)合操作。
• 這樣一個(gè)復(fù)合操作用一個(gè)RS是不太好描述的，所以用一個(gè)更通用的Deployment來描述。
• 以Kubernetes的發(fā)展方向，未來對(duì)所有長(zhǎng)期伺服型的的業(yè)務(wù)的管理，都會(huì)通過Deployment來管理。

有狀態(tài)服務(wù)集（StatefulSet）?

• 對(duì)于StatefulSet中的Pod，每個(gè)Pod掛載自己獨(dú)立的存儲(chǔ)，如果一個(gè)Pod出現(xiàn)故障，從其他節(jié)點(diǎn)啟動(dòng)一個(gè)同樣名字的 Pod，要掛載上原來Pod的存儲(chǔ)繼續(xù)以它的狀態(tài)提供服務(wù)。
• 適合于StatefulSet的業(yè)務(wù)包括數(shù)據(jù)庫(kù)服務(wù)MySQL和PostgreSQL，集群化管理服務(wù)ZooKeeper、etcd等有狀態(tài)服務(wù)。
• 使用StatefulSet，Pod仍然可以通過漂移到不同節(jié)點(diǎn)提供高可用，而存儲(chǔ)也可以通過外掛的存儲(chǔ)來提供高可靠性， StatefulSet 做的只是將確定的Pod與確定的存儲(chǔ)關(guān)聯(lián)起來保證狀態(tài)的連續(xù)性。

Statefulset 與 Deployment 的差異?

• 身份標(biāo)識(shí)
  • StatefulSetController為每個(gè)Pod編號(hào)，序號(hào)從 0 開始。
• 數(shù)據(jù)存儲(chǔ)
  • StatefulSet允許用戶定義volumeClaimTemplates，Pod被創(chuàng)建的同時(shí)，Kubernetes會(huì)以 volumeClaimTemplates中定義的模板創(chuàng)建存儲(chǔ)卷，并掛載給Pod。
• StatefulSet的升級(jí)策略不同
  • onDelete
  • 滾動(dòng)升級(jí)
  • 分片升級(jí)

任務(wù)（Job）?

• Job是Kubernetes用來控制批處理型任務(wù)的API對(duì)象。
• Job管理的Pod根據(jù)用戶的設(shè)置把任務(wù)成功完成后就自動(dòng)退出。
• 成功完成的標(biāo)志根據(jù)不同的spec.completions策略而不同：
  • 單Pod型任務(wù)有一個(gè)Pod成功就標(biāo)志完成；
  • 定數(shù)成功型任務(wù)保證有N個(gè)任務(wù)全部成功；
  • 工作隊(duì)列型任務(wù)根據(jù)應(yīng)用確認(rèn)的全局成功而標(biāo)志成功。

后臺(tái)支撐服務(wù)集（DaemonSet）?

• 長(zhǎng)期伺服型和批處理型服務(wù)的核心在業(yè)務(wù)應(yīng)用，可能有些節(jié)點(diǎn)運(yùn)行多個(gè)同類業(yè)務(wù)的Pod，有些節(jié)點(diǎn)上又沒有這類Pod運(yùn)行；
• 而后臺(tái)支撐型服務(wù)的核心關(guān)注點(diǎn)在Kubernetes集群中的節(jié)點(diǎn)（物理機(jī)或虛擬機(jī)），要保證每個(gè)節(jié)點(diǎn)上都有一個(gè)此類Pod運(yùn)行。
• 節(jié)點(diǎn)可能是所有集群節(jié)點(diǎn)也可能是通過nodeSelector選定的一些特定節(jié)點(diǎn)。
• 典型的后臺(tái)支撐型服務(wù)包括存儲(chǔ)、日志和監(jiān)控等在每個(gè)節(jié)點(diǎn)上支撐Kubernetes集群運(yùn)行的服務(wù)。

存儲(chǔ) PV 和 PVC?

• PersistentVolume（PV）是集群中的一塊存儲(chǔ)卷，可以由管理員手動(dòng)設(shè)置， 或當(dāng)用戶創(chuàng)建PersistentVolumeClaim（PVC）時(shí)根據(jù)StorageClass動(dòng) 態(tài)設(shè)置。
• PV和PVC與Pod生命周期無(wú)關(guān)。也就是說，當(dāng)Pod中的容器重新啟動(dòng)、 Pod重新調(diào)度或者刪除時(shí)，PV和PVC不會(huì)受到影響，Pod存儲(chǔ)于PV里 的數(shù)據(jù)得以保留。
• 對(duì)于不同的使用場(chǎng)景，用戶通常需要不同屬性（例如性能、訪問模式等） 的PV。

CustomResourceDefinition?

• CRD就像數(shù)據(jù)庫(kù)的開放式表結(jié)構(gòu)，允許用戶自定義Schema。
• 有了這種開放式設(shè)計(jì)，用戶可以基于CRD定義一切需要的模型，滿足不同 業(yè)務(wù)的需求。
• 社區(qū)鼓勵(lì)基于CRD的業(yè)務(wù)抽象，眾多主流的擴(kuò)展應(yīng)用都是基于CRD構(gòu)建 的，比如Istio、Knative。
• 甚至基于CRD推出了Operator Mode和Operator SDK，可以以極低的 開發(fā)成本定義新對(duì)象，并構(gòu)建新對(duì)象的控制器。

到了這里，關(guān)于Kubernetes 架構(gòu)原則和對(duì)象設(shè)計(jì)的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！