前言：K8S 提供了豐富的認證和受權機制，能夠知足各類場景細粒度的訪問控制。本文會介紹 k8s 中的用戶認證、受權機制，並經過例子闡述 kubeconfig 的生成和原理，最後會列舉常見的證書問題，如過時、吊銷、租戶控制等。本文屬於科普 + 實踐，不涉及 apiserver 中代碼實現。node
兩種用戶mysql
k8s中的客戶端訪問有兩類用戶:nginx
普通用戶（Human User），通常是集羣外訪問，如 kubectl 使用的證書程序員
service account: 如集羣內的 Podweb
有什麼區別呢？面試
k8s 不會對 user 進行管理，並不存儲 user 信息，你也不能經過調用k8s api來增刪查這個 user。你能夠認爲這個 user 指的就是公司內的人員，通常須要對接內部權限系統，user 的增刪操做都是在 k8s 外部進行，k8s 只作認證不作管理。sql
k8s 會對serviceaccount 進行管理，他的做用是給集羣內運行的 pod 提供一種認證的方式，若是你這個 pod 想調用apiserver操做一些資源如獲取 node列表，就須要綁定一個serviceaccount帳戶給本身，併爲這個serviceaccount賦予必定的權限，這樣就作到了實體和權限的分離，也就是後面會提到的 rbac 受權。json
做用範圍：bootstrap
User獨立在 K8S 以外，也就是說User是能夠做用於全局的，跨 namespace，而且須要在全局惟一api
ServiceAccount是K8S的一種資源，是存在於某個namespace之中的，在不一樣namespace中能夠同名，表明了不一樣的資源。
舉例說明：
爲 user 生成 kubeconfig
一個同事張三都想要一份集羣的 kubeconfig 用來平常 kubectl 操做集羣，但限定只能操做名爲 test 的 namespace，公司有獨立的權限系統，他的用戶 ID 是惟一的，叫zhangsan。接下來手動爲這個用戶生成 kubeconfig
生成證書：
獲得：
zhangsan.pem
zhangsan-key.pem
接下來爲 zhangsan 受權，首先生成一份角色：test-role, 權限爲test 的命名空間下的全部資源的全部操做權限
而後將這個角色role綁定到zhangsan這個 user 上，表明 zhangsan 擁有了這個 role 的權限
爲張三生成專屬的 kubeconfig 文件，名爲zhangsan.conf
獲取 test 下全部的 pod
若是獲取其餘 namespace 下的pod，則報權限錯誤
爲 pod 建立 serviceaccount
以 metrics-server的 pod 爲例，須要對 pod、node、ns 等資源進行 get list操做，所以權限配置爲：
pod 的 yaml 配置中聲明serviceAccountName爲metrics-server
以上是 user用戶使用 kubeconfig、pod 使用 serviceaccount 的示例，pod 使用serviceaccount是比較好理解的，但其實 kubeconfig 也能夠直接用serviceaccount來生成，不必定非得用 user，只是大多數狀況下，kubeconfig 的管理是和用戶的聲明週期一致的，即子用戶能夠申領一份本身的 kubeconfig，管理員能夠隨時吊銷或者禁用子用戶 kubeconfig 的效力。這個在後面的」多租戶下的kubeconfig「中會提到。
三種機制
談 k8s 的認證和訪問控制，通常都會看到這張圖：
k8s 中全部的 api 請求都要經過一個 gateway 也就是 apiserver 組件來實現，是集羣惟一的訪問入口。既然是 gateway，最基礎的功能就是 api 的認證 + 鑑權了。對應了圖上的步驟1和2，而 k8s 中還提供了第 3 步的 admission Control（准入控制），能夠更方便地攔截、校驗資源請求。
三種機制：
一、認證：Authentication，即身份認證。檢查用戶是否爲合法用戶，如客戶端證書、密碼、bootstrap tookens和JWT tokens等方式。
二、鑑權：Authorization，即權限判斷。判斷該用戶是否具備該操做的權限，k8s 中支持 Node、RBAC（Role-Based Access Control）、ABAC、webhook等機制，RBAC 爲主流方式
三、准入控制：Admission Control。請求的最後一個步驟，通常用於拓展功能，如檢查 pod 的resource是否配置，yaml配置的安全是否合規等。通常使用admission webhooks來實現
1-2-3 所有經過後api 請求會被處理，在 k8s 中也就意味着資源變動能夠落庫到 etcd。
K8S 中的認證
上面提到 k8s 並不存儲 user，只知道一個 user 名稱，所以 user 在訪問api 時怎麼作的認證？
kubernetes 支持不少種認證機制，包括：
X509 client certs
Static Token File
Bootstrap Tokens
Static Password File
Service Account Tokens
OpenId Connect Tokens
Webhook Token Authentication
Authticating Proxy
Anonymous requests
User impersonation
Client-go credential plugins
前面提到的 user 生成 kubeconfig就是X509 client certs方式， 而 metric-server 就是Service Account Tokens方式。
X509 client certs
即客戶端證書認證，X509 是一種數字證書的格式標準，是 kubernetes 中默認開啓使用最多的一種，也是最安全的一種，api-server 啓動時會指定 ca 證書以及 ca 私鑰，只要是經過同一個 ca 簽發的客戶端 x509 證書，則認爲是可信的客戶端，kubeadm 安裝集羣時就是基於證書的認證方式。
客戶端證書認證叫做 TLS 雙向認證，也就是服務器、客戶端互相驗證證書的正確性，在都正確的狀況下協調通訊加密方案。apiserver 、controller-manager、scheduler、kubelet 等組件之間的交互，通常也是基於X509的客戶端認證方式，目前最經常使用的 X509 證書製做工具備 openssl、cfssl ，上面生成 kubeconfig 時用到就是 cfssl 工具簽發的證書。
仍是舉個例子，在手動部署 k8s 集羣時須要作的證書操做，若是你已經熟悉這個過程或者用了 kubeadm 等部署工具，能夠跳過這一段。
一、基礎證書生成
ca-config.json
建立用來生成 CA 文件的 JSON 配置文件，這個文件後面會被各類組件使用，包括了證書過時時間的配置，expiry字段
ca-csr.json
建立用來生成 CA 證書籤名請求（CSR）的 JSON 配置文件
生成基礎 ca 證書
建立自簽名 CA 證書：這裏只須要ca-csr.json文件，執行後會生成三個文件：
ca.csr：證書籤名請求，通常用於提供給證書頒發機構，自籤的就不須要了
ca.pem：證書，公共證書
ca-key.pem：CA密鑰
二、生成 apiserver 證書
apiserver-csr.json
hosts列表不只包含了三臺 master 機器的ip，還包括了 對應的負載均衡的 ip和外網 ip（若是有的話），以及 kubernetes 的 svc IP：172.18.0.1
這個 ip 是 svc ip range 中的第一個 ip，若是沒有這個 ip，集羣內的 pod 將沒法經過 serviceaccount 的形式訪問 apiserver 並鑑權，會報證書錯誤。
建立apiserver 的 CA 證書：這裏須要4 個文件
apiserver-csr.json：apiserver的證書配置
ca.pem：基礎公鑰
ca-key.pem：基礎私鑰
ca-config.json：配置文件，如過時時間
執行後會生成三個文件：
apiserver.csr
apiserver.pem
apiserver-key.pem
** 使用證書**
Service Account Tokens
也就是 service account 使用的認證方式。
你會發現x509的認證方式比較複雜，須要作不少證書，若是我在集羣中部署了一個 pod，好比一些 operator，想訪問apiserver獲取集羣的一些信息，甚至對集羣的資源進行改動，這種認證屬於 k8s 管理範疇，所以 k8s 定義了一種資源serviceaccounts來定義一個 pod 應該擁有什麼權限。
serviceaccounts 是面向 namespace 的，每一個 namespace 建立的時候，kubernetes 會自動在這個 namespace 下面建立一個默認的 serviceaccounts，而且這個 serviceaccounts 只能訪問該 namespace 的資源。serviceaccounts 和 pod、service、deployment 同樣是 kubernetes 集羣中的一種資源，用戶能夠建立本身的serviceaccounts。
service account 主要包含了三個內容：namespace、token 和 ca
namespace: 指定了 pod 所在的 namespace
token: token 用做身份驗證
ca: ca 用於驗證 apiserver 的證書
每一個 service account 都對應一個 secret，這三個信息就存放在這個 secret 裏，以 base64 編碼。service account 經過 mount 的方式保存在 pod 的文件系統中，其三者都是保存在 /var/run/secrets/kubernetes.io/serviceaccount/目錄下。
kubeconfig 的生成與含義
kubeconfig 是用來訪問 k8s 集羣的憑證，生成 kubeconfig 的步驟很簡單但參數不少，這裏以生成 admin 的 kubeconfig 爲例，解釋各參數的含義。
生成最高權限的 kubeconfig。
通常狀況下集羣建立以後，會先生成一份最高權限的 kubeconfig，即管理員角色，能夠操做集羣的全部資源，併爲其餘用戶建立或刪除權限，能夠稱之爲 admin 證書，生成方式是：
admin-csr.json
admin 證書
生成 admin.conf，即最高權限的 kubeconfig
集羣參數
本段設置了所須要訪問的集羣的信息。
使用 set-cluster 設置了須要訪問的集羣，如上爲 kubernetes 這只是個名稱，實際爲 –server 指向的 apiserver 所在的集羣。
–certificate-authority 設置了該集羣的公鑰
–embed-certs 爲 true 表示將 –certificate-authority 證書寫入到 kubeconfig 中
–server 則表示該集羣的 apiserver 地址
用戶參數
本段主要設置用戶的相關信息，主要是用戶證書。
用戶名: zhangsan
證書: /etc/kubernetes/ssl/zhangsan.pem
私鑰: /etc/kubernetes/ssl/zhangsan-key.pem
這一步操做是指客戶端的證書首先要通過集羣 CA 的簽署，不然不會被集羣承認，認證就失敗。
此處使用的是 客戶端 x509 認證方式，也可使用token認證，如kubelet的 TLS Boostrap機制下的bootstrapping 使用的就是 token 認證方式
上下文參數
集羣參數和用戶參數能夠同時設置多對，而上下文參數就是集羣參數和用戶參數關聯起來。
上面的上下文名稱爲 kubenetes，集羣爲 kubenetes(apiserver 地址對應的集羣)，用戶爲zhangsan，表示使用 zhangsan 的用戶憑證來訪問
kubenetes 集羣
最後使用 kubectl config use-context kubernetes 來使用名爲 kubenetes 的環境項來做爲配置。
若是配置了多個環境項，能夠經過切換不一樣的環境項名字來訪問到不一樣的集羣環境。
kubeconfig 的認證過程
正向生成 kubeconfig 咱們已經作完了，apiserver 認證請求時，如何解析 kubeconfig 文件的內容呢？
咱們能夠看下 kubeconfig 的內容：
除了 context，裏面有三個證書字段，都是 base64 編碼後的內容
certificate-authority-data: server 端的證書，用於驗證 apiserver 的合法性
client-certificate-data: 客戶端證書
client-key-data: 客戶端私鑰
能夠提取出來 certificate-authority-data 的內容放到一個文件cert.txt，而後base64解碼
ertificate-authority-data：
獲得的內容其實就是 ca.pem 即服務端證書，apiserver 的證書也是基於ca.pem簽發，由於 TLS 是雙向認證，apiserver 在認證 kubectl請求時，kubectl 也須要驗證 apiserver 的證書，防止中間人攻擊，驗證的字段就是certificate-authority-data
client-certificate：
由於 k8s 沒有 user 這種資源，所以在使用 kubeconfig 訪問時，身份信息就「隱藏」在client-certificate的數據中，咱們來查看一下。
將 kubeconfig 中的client-certificate-data的內容放在一個文件 client.txt 中，而後解碼：
查看證書內容：
輸出內容能夠看到Subject: organization=system:masters, common_name=kubernetes-admin
apiserver 驗證、解析請求，獲得 system:masters 的http上下文信息，並傳給後續的authorizers來作權限校驗。
O 和 CN 的含義
「O」：Organization, apiserver接到請求後從證書中提取該字段做爲請求用戶所屬的組 (Group)
「CN」：Common Name，apiserver從證書中提取該字段做爲請求的用戶名 (User Name)
在admin-csr.json中， admin使用了system:masters做爲組 (Group)
k8s 預約義了 RoleBinding:cluster-admin 將 Group system:masters 與 Role cluster-admin 綁定，該 Role 授予了調用 k8s 相關 API 的權限，權限極高。
即：
Group: system:masters
ClusterRole: cluster-admin
ClusterRoleBinding: cluster-admin
k8s 核心組件的默認權限
admin權限：system:masters組，clusterrole 和 rolebinding 都叫 cluster-admin
kubelet: system:nodes組，clusterrole 和 rolebinding 都叫system:nodes，下同
kube-proxy: system:kube-proxy組
scheduler: system:kube-scheduler組
controller-manager: system:kube-controller-manager組
對應關係如圖所示
即 k8s 全部自身組件使用的權限都是基於內置的 clusterrole，生成出來的 kubeconfig 被各組件進程使用，權限都是默認已有 role，若是但願本身建立 role ，就要使用 rbac 受權了
至此，咱們應該知道了kubeconfig 的生成流程、驗證方式，以及爲何採用了 admin.conf 做爲kubeconfig，kubectl就能擁有最高權限。下面是一幅示意圖
K8S 中的受權
不管是 user的x509認證 仍是 service account的 token認證，認證完後，都要到達第 2 步：受權，
K8S 目前支持了以下四種受權機制：
Node
ABAC
RBAC
Webhook
用的最多的就是 RBAC，即基於角色作權限控制。
Node
僅 v1.7 版本以上支持 Node 受權，配合 NodeRestriction 准入控制來限制 kubelet，使其僅可訪問 node、endpoint、pod、service 以及 secret、configmap、pv、pvc 等相關的資源，在 apiserver 中使用如下配置來開啓
node 的鑑權機制：
RBAC
RBAC（Role-Based Access Control）是 kubernetes 中基於角色的訪問控制，經過自定義角色並將角色和特定的 user，group，serviceaccounts 關聯起來達到權限控制的目的。
RBAC 中有三個比較重要的概念：
Role: 角色，它實際上是一組規則，定義了一組對 Kubernetes API 對象的操做權限；
Subject: 被做用者，包括 user、group、service account，通俗來說就是認證機制中所識別的用戶；
RoleBinding: 定義了「被做用者」和「角色」的綁定關係，也就是將用戶以及操做權限進行綁定；
RBAC 其實就是經過建立角色(Role），經過 RoleBinding 將被做用者（subject）和角色（Role）進行綁定。下圖是 RBAC 中的幾種綁定關係：
示例：
role:
權限聲明：
apiGroups爲「」表明全部核心資源即 v1 group
apiGroups爲「*」表明全部group
指定 pod 下的子對象如 kubectl logs xx，在resources中寫爲pods/log
對於 CRD 的權限能夠定義爲：
deployment、sts 等不在覈心組，
以 prometheus pod 所須要的權限爲例：
K8S 中的准入控制
准入控制是請求的最後一個步驟，准入控制有許多內置的模塊，能夠做用於對象的 「CREATE」、」UPDATE」、」DELETE」、」CONNECT」 四個階段。在這一過程當中，若是任一準入控制模塊拒絕，那麼請求馬上被拒絕。一旦請求經過全部的准入控制器後就會寫入 etcd 中。
准入控制是在 apiserver 中進行配置啓用的：
kubectl api-versions |grep admission 來確認是否開啓「admissionregistration.k8s.io/v1beta1」
准入控制的配置是有序的，不一樣的順序會影響 kubernetes 的性能。若須要對 kubernetes 中的對象作一些擴展，可使用准入控制，好比：建立 pod 時添加 initContainer 或者校驗字段等。准入控制最常使用的擴展方式就是 admission webhooks，分兩種
MutatingAdmissionWebhook：在對象持久化以前進行修改
ValidatingAdmissionWebhook：在對象持久化以前進行
istio就是經過 mutating webhooks 來自動將Envoy這個 sidecar 容器注入到 Pod 中去的：https://istio.io/docs/setup/kubernetes/sidecar-injection/。
admission webhooks是同步調用，須要部署webhook server，並建立對象ValidatingWebhookConfiguration 或 MutatingWebhookConfiguration來指向本身的 server，以ValidatingAdmissionWebhook爲例：
部署 webhook：
配置：ValidatingWebhookConfiguration
你須要等待幾秒，而後經過經過Deployment或者直接建立Pod，這時建立Pod的請求就會被apiserver攔住，調用ValidatingAdmissionWebhook進行檢查是否Admit經過。好比，上面的example-webhook是檢查容器鏡像是否以」gcr.io」爲前綴的。
示例中的 webhook邏輯比較簡單，只是檢查下 image name，而後啓動 http server
AdmissionWebhook 與 Initializers 的區別：
兩者都能實現動態可擴展載入admission controller， Initializers是串行執行，在高併發場景容易致使對象停留在uninitialized狀態，影響繼續調度。Alpha Initializers特性在k8s 1.14版本被移除了，官方更推薦AdmissionWebhook；MutatingAdmissionWebhook是串行執行，ValidatingAdmissionWebhook是並行執行，性能更好。
證書吊銷、過時更換
對於kubeconfig 這種 x509證書來講，只要證書不泄露，能夠認爲是很安全的。可是頒發證書容易，卻沒有很好的方案註銷證書、續期證書
吊銷
想一下若是某個核心成員離職，該如何回收他的admin kubeconfig證書？或者不當心把 kubeconfig 泄露，如何讓這個 kubeconfig 無效呢？
先看下封禁手段：
若是是離職，且 k8s 集羣在內網環境，就算他把證書帶出公司也不要緊，畢竟有內網訪問限制。但若是是雲上 k8s 集羣，且開放了公網的入口，那麼安全風險就很高了，kubeconfig 只是一個文件，你沒法經過限制 ip 來源來封禁。
若是是轉崗，封禁就比較困難了，仍然在內網環境，且 kubeconfig 通常在辦公電腦上使用，即辦公網絡到服務內網，經過來源封禁是不可能的。
再看下證書吊銷：
kubeconfig 證書不支持吊銷，參考 ISSUE。準確的說 k8s 沒有實現CRL（證書吊銷列表）或 OCSP（在線證書狀態協議），並無一個統一的地方管理這些證書，所以若是您的密鑰被盜用，Kubernetes也沒法在身份驗證層知道。
如何解決這種問題：
從新簽發證書，涉及到apiserver 等組件的重啓
若是用了 rbac，封禁這個角色的權限
如何預防這種問題:
重要：不要使用最高權限的證書，不要使用自帶權限的證書如 system:master，這種只適合kubelet 等組件使用，不適合用來簽發 kubeconfig
不管是用 user 仍是 service account 來生成kubeconfig，都使用 rbac 來受權，這樣就算 kubeconfig 丟失，也能夠解除 clusterrolebinding來吊銷權限。即管理給用戶的受權，就變成管理clusterrolebinding了
證書的過時時間設置的短一點，如 1 個月就失效，將影響範圍下降
合理規劃主帳號和子帳戶，如主帳戶只容許有一份 admin 證書，其餘子用戶所有基於 rbac 來操做，甚至主帳戶也能夠用 rbac 來操做，只是權限特別大而已
集成外部認證系統
證書之因此沒法吊銷，是由於證書沒有統一的認證中心，換句話，K8S只是定義了一些角色，並無實現用戶管理、權限管理，所以專業的人作專業的事，接入認證系統纔是生產環境嚴肅認真的解決方案。
Kubernetes支持集成第三方Id Provider（IdP），主流的如AD、LADP以及OpenStack Keystone等。通常都是基於 OpenID Connect（OIDC）Token 的認證和受權。
當前支持OpenID Connect的產品有不少，如：
Keycloak
UAA
Dex
OpenUnison
雲廠商
證書續簽
證書配置中有一個字段：」expiry」: 「87600h」表明了證書的過時時間，到期後證書認證會失敗。
kubeadm 建立的 Kubernetes 集羣， apiserver、controller-manager、kubelete 等組件的證書默認有效期只有一年。
由於 k8s 版本迭代很快，官方推薦一年以內至少用 kubeadm 更新一次 Kubernetes 版本，同時會自動更新證書。
查看根 CA 證書的有效期，默認爲 10 年：
查看當前證書有效期
從新簽發證書:續簽所有證書
也能夠局部進行續簽
如apiserver-etcd-client 、apiserver-kubelet-client、apiserver、etcd-healthcheck-client、etcd-peer、etcd-server、front-proxy-client
kubeadm alpha certs renew apiserver-etcd-client
若是不是 kubeadm 建立的集羣，須要手動從新生成全部組件的證書
kubelet 從 v1.8.0 開始支持證書輪換，當證書過時時，能夠自動生成新的密鑰，並從 Kubernetes API 申請新的證書。
更換 apiserver 的 ip 或接入 nginx
若是由於機器故障，須要更換 apiserver 機器，則最好保持 ip 不變，不然證書須要重籤，由於證書文件中聲明瞭機器 ip和負載均衡 ip，若是訪問時只用到了負載均衡 ip，那麼機器 ip 能夠不用聲明，也不用擔憂機器更換問題。
apiserver 接入 nginx
使用 nginx 的 passthrough，即 4 層轉發 ssl 請求（配置簡單，不須要apiserver證書）
方法二：使用七層正常的 http 轉發
多租戶集羣中的的用戶訪問控制
rbac 權限控制是多租戶集羣中最基礎的隔離手段，如基於 namespace 作租戶隔離：
企業內部集羣：也就是公司內的集羣，是不少 k8s 客戶的使用模式，由於集羣在公司內網環境，網絡風險可控，所以通常經過 namespace 對部門或產品線作隔離，如：
集羣管理員：admin 角色，最高權限，能夠擴、縮節點、升級集羣，負責分配PV、租戶等全局資源，通常是集羣負責人。
租戶管理員：op 角色，租戶內（namespace）的最高權限，管理租戶內的 rbac 權限、存儲、計算資源等
普通用戶：rd 角色，使用權限，根據開發測試角色不一樣，功能不一樣，可能會限制get/list/edit 等權限。
namespace 名通常和部門 id 是一致的，方便對接內部權限系統如 SSO，用戶登陸後只能看到本身的 ns 下的業務 pod，同時能夠下載本身的 kubeconfig 文件。
由於是經過 namespace 作 rbac 權限上的隔離，所以網絡層面也要隔離 namespace，禁止互訪，若是是跨租戶的訪問須要開放白名單。而存儲和主機特權的隔離須要根據業務來決定，如seccomp/AppArmor/SELinux等是否容許業務使用。
通常狀況下，namespace 的權限隔離能知足大多數企業 k8s 的需求，也是不少 paas 平臺的租戶實現方式。
saas & serveless 平臺：通常出如今公有云上，該場景下用戶沒有 k8s 的概念，且不一樣的服務能夠混布在不一樣的 namespace，如函數計算、AI 離線計算等，你只須要在 saas 控制檯上點擊部署 wordpress，選擇軟件版本，就能獲得一個完整的博客平臺，不須要關心後面的調度邏輯。
這種混布的業務若是有較高的安全需求，k8s 原生是沒法知足的，還須要使用安全容器如 kata在容器運行時來強化租戶安全。
其餘場景下的認證需求
ingress
除了 k8s 集羣的認證，ingress 也須要 https 證書，而 ssl 證書的續期管理都是一件麻煩事，若是你用的是雲廠商，能夠直接在雲上購買 ssl 證書並綁定域名，而後經過 ingress-controller 實現 ingress 的功能，續簽和證書管理都在雲上進行，不須要本身關心。
若是你以爲正規的 ca證書太貴，想用 Let’s Encrypt 等簽發方式，又以爲續簽麻煩，可使用Cert manager來管理你的證書實現證書自動續簽。
cert-manager + nginx-ingress-controller 結合能夠參考這個文章：https://cert-manager.io/docs/tutorials/acme/ingress/
helm
在 helm2 中，helm 操做須要配合集羣內部署 tiller 的 pod 來負責資源的建立，所以 tiller 須要賦予必定的權限，通常爲了簡單會爲 tiller 的 pod 賦予 cluster-admin 的最高權限
tiller pod 運行在kube-system 下，擁有集羣全部ns、全部資源的操做權限，不過你也能夠限定tiller的使用範圍，好比只能在特定的 namespace 下工做，如：
在特定 namespace 中部署 tiller，並僅限於在該 namespace 中部署資源
運行 helm init 來在 tiller-world namespace 中安裝 Tiller
而在 helm3 中已經不須要 tiller 這個組件，只須要一個 helm 二進制，所以helm 命令使用的 kubeconfig 的權限，也就決定了可以在哪一個 namespace 操做什麼資源，helm 權限和 kubectl 統一，更加方便。
歡迎你們關注個站：damon8.cn。
往期回顧
ArrayList、LinkedList 你真的瞭解嗎？
淺談 Java 集合 | 底層源碼解析
Spring Cloud Kubernetes之實戰一配置管理
Spring Cloud Kubernetes之實戰二服務註冊與發現
Spring Cloud Kubernetes之實戰三網關Gateway
關注公衆號，回覆入羣，獲取更多驚喜！公衆號(程序猿Damon)裏回覆 ES、Flink、Java、Kafka、MQ、ML、監控、大數據、k8s 等關鍵字能夠查看更多關鍵字對應的文章。
點擊 "damon8.cn" 獲取更好的閱讀體驗！
❤️
給個
「在看」
，是對我最大的支持❤️
本文分享自微信公衆號 - 程序猿Damon（Damon4X）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。