Skip to main content

3 posts tagged with "Helm"

View All Tags

· 3 min read

如何投過 Bitnami 的 Helm Chart 來安裝 Redis-Cluster

採用 Kustomize + Helm 的方式 (ArgoCD)

$ cat kustomization.yaml
helmCharts:
- name: redis-cluster
includeCRDs: false
valuesFile: redis.yaml
releaseName: redis-cluster
namespace: production
version: 9.0.5
repo: https://charts.bitnami.com/bitnami

$ cat redis.yaml

global:
storageClass: standard-rwo
existingSecret: redis-cluster
existingSecretPasswordKey: password
redis:
resources:
limits:
cpu: 2
memory: 2Gi
requests:
cpu: 0.1
memory: 0.5Gi
podAnnotations:
'xxxxx': 'yyyyy'

這種部署方式就會啟動密碼驗證機制,而密碼則來自於同 namespace 的 secret 物件 redis-cluster 內的 key password.

如果想要無密碼驗證,可以使用下列方式

usePassword: false

'''note 如果已經先行有密碼驗證,則修改此欄位對於運行中的 Redis Cluster 不會有任何效果,這部分需要更多額外操作來完成,砍掉 PVC 重新部署是一個簡單暴力的方式。 '''

由於此架構會部署 Redis-cluster,預設情況下會部署三組(master+worker)的 statefulset,並且給兩組 servicee

redis-cluster                       ClusterIP      10.2.5.248    <none>        6379/TCP                                                                                          213d
redis-cluster-headless ClusterIP None <none> 6379/TCP,16379/TCP 213d

另外要注意的是,redis-cluster 並不適用 kubectl port-forward 的方式連接,因為 redis-cluster 的溝通過程會回傳其他 Pod 的 IP 給你,而每個 Pod 的 IP 都用相同的 Port,因此除非你有辦法於本地產生一些虛擬網卡並且搭配多組 kubectl port-forawrd 幫每個 Pod 都打通,否則存取上會出問題。

舉例來說

$ kubectl port-forward --address 0.0.0.0 pod/redis-cluster-0 6379:6379
Forwarding from 0.0.0.0:6379 -> 6379
$ redis-benchmark -n 1 --cluster
Cluster has 3 master nodes:

Master 0: 1020525d25c7ad16e786a98e1eb7419d609b8847 10.4.0.119:6379
Could not connect to Redis at 10.4.0.119:6379: Connection refused

可以看到透過 port-forward 打進去後,接下來的連線就會轉到其他的 pod 然後就會失敗,因此這種情況要簡單使用還是部署一個包含 redis 指令的 Pod 到同樣的 namespace 並且用 kubectl exec 進去操作會比較順

$ kubectl run --image=hwchiu/netutils test
$ kubectl exec -it test -- bash
root@test:/# redis-benchmark -h redis-cluster -q -c 20 -n 30000
PING_INLINE: 44977.51 requests per second
PING_BULK: 48154.09 requests per second
SET: 45317.22 requests per second
GET: 47169.81 requests per second
INCR: 50251.26 requests per second
LPUSH: 48465.27 requests per second
LPOP: 41265.48 requests per second
SADD: 37878.79 requests per second
SPOP: 49833.89 requests per second
LPUSH (needed to benchmark LRANGE): 51724.14 requests per second
LRANGE_100 (first 100 elements): 43041.61 requests per second
LRANGE_300 (first 300 elements): 35842.29 requests per second
LRANGE_500 (first 450 elements): 36014.41 requests per second
LRANGE_600 (first 600 elements): 33259.42 requests per second
MSET (10 keys): 42796.01 requests per second

· 2 min read

Helm Chart 中可以透過各種 if/else 的語法將物件給包裹起來,這個操作會影響最後安裝過程中 該物件會不會被產出並且安裝到目標叢集中,因此大部分都是都過 Values 裡面的 enable/disable 等參數來調整。

但是如果今天該物件的安裝條件則是根據 K8s 版本而定,特別是當某些 API 於新版被移除時,這時候要如何撰寫一個兼容兩個版本的 Helm Chart。 舉例來說,以最近被移除的 PSP(PodSecurityPolicy) 物件為範例。

  1. 第一個做法就是維護兩個版本的 Helm Chart,針對新版的 Kubernetes 推進新版本,移除 PSP 物件並且針對 k8s 版本限制最低版本,舊 k8s 叢集不支援
  2. 使用 Helm 內建語法 .Capabilities.APIVersions.Has 去判斷目標 K8s API Resource 是否有包含目標版本

kube-prometheus-stack 為範例 其 psp-clusterorle.yaml 中的開頭使用了下列語法

{{- if and .Values.prometheus.enabled .Values.global.rbac.create .Values.global.rbac.pspEnabled }}
{{- if .Capabilities.APIVersions.Has "policy/v1beta1/PodSecurityPolicy" }}
kind: ClusterRole
...
{{- end }}
{{- end }}

透過 .Capabilities.APIVersions.Has 語法去判斷該物件是否支援,若支援則安裝否則跳掉,這機制帶來的好處就是可以打造出一個兼容更多版本 K8s 叢集的 Helm Chart,但是實務上真的需要這樣控管?還是應該要用不同版本的來管理會更好應該就見仁見智。

· 3 min read

標題: 「透過 Helm 與 Terraform 來自動 Re-new Cloudflare origin CA」 類別: usecase 連結: https://awstip.com/auto-renew-cloudflare-origin-ca-with-terraform-and-helm-d28be3f5d8fa?source=linkShare-91a396987951-1645539866&gi=a18b2bbd9604

本篇文章是過工具介紹文,探討如何基於 Helm 與 Terraform 這兩個不同層級的工具來處理 Cloudflare 的憑證。

Why Cloudflare

根據 W3Techs 的調查顯示, 81.2% 的網站都使用 Cloudflare 來提升讀取速度或安全防護。 透過 CDN 的概念與機制,網站可以讓全球使用者有更快的讀取速度,此外也愈來愈多的網站會透過 Cloudflare 來處理如機器人, DDOS 之類的流量攻擊,畢竟要自己架設網站處理這些攻擊非常困難 因此讓 Cloudflare 這類型的網站來幫忙過濾與處理能夠讓團隊更專注於本身的業務開發與維運

Kubernetes

想要在 Kubernetes 內妥善管理所有使用的憑證其實也是一個麻煩事情,除了要能夠設置正確來創立憑證外,能夠於到期前自動 re-new 也是一個不可或區的功能。 Kubernetes 內跟憑證有關的最知名專案我想就是 Cert-Manager,而 Cloudflare 也基於此專案撰寫了相關的 Kubernetes Controller,如 Origin CA 等 因此本文使用的功能與示範都會基於 cert-manager 與 Cloudflare 的架構。

目的

本文的目的是希望能夠將過往手動的繁瑣步驟給自動化,讓 Kubernetes 可以獲得 Cloudflare 提供的好處,如憑證與相關域名等。 內文是基於 Terraform 作為出發點,然後透過 Kubernetes Provider 的方式來與之互動,一步一步的安裝各種資源最後成功於叢集內獲得相關域名的 SSL 憑證以及其他資源