ref: https://jzimnowo.medium.com/harbor-keycloak-and-istio-a-good-dance-troupe-6c3520fb87de
本篇是個經驗分享文,作者想要打造一個基於 Kubernetes namespace 的多租戶 Kubernetes 平台。
該平台主要針對的是團隊內不同的 DevOps team,並且每個 Team 都會有自己的下列資源
1. Harbor: Private Container Registry
2. Keycloak: SSO
3. Istio: Service Mesh.
# Harbor
Harbor 是 CNCF 的畢業專案,專注於提供 private container registry,本身除了有友善的操作介面外,也整合了多項常見功能,譬如
1. 基於 OIDC 的授權認證機制
2. 容器安全性掃描
3. Chartmuseum (未來會被移除)
4. 專案管理
透過 OIDC 與專案的機制,能夠很輕鬆的針對不同專案設定不同權限,譬如屬於群組 A 的只能使用 Project A。
此外每個專案本身也有提供 robot account,該 robot account 的目的則是讓整個工作流程更佳簡潔。
如果要於 Kubernetes 中去抓取這些 Private Container Registry,則必須要透過 ImagePullSecret 的物件來描述登入資訊。
為了避免使用個人帳戶來存取,作者推薦每個專案都要準備兩個 Robot Account,這兩個 Robot Account 都只能針對該專案底下的 container 去存取
所以也不用擔心會去存取到其他 Team 的專案。
第一個 robot account 專注於 Pull Image,主要是讓 Kubernetes 內部可以下載 Image 使用。
第二個 robot account 則是給 CI/CD pipeline 使用,讓 pipeline 有能力將新的 image 給推向 Harbor。
前述所說 Harbor 可以基於 OIDC 來滿足認證的機制,作者於團隊中就使用 Keycloak 這個開源來作為一個 OIDC 提供者(另外一個常見的是 Dex)。
文章中有稍微介紹如何於 Keycloak 中創立一個 Client 的物件,並且於 Harbor 如何設定。
如果團隊有這個需求的可以看一下要如何操作。
文章最後探討使用這三個專案的一些經驗與痛點,有興趣的可以閱讀全文參考
cncf認證 在 矽谷牛的耕田筆記 Facebook 的精選貼文
ref: https://loft.sh/blog/the-cost-of-managed-kubernetes-a-comparison/
本篇文章探討不同 Cloud Provider kubernetes 服務的差異,作者列舉了四個常見的 kubernetes 服務,包含 GKE, EKS, AKS 以及 DOKS。
這四個 kubernetes 服務所部署的 Kubernetes 叢集都有獲得 CNCF Kubernetes Certification 的認證,不同 Cloud Provider 都有自己的優缺點。
使用 Kubernetes 服務帶來的好處就是使用者通常不太需要去擔心如何處理
1. Kubernetes 核心元件之間的 Certificate (API Server, Controller, Scheduler, Kubelet ...etc)
2. 動態調整 Kubernetes 節點
3. 相較於單純靠社群, Cloud Provider 可以提供更快速且更好的支援(畢竟有付錢給對方)
因此該文章接下來就會針對這四個 Kubernetes 服務來探討一下彼此的差異。
註: 有興趣的話都可以用 Sonobuoy 這個開源專案來檢測自己維護的 Kubernetes 叢集,通過測試就可以把測試報告送到 GitHub 開 Issue 申請認證
GKE
1. Kubernetes 正式公開後一個月就 GKE 就出現了 (08/2015), 是最早的 Kubernetes 服務
2. GKE 會使用 gVisor 專注於安全層級的容器隔離技術來部署服務。
3. 有機會使用針對 Container 最佳化的 OS,有些 cloud provider 只能使用 Ubuntu image 之類的。
4. 服務出現問題時,可以啟動 auto-repair 來修復叢集,一種典型作法就是將一直回報為 NotReady 的 k8s 節點給重建
5. GKE 提供自動升級 Kubernetes 版本的功能,如果不想要的話記得要去關閉這個功能,否則自動升級是有可能讓某些應用程式無法正常運作的。
6. 使用 GKE 的話,要付每小時 $0.1 美元的管理費。如果使用 on-prem 的解決方案 (Anthos) 的話就可以免去這些管理費。
EKS
1. 06/2018 創立
2. 可以使用 Ubuntu Image 或是 AWS 針對 EKS 最佳化的 EKS AMI 來獲得更好的效能。
3. EKS 沒有提供自動升級 Kubernetes 版本的功能,官方有提供大量詳細的文件介紹如何手動升級 Kubernetes 版本
4. 沒有類似 auto-repair 的機制去幫忙監控與修復出問題的 k8s node,因此 EKS 使用者需要自己去監控與維護這些節點。
5. EKS 也是每小時 $0.10 的管理費用。 AWS Outposts/EKS Anywhere 這些 2021 啟動的專案讓你有機會將 EKS 部署到 on-prem 的環境中。
AKS
1. 06/2018 創立
2. AKS 沒有提供任何最佳化的 OS,你只能使用常見的那些 OS image 作為你的 k8s 節點
3. 預設情況不會自動升級 kubernetes 版本,不過 AKS 提供選項去開啟自動升級。Cluster 有四種不同策略(none,patch,stable,rapid)來自動更新你的 k8s 叢集。
4. AKS 預設不會啟動 auto-repair 功能。對於一直持續回報 NotReady 的節點, AKS 會先重起該節點,如果問題無法解決就會砍掉重建節點。
5. AKS 不收管理費
6. Azure 沒有特別提供一個供 on-prem 的 AKS 解決方案,不過透過 ARC 是有機會於 on-prem 的環境運行 AKS.
DOKS(DigitalOcean)
1. 05/2019 創立
2. 有提供 kubernetes 版本自動更新功能,但是只有針對 patch 版本的變化
3. 沒有 auto-repair 的功能
4. 文章撰寫的當下, DOKS 沒有任何文件說明如何於 on-prem 的環境運行 DOKS
5. 不收管理費
6. 相對其他三家來說,底層架構相對便宜,一個 DOKS 最低可以低到每個月 $10 美元。
價錢比較:
1. 假設需要創建一個擁有 20 節點並且有 80vCPU, 320GB RAM 的叢集 (GKE 因為每個節點都是 15GB,所以最後只能湊到 300GB)
2. 每個月為單位去計算價格,AKS/EKS/GKE 都使用其提供的價格計算機來粗估, DOKS 需要手動計算。
3. 價錢評比
a. AKS: $3416
b. EKS: $2928
c. DOKS: $2400
d. GKE: $1747
對文章有興趣的別忘了參閱全文
cncf認證 在 矽谷牛的耕田筆記 Facebook 的精選貼文
ref: https://medium.com/flant-com/cert-manager-lets-encrypt-ssl-certs-for-kubernetes-7642e463bbce
這篇文章是個分享文,作者分享如何使用 cert-manager 這個工具透過 lets-encrypts 來獲得一個被認證的 SSL 憑證供 kubernetes 內部應用使用。
根據 CNCF Technology Radar(https://radar.cncf.io/2021-02-secrets-management) 的介紹,目前 Cert-Manager 幾乎是 k8s 內管理憑證最為知名的專案。
本篇文章針對幾個四種不同的使用情境來介紹如何使用 cert-manager,以下針對每個用法給一些摘要。
前期提要:
Kubernetes 會使用 SSL 憑證的大部分情況都是透過 Ingress 這個物件去描述需要使用 Certificate,所以文章的範例都會是基於 Ingress 的使用下手。
譬如說 Ingress 想要使用開啟 TLS 的功能,需要使用一個 secret,而 Cert-Manager 則會基於其設定最後產生出一個符合 Certificate 用法的 Secert 物件給 Ingress 使用。
Self-signed certificate
第一種是最簡單也是最直接的用法,透過 cert-manager 來產生一組自行簽署的簽證
正常情況下產生後的自簽憑證預設是不被信任的,畢竟預設情況下並沒有加入一個 CA,因此簽出來的憑證用瀏覽器打開還是會呈現不可信任
如果環境有事先準備好 CA 的話,是可以將該 CA 加入到 cert-manager 的設定中,這樣就可以簽出一個被信任的憑證了。
Let’s Encrypt certificate with the HTTP/DNS validation
第二個則是最普遍的用法,就是透過 Let's Encrypt 的服務來獲得一個可以被信任的憑證,而 Cert-Manager 目前支持兩種 ACME 的認證方式,分別是 HTTP 以及 DNS,這兩個方式最主要的目的都是要確認
申請者是該申請 domain 的擁有者,所以可以透過不同的方式來驗證。
如果想要使用 DNS 來進行驗證的則必須要確認該域名管理的服務商是否有提供相關的 API 同時該 API 是否 cert-manager 有支援,文章中作者使用 CloudFlare 來當範例展示一下如何使用 DNS 挑戰來驗證相關的 TXT Record.
由於 DNS Record 本身會有 Propagation 延遲傳遞的問題,因此驗證上通常會比使用 HTTP 的方式還來得慢一點。
Cert-Manager 本身也支援兩種方式同時使用。
另外使用 Let's Encrypt 時要特別注意,非常推薦一開始使用 Let's Encrypt Staging 的服務來進行測試,不要一開始就直接使用 Production 的 API,因為 Production 會將短時間內發送大量請求的網域給停權一陣子,要等待一段時間後才可以再次發送。
因此開發測試過程請先使用 Staging 的 API,待一切沒問題後才轉向 Production API。
Using special Ingress annotations
這種方法其實是簡化維運者的工作,Cert-Manager 會有一個額外的 Controller 去監聽所有的 Ingress 物件,如果該 Ingress 物件的 Annotation 有描述跟憑證相關的資訊,該 Controller
就會自動創造 cert-manager 相關的資源,讓管理者減少需要自己部署的物件數量,反而將部分操作轉交給 Controller 去處理。
cncf認證 在 CKA認證- 02_2 環境設定Windows OS (適用版本Kubernetes ... 的推薦與評價
【CKA 介紹】Certified Kubernetes Administrator(CKA) 認證 計畫由Cloud Native Computing Foundation( CNCF )組織,提供考生以Kubernetes 平台管理員的 ... ... <看更多>
cncf認證 在 蓋亞資訊全台唯一Kubernetes通過CNCF認證 - Facebook 的推薦與評價
全台第一家☝ 蓋亞資訊取得KCSP資格成為全台唯一Kubernetes通過國際 CNCF認證 之混合雲供應商擁有通過Linix foundation授權認證的國際專業講師 ... ... <看更多>