普通视图

发现新文章,点击刷新页面。
昨天以前Hwchiu Learning Note

Multus 下如何透過 network policy 設定

作者 HungWei Chiu
2023年12月24日 08:00

由於 Multus 下會透過多組 CNI 讓 Pod 內去呼叫多個 CNI 最後產生多個網卡,而 NetworkPolicy 這種情況下其實有點危險 當安裝的 CNI 數量夠多且每個都支援時也有可能讓這些 controller 太忙 另外大部分的 Multus 都是使用 SRIOV, Bridge, Macvlan 等本來就沒有實作 Network Policy 的 CNI,若有需求時就有點麻煩

Multus 那有相關的專案來解決這個問題,以下專案提供介面 https://github.com/k8snetworkplumbingwg/multi-networkpolicy

該專案被用於 openshift 環境內,實作的專案(iptables)如下 https://github.com/openshift/multus-networkpolicy

其會動態的進入到目標 Pod 內去下 iptables 的規則來控管封包的進出

專案內的 deploy.yaml 可以直接安裝,不過下列參數需要修改

  1. 修改參數 args:
    - "--host-prefix=/host"
    # uncomment this if runtime is docker
    # - "--container-runtime=docker"
    - "--network-plugins=bridge"
    - "--v=9"
    - "--container-runtime-endpoint=/run/containerd/containerd.sock"
  2. 若不需要可以移除 custom iptavles 相關的 volume

(1) 的部分要特別注意 --networks-plugins=bridge 以及 --container-runtime-endpoint 前者要跟 multus 串連的 multus 一致,這樣才會運作

接者就要部署專屬的 MultiNetworkPolicy 的物件,用法與傳統的 Network Policy 一樣

apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
metadata:
name: test-network-policy
namespace: default
annotations:
k8s.v1.cni.cncf.io/policy-for: bridge-network
spec:
podSelector:
matchLabels:
app: debug
policyTypes:
- Ingress
- Egress
ingress:
- from:
- ipBlock:
cidr: 10.10.0.5/24
egress:
- to:
- ipBlock:
cidr: 10.10.0.7/32

設定完成後就有機會於符合規則的 container 內看到下列規則

[142:11928] -A INPUT -i net1 -j MULTI-INGRESS
[478:40152] -A OUTPUT -o net1 -j MULTI-EGRESS
[0:0] -A MULTI-0-EGRESS -j MARK --set-xmark 0x0/0x30000
[0:0] -A MULTI-0-EGRESS -j MULTI-0-EGRESS-0-PORTS
[0:0] -A MULTI-0-EGRESS -j MULTI-0-EGRESS-0-TO
[0:0] -A MULTI-0-EGRESS -m mark --mark 0x30000/0x30000 -j RETURN
[0:0] -A MULTI-0-EGRESS -j DROP
[0:0] -A MULTI-0-EGRESS-0-PORTS -m comment --comment "no egress ports, skipped" -j MARK --set-xmark 0x10000/0x10000
[0:0] -A MULTI-0-EGRESS-0-TO -d 10.10.0.7/32 -o net1 -j MARK --set-xmark 0x20000/0x20000
[0:0] -A MULTI-0-INGRESS -j MARK --set-xmark 0x0/0x30000
[0:0] -A MULTI-0-INGRESS -j MULTI-0-INGRESS-0-PORTS
[0:0] -A MULTI-0-INGRESS -j MULTI-0-INGRESS-0-FROM
[0:0] -A MULTI-0-INGRESS -m mark --mark 0x30000/0x30000 -j RETURN
[0:0] -A MULTI-0-INGRESS -j DROP
[0:0] -A MULTI-0-INGRESS-0-FROM -s 10.10.0.0/24 -i net1 -j MARK --set-xmark 0x20000/0x20000
[0:0] -A MULTI-0-INGRESS-0-PORTS -m comment --comment "no ingress ports, skipped" -j MARK --set-xmark 0x10000/0x10000
[0:0] -A MULTI-EGRESS -o net1 -m comment --comment "policy:test-network-policy net-attach-def:default/bridge-network" -j MULTI-0-EGRESS
[0:0] -A MULTI-INGRESS -i net1 -m comment --comment "policy:test-network-policy net-attach-def:default/bridge-network" -j MULTI-0-INGRESS
COMMIT

其透過 mark 的方式來標示封包是否需要被 DROP,同時也支援針對 ip & port 的方式去判斷

k8s 內安裝 redis-cluster

作者 HungWei Chiu
2023年9月11日 08:00

如何投過 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

Helm Chart 中如何根據條件來動態安裝 Template 內的物件

作者 HungWei Chiu
2023年9月1日 08:00

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,但是實務上真的需要這樣控管?還是應該要用不同版本的來管理會更好應該就見仁見智。

GCS 操作上注意事項

作者 HungWei Chiu
2023年7月21日 08:00

GCS 本身對於存放的資料有不同分類,包含

  1. STANDARD
  2. NEARLINE
  3. COLDLINE
  4. ARCHIVE

分類的設定可以從

  1. 預設值 Storage class
  2. 設定 Lifecycle Rule,針對超過一定天數的檔案自動調整不同的分類

這幾個分類對消費者來說最大的影響可能就是存取與維護成本 以Cloud Storage pricing來說

存放本身的價格就是 STANDARD > NEARLINE > COLDLINE > ARCHIVE

但是如果今天想要存取資料(Retrieval fees)來說則要特別注意 STANDARD 本身免費,後面三者價格依序提高,其中以 COLDLINE 來說是 $0.02 GB

因此若需要存取 GCS 的話,則特別要注意目前檔案的屬性以及存取量,然後評估一下可能的花費 若有需要大量長期存取的,記得要切換成 STANDARD 模式,若幾乎不存取的就直接往後搬移減少儲存花費。

istio 操作記錄

作者 HungWei Chiu
2023年7月21日 08:00

預設的 istio-proxy 都會吃掉一些 CPU/Memory,當叢集內的 Pod 數量過多時,這些 sidecar 吃掉的數量非常可觀 如果是採用 istiooperator 的方式安裝,可以採用下列方式修改

...
spec:
values:
global:
proxy:
privileged: false
readinessFailureThreshold: 30
readinessInitialDelaySeconds: 1
readinessPeriodSeconds: 2
resources:
limits:
cpu: 2000m
memory: 1024Mi
requests:
cpu: 100m
memory: 128Mi

這個設定是 global 的設定,如果是單一的 Pod 要自行調整,可以於 Pod annotations 中加入列下資訊調整

annotations:
sidecar.istio.io/proxyCPU: 50m
sidecar.istio.io/proxyMemory: 128Mi

如果要更新 istio,建議參考官方 Canary Approach 的步驟,使用金絲雀部署的方式逐步調整 其原理很簡單

  1. 同時部署兩個版本的 istiod
  2. 逐步重啟 Pod 來套用新版本的 istio,直到所有 pod 都轉移到新版本的 istiod
  3. 移除舊的

基本上安裝過程要透過 "--revision=1-14-2" 的方式去打版本,安裝完畢後就是單純只有 control plane

接下來就取決當初如何設定 sidecare 的,如果是 namespace 的話,就可以直接改 namespace 裡面的

istio.io/rev=1-14-2

接下來就逐步重啟 Pod 就可以切換到新的 istio 版本。

另外可以透過 istioctl proxy-status 觀察每個 Pod 目前搭配的版本,透過此指令觀察升級進度

一旦全部升級完畢可以用 istioctl uninstall --revision 1-13-1 -y 來移除舊版本

terraform

2023年6月21日 08:00

-- title: terraform 小筆記 authors: hwchiu tags:

當使用支援 Lock 的遠端 Backend 時,每次執行 Terraform 操作都會嘗試去 Lock,並且指令結束後去釋放 Lock 若執行到一半就透過 CTRL+C 強制離開可能會導致 Lock 沒有辦法順利結束,這時候下次執行就會遇到下列的問題

$ terraform apply
Acquiring state lock. This may take a few moments...

│ Error: Error acquiring the state lock

│ Error message: writing "gs://xxxxx/xxxxxxx/default.tflock" failed: googleapi: Error 412: At least one of the pre-conditions you specified did not hold., conditionNotMet
│ Lock Info:
│ ID: 1696991555387294
│ Path: gs://xxxxx/xxxxxxx/default.tflock
│ Operation: OperationTypeApply
│ Who: your_name@hostname.local
│ Version: 1.5.6
│ Created: 2022-10-11 02:32:35.12734 +0000 UTC
│ Info:

│ Terraform acquires a state lock to protect the state from being written
│ by multiple users at the same time. Please resolve the issue above and try
│ again. For most commands, you can disable locking with the "-lock=false"
│ flag, but this is not recommended.

當然上述原因也有可能是同時間真的有人其他人正在運行指令,把 lock 搶走,所以要先釐清 lock 卡住的情況是否如預期 如果是不預期的,就需要執行下列指令手動移除 lock

以上面輸出的 ID 當作內容,透過 terraform force-unlock 來解除

$ terraform force-unlock 1696991555387294
Do you really want to force-unlock?
Terraform will remove the lock on the remote state.
This will allow local Terraform commands to modify this state, even though it
may still be in use. Only 'yes' will be accepted to confirm.

Enter a value: yes

如果需要調整 Terraform State 的內容的話,通常可以使用

  1. terraform state list
  2. terraform state rm xxxx

手動將不需要的內容從 state 中移除

但是如果今天有更強硬的要求需要手動去修改內容的話,則需要

  1. terraform state pull > old_state
  2. vim a
  3. terraform state push old_state

這招很危險,要 100% 清楚自己做什麼同時也要有備份的 state 檔案,大意就是把 state 檔案抓下來並且直接修改,然後強行寫入回去,完全不需要額外 terraform plan/apply 的介入。 通常是 migration 過程希望可以順利轉移,同時又不希望遠方資源被影響,就可能會採用這種機制來直接修改 state.

此外轉移過程中如果有 provider 要處理,也可以透過使用 terraform state replace-provider 的方式來轉移,如下範例

terraform state replace-provider "registry.terraform.io/-/aws" "hashicorp/aws"

Kubernetes GKE 維運上小筆記

作者 HungWei Chiu
2023年6月11日 08:00

GKE 環境上可以啟動 CA(Cluster-Autoscaling) 來根據資源使用量調整節點的數量,可以視為節點層級的 HPA

基本上只要節點的資源使用率過低,該節點就會被嘗試回收並且將所有的 Workload 都轉移到其他的節點

如果有特別特別重要的 Pod 希望該 Pod 能夠抑制 CA 的行為,有該 Pod 運行的節點都不能被踢除回收的話,可以於 annotations 中加入下列設定

    cluster-autoscaler.kubernetes.io/safe-to-evict: 'false'

該節點就會讓節點沒有辦法順利踢除因此最後不會回收該節點,該指令也要小心使用,若用不好可能會導致節點資源使用率過低最後產生額外的花費。

應用程式本身需要更長時間去調整 GracePeriod (預設 30 秒),可以直接修改 pod.spec.terminationGracePeriodSeconds 此欄位即可

$ kc explain pod.spec.terminationGracePeriodSeconds
KIND: Pod
VERSION: v1

FIELD: terminationGracePeriodSeconds <integer>

DESCRIPTION:
Optional duration in seconds the pod needs to terminate gracefully. May be
decreased in delete request. Value must be non-negative integer. The value
zero indicates stop immediately via the kill signal (no opportunity to shut
down). If this value is nil, the default grace period will be used instead.
The grace period is the duration in seconds after the processes running in
the pod are sent a termination signal and the time when the processes are
forcibly halted with a kill signal. Set this value longer than the expected
cleanup time for your process. Defaults to 30 seconds.

簡易 bash 腳本可以備份目前環境中的所有 secret 物件

function dump_secret {
for i in $(kubectl -n $1 get --no-headers secret | awk '{print $1}'); do
kubectl -n $1 get secret -o yaml $i > $i.yaml;
done
}

function dump_secrets {
for i in $(kubectl get ns --no-headers | awk '{print $1}'); do
if [ ! -d "./$i" ]; then
mkdir $i
fi
echo "Dump $i"
cd $i
dump_secret $i
cd ..
done
}

Loki 安裝上的參數調整以及 Ring 的問題除錯

作者 HungWei Chiu
2023年5月1日 08:00

因為 HPA 或是 CA 等調度使得 Ingester 等 Pod 重啟後,有機會踩到 Bug 使得系統中存在 unhealthy instance. 常見的錯誤訊息為 too many unhealthy instances in the ring

這種情況的解法有兩個

  1. 手動移除
  2. 設定環境讓其自動移除

手動移除的部分需要存取 loki-distributor 的 UI,譬如

$ kubectl port-forward svc/loki-distributor 3100:3100

接者存取 localhost:3100/ring 的網頁,就可以看到所有 instance 的資訊,針對不健康的 instance 從網頁中將其遺忘即可。

另外也可以部署安裝 Loki(Helm) 的過程中設定 ingester 的參數讓其自動忘記,未來就不需要手動設定

ingester:
autoforget_unhealthy: true

另外部署效能上有不少參數需要調整,通常都是 limits_config,新舊版本有些設定有差 然後 querier 以及 ingester 需要額外調整自己的 resource 與 HPA 的數量,根據使用者習慣以及用量來調整已提升整體吞吐量

loki:
config: |
server:
grpc_server_max_recv_msg_size: 104857600
grpc_server_max_send_msg_size: 104857600
http_server_read_timeout: 10m
http_server_write_timeout: 10m
ingester:
chunk_idle_period: 10m
chunk_block_size: 262144
chunk_encoding: snappy
chunk_retain_period: 1m
max_transfer_retries: 0
wal:
dir: /var/loki/wal
limits_config:
max_global_streams_per_user: 15000
enforce_metric_name: false
reject_old_samples: true
reject_old_samples_max_age: 168h
max_cache_freshness_per_query: 10m
retention_period: 2160h
split_queries_by_interval: 30m
ingestion_rate_mb: 32
ingestion_burst_size_mb: 64
max_query_parallelism: 256
max_cache_freshness_per_query: 10m
per_stream_rate_limit_burst: 15MB
gateway:
nginxConfig:
httpSnippet: client_max_body_size 50M;
serverSnippet: |-
client_max_body_size 50M;
proxy_read_timeout 600s;
proxy_send_timeout 600s;

觀測 K8s 內 OOM 事件

作者 HungWei Chiu
2023年4月12日 08:00

Kubernetes 內的容器運行上可能會遇到 OOM (Out Of Memory),通長會有兩種情況

  1. 應用程式本身的 Memory Limit 沒有設定好,因此踩到上限被移除
  2. 眾多應用程式的 Memory Request 沒有設定好,導致系統資源被互搶直到系統沒有足夠記憶體,因此觸發 OOM 開始砍人

這類型的事件可以透過下列的方式去觀測

  1. 安裝 kube event exporter,該專案會將所有 event 以不同的方式輸出。簡易方式可以採用 stdout 的方式輸出
  2. 透過 Logging 系統收集 stdout 的 log,從中分析是否有 OOM 的事件發生,有的話可以發送 Alert

以 Loki 來說,可以採用下列語法去過ㄌㄩ

count_over_time({container="kube-event-exporter"}[1m] | json | __error__ != "JSONParserErr" | reason="OOMKilling")

Kubevirt 初體驗

作者 HungWei Chiu
2023年10月10日 08:00

本文紀錄如何於 Linux(Ubuntu 22.04) 環境上簡易搭建 Kubevirt 的環境

環境搭建

KVM

安裝指令來檢查 qemu 相關狀態

sudo apt install libvirt-clients

使用 virt-host-validate 檢查相關

$ virt-host-validate qemu
QEMU: Checking for hardware virtualization : PASS
QEMU: Checking if device /dev/kvm exists : PASS
QEMU: Checking if device /dev/kvm is accessible : FAIL (Check /dev/kvm is world writable or you are in a group that is allowed to access it)
QEMU: Checking if device /dev/vhost-net exists : PASS
QEMU: Checking if device /dev/net/tun exists : PASS
QEMU: Checking for cgroup 'cpu' controller support : PASS
QEMU: Checking for cgroup 'cpuacct' controller support : PASS
QEMU: Checking for cgroup 'cpuset' controller support : PASS
QEMU: Checking for cgroup 'memory' controller support : PASS
QEMU: Checking for cgroup 'devices' controller support : WARN (Enable 'devices' in kernel Kconfig file or mount/enable cgroup controller in your system)
QEMU: Checking for cgroup 'blkio' controller support : PASS
QEMU: Checking for device assignment IOMMU support : WARN (No ACPI DMAR table found, IOMMU either disabled in BIOS or not supported by this hardware platform)
QEMU: Checking for secure guest support : WARN (Unknown if this platform has Secure Guest support)

可以看到中間有一個錯誤,這時候需要安裝 sudo apt install qemu-kvm 並且調整權限 sudo usermod -aG kvm $USER.

$ virt-host-validate qemu
QEMU: Checking for hardware virtualization : PASS
QEMU: Checking if device /dev/kvm exists : PASS
QEMU: Checking if device /dev/kvm is accessible : PASS
QEMU: Checking if device /dev/vhost-net exists : PASS
QEMU: Checking if device /dev/net/tun exists : PASS
QEMU: Checking for cgroup 'cpu' controller support : PASS
QEMU: Checking for cgroup 'cpuacct' controller support : PASS
QEMU: Checking for cgroup 'cpuset' controller support : PASS
QEMU: Checking for cgroup 'memory' controller support : PASS
QEMU: Checking for cgroup 'devices' controller support : WARN (Enable 'devices' in kernel Kconfig file or mount/enable cgroup controller in your system)
QEMU: Checking for cgroup 'blkio' controller support : PASS
QEMU: Checking for device assignment IOMMU support : WARN (No ACPI DMAR table found, IOMMU either disabled in BIOS or not supported by this hardware platform)
QEMU: Checking for secure guest support : WARN (Unknown if this platform has Secure Guest support)

Kubernetes

透過 minikube 搭建一個 k8s (provider採用 docker 減少第二層虛擬化)

$ minikube start --cni=flannel

叢集準備好後,安裝 kubevirt-operator

$ export VERSION=$(curl -s https://api.github.com/repos/kubevirt/kubevirt/releases | grep tag_name | grep -v -- '-rc' | sort -r | head -1 | awk -F': ' '{print $2}' | sed 's/,//' | xargs)
$ echo $VERSION
$ kubectl create -f https://github.com/kubevirt/kubevirt/releases/download/${VERSION}/kubevirt-operator.yaml
namespace/kubevirt created
customresourcedefinition.apiextensions.k8s.io/kubevirts.kubevirt.io created
priorityclass.scheduling.k8s.io/kubevirt-cluster-critical created
clusterrole.rbac.authorization.k8s.io/kubevirt.io:operator created
serviceaccount/kubevirt-operator created
role.rbac.authorization.k8s.io/kubevirt-operator created
rolebinding.rbac.authorization.k8s.io/kubevirt-operator-rolebinding created
clusterrole.rbac.authorization.k8s.io/kubevirt-operator created
clusterrolebinding.rbac.authorization.k8s.io/kubevirt-operator created
deployment.apps/virt-operator created

實驗當下使用的版本是 v1.1.0-alpha.0,安裝完畢後檢查 kubevirt namespace 的資源

$ kubectl -n kubevirt get pods
NAME READY STATUS RESTARTS AGE
virt-operator-57f9fb965d-5lnqf 1/1 Running 0 46m
virt-operator-57f9fb965d-f5zg4 1/1 Running 0 46m

接下來安裝 CRD 物件

$ kubectl create -f https://github.com/kubevirt/kubevirt/releases/download/${VERSION}/kubevirt-cr.yaml

安裝完畢後可以看到有一個名為 kubevirt 的物件(CRD為 kubevirt,簡稱 kv)被創立,因此 operator 就會針對該物件去創立 kubevirt 相關的服務 Pod

$ kubectl -n kubevirt get kv kubevirt -o yaml
apiVersion: kubevirt.io/v1
kind: KubeVirt
metadata:
annotations:
kubevirt.io/latest-observed-api-version: v1
kubevirt.io/storage-observed-api-version: v1
creationTimestamp: "2023-10-10T14:35:55Z"
finalizers:
- foregroundDeleteKubeVirt
generation: 2
name: kubevirt
namespace: kubevirt
resourceVersion: "1490"
uid: bc621d93-4910-4b1f-b3c8-f8f1f4e27a38
spec:
certificateRotateStrategy: {}
configuration:
developerConfiguration: {}
customizeComponents: {}
imagePullPolicy: IfNotPresent workloadUpdateStrategy: {}
$ kubectl -n kubevirt get pods
NAME READY STATUS RESTARTS AGE
virt-api-77f8d679fc-hntws 1/1 Running 0 49m
virt-controller-6689488456-4jtv8 1/1 Running 0 48m
virt-controller-6689488456-68hnz 1/1 Running 0 48m
virt-handler-psc4w 1/1 Running 0 48m

基本上就是預設的設定檔案,然後對應的 API, Controller 以及 Handler 都被創建出來處理後續的操作。

Virtctl

透過官方指令直接抓取對應版本的 virtctl

VERSION=$(kubectl get kubevirt.kubevirt.io/kubevirt -n kubevirt -o=jsonpath="{.status.observedKubeVirtVersion}")
ARCH=$(uname -s | tr A-Z a-z)-$(uname -m | sed 's/x86_64/amd64/') || windows-amd64.exe
echo ${ARCH}
curl -L -o virtctl https://github.com/kubevirt/kubevirt/releases/download/${VERSION}/virtctl-${VERSION}-${ARCH}
chmod +x virtctl
sudo install virtctl /usr/local/bin
-> % virtctl version
Client Version: version.Info{GitVersion:"v1.1.0-alpha.0", GitCommit:"67902ed9de43d7a0b94aa72b8fd7f48f31ca4285", GitTreeState:"clean", BuildDate:"2023-09-18T10:45:14Z", GoVersion:"go1.19.9", Compiler:"gc", Platform:"darwin/arm64"}
Server Version: version.Info{GitVersion:"v1.1.0-alpha.0", GitCommit:"67902ed9de43d7a0b94aa72b8fd7f48f31ca4285", GitTreeState:"clean", BuildDate:"2023-09-18T12:03:45Z", GoVersion:"go1.19.9", Compiler:"gc", Platform:"linux/arm64"}

'''info 官方文件有說明可以透過 kubectl krew 的平台來安裝 virtctl 指令,透過 kubectl krew install virt 來安裝並使用,但是目前並沒有支援 darwin-arm64 (MacOS M1/M2) '''

安裝 VM

透過官方示範檔案部署第一個 VM

$ kubectl apply -f https://kubevirt.io/labs/manifests/vm.yaml
virtualmachine.kubevirt.io/testvm created
$ kubectl get vm
NAME AGE STATUS READY
testvm 7s Stopped False

預設情況下,創建好 VM 並不代表 VM 已經啟動,這時候可以透過 virtctl 將該 VM 給運行起來

$ virtctl start testvm
VM testvm was scheduled to start

當 VM 啟動後,對應的 Pod 就會正式被部署到環境內

$ kubectl get pods -o wide

這時候來研究一下該 Pod 的一些架構

先透過 virtctl console testvm 登入後觀察一下 VM IP

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc pfifo_fast qlen 1000
link/ether 52:54:00:0c:00:55 brd ff:ff:ff:ff:ff:ff
inet 10.0.2.2/24 brd 10.0.2.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::5054:ff:fe0c:55/64 scope link
valid_lft forever preferred_lft forever
$ ip r
default via 10.0.2.1 dev eth0
10.0.2.0/24 dev eth0 src 10.0.2.2

IP 是 10.0.2.2 並且 Gateway 是 10.0.2.1 這時候進入到對應的 Pod 去觀察

$ kubectl exec -it virt-launcher-testvm-pnn4j -- bash
bash-5.1$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0@if14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default
link/ether 12:37:77:cf:6d:63 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 10.244.0.10/24 brd 10.244.0.255 scope global eth0
valid_lft forever preferred_lft forever
3: k6t-eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default qlen 1000
link/ether 02:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
inet 10.0.2.1/24 brd 10.0.2.255 scope global k6t-eth0
valid_lft forever preferred_lft forever
4: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc fq_codel master k6t-eth0 state UP group default qlen 1000
link/ether d6:0e:c5:6f:41:f1 brd ff:ff:ff:ff:ff:ff
bash-5.1$

這邊可以看到 Pod 上面的 k6t-eth0 是有 IP 10.0.2.1 同時可以看到下方有一個 tap0 的網卡,該網卡有設定 master k6t-eth0 因此可以推斷 k6t-eth0 是 Linux Bridge, tap0 則是 bridge 下的一個 Port,透過下列指令可以確認


bash-5.1$ ls /sys/class/net/k6t-eth0/brif
tap0
bash-5.1$ ls /sys/class/net/k6t-eth0/bridge/
ageing_time group_fwd_mask multicast_last_member_count multicast_query_response_interval nf_call_arptables root_port vlan_protocol
bridge_id hash_elasticity multicast_last_member_interval multicast_query_use_ifaddr nf_call_ip6tables stp_state vlan_stats_enabled
default_pvid hash_max multicast_membership_interval multicast_router nf_call_iptables tcn_timer vlan_stats_per_port
flush hello_time multicast_mld_version multicast_snooping no_linklocal_learn topology_change
forward_delay hello_timer multicast_querier multicast_startup_query_count priority topology_change_detected
gc_timer max_age multicast_querier_interval multicast_startup_query_interval root_id topology_change_timer
group_addr multicast_igmp_version multicast_query_interval multicast_stats_enabled root_path_cost vlan_filtering
bash-5.1$

k6t-eth0 底下有眾多 bridge 的設定,並且 brif 底下有 tap0,而實務上該 tap0 則是 kvm 創建 vm 後將其綁到 VM 內,因此會與 VM 內的 eth0 掛勾,可以想成是一條大水管,一邊進去另外一邊出來 看來詳細細節還是需要閱讀interface networks,似乎提供不同網路模式來達成不同功能,有空來玩看看彼此差異研究下實作細節。

[MacOS ]隨手筆記 Sed 與 Rename 的使用

作者 HungWei Chiu
2023年10月9日 08:00

刪除特定一行

sed '/^keywords:/d' input > output

刪除符合字串後的所有行數

sed '/^keywords/,$d' input > output

搭配 Find 達到大量修改所有檔案

統一刪除所有檔案

find . -type f -exec sed -i '' '/^authors:/d' {} +

Append 一行新的,換行要特別注意處理

find . -type f -exec sed -i '' '/^title/a\
authors: hwchiu\
' {} +

大量換名稱 https://hackmd.io/_uploads 變成 ./assets/

find *.md -type f -exec sed -i '' -e 's/https:\/\/hackmd\.io\/_uploads\//\.\/assets\//g' {} +

假設環境中有大量檔案需要改名稱,透過 rename 這個工具可以快速達成 譬如以下範例會先用正規表達式找尋所有符合的檔案名稱,接者將所有 read-notes 都改名為 reading-notes

rename 's/read-notes/reading-notes/' *read-notes-*

閱讀筆記: 「DevOps is a failure」

作者 HungWei Chiu
2022年6月29日 08:05

標題: 「DevOps is a failure」 類別: others 連結: https://leebriggs.co.uk/blog/2022/06/21/devops-is-a-failure

本篇文章作者從不同的角度來聊聊 DevOps 這個詞所代表的含義與實作意義

第一段作者先閒聊一下自己與 DevOps 詞的歷史,接者直接拋出一個作者長期好奇的觀點 「每個人都一定聽過 DevOps 是一個需要 Dev + Ops 共同參與的文化,但是作者自己參與的 DevOps 相關會議與討論,與會者大部分都是 Ops 人員,而不是那些真正參與開發的 Dev 人」

困惑時期

接者作者聊聊自身多年前的經驗,當時的開發團隊宣稱該團隊是「true devops」,同時不跟作者的維運團隊討論各種維運需求,這過程讓作者非常困惑,為什麼對方會說自己是 true devops 而又不找自己探討維運需求

作者後來與該開發團隊深聊後終於理解對方的意思,原來該開發團隊身兼開發與維運,該團隊使用 boto3 加上一些腳本來管理應用程式的生命週期,同時該團隊招募的 「full stack engineer」除了基本的後端技術外,也要對 AWS 有不少的熟悉與經驗。

對方的舉動更加困惑了作者,畢竟公司當時採取類似 Netflix 的方式來打造一個平台來讓所有開發者可以更輕鬆的去管理這些東西,而該開發團隊的舉動完全是反其道而行,到底為什麼要這麼做??

Pulumi 時期

當作者加入 Pulumi 時期時,作者開始使用一些知名工具如 GitLab, Terraform, Kubernetes 等工具來打造一個適合開發者的好用平台,然而每次想要將該平台給推廣給開發者時總是屢屢碰壁,總是會聽到如「你們的東西我不熟悉,我們還是習慣自己打造的工具」等類似說詞給打發掉。

作者接下來不斷嘗試說服開發團隊來使用自己打造的超級平台,鼓勵他們參加 DevOps 相關活動等各種方式,最終得到的還是類似「我們會按照我們自己的方式去嘗試~謝囉」之類的回覆

回顧

回顧過往,作者發現錯的是自己,一直以來相信的 DevOps 願景「讓 Ops 停止說 No, 讓 Dev 停止說"yo~ 今天部署吧"」 其實並不真實,作者認為 2022 的今天, DevOps 真正的含義是 「維運端的人努力說服開發人員按照維運人員的想法去做事情」

綜觀所有號稱跟 DevOps 有關的工具,你會發現幾乎都跟維運有關,每個跟 DevOps 有關的職缺列舉的技能也是滿滿的跟維運有關,對作者來說, DevOps 工程師跟過往的 System Admin 根本沒有太大分別,差異只有把「實體機房建置,上架機器」 v.s 「雲端機器建置,創立VM」而已。

文章內後半部分還有一些作者的想法,有興趣的可以閱讀完畢

本篇文章的想法滿有趣的,譬如作者提到想要幫開發團隊建立一個維運平台卻屢屢碰壁。

Ops 可能會覺得 Dev 一直不停重複打造工具沒有效率,不如使用自己打造的好平台 Dev 可能會覺得 Ops 不懂自己的需求,不如自己根據需求打造

同樣的敘述放到不同的規模,譬如

dev -> 5 人的專職開發團隊 dev -> 50 人的專職產品團隊

後者的角度也許會覺得團隊人數夠多,可以自己處理自己的需求,不需要仰賴公司提供一個萬能平台來處理一切,同時跨 team 合作可能還會使得很多事情效率低落,溝通成本過大。

歡迎留言探討你的想法

閱讀筆記: 「面試人生 - 設計一個簡易的分散式 Job Scheduler」

作者 HungWei Chiu
2022年6月27日 10:05

標題: 「面試人生 - 設計一個簡易的分散式 Job Scheduler」 類別: others 連結: https://medium.com/@raxshah/system-design-design-a-distributed-job-scheduler-kiss-interview-series-753107c0104c

本篇文章是一個面試技術文,探討開發一個類似 Job Scheduler 的專案時應該要如何去設計整體系統來完成需求,整體的架構基於 KISS 的原則,就是簡單為主。

整個流程原則基本上是

  1. 理解所有功能需求,包含功能面以及非功能面
  2. 瞭解可能的資料,根據規模大小與功能需求去推估出整體的規模大小
  3. 根據上述需求去規劃整體架構,其中規模大小有時候可以幫忙歸納出 ”讀寫“彼此的比例,這個會影響架構設計

功能面常見類型如

  1. 針對使用者提供何種操作,譬如遞交一個 Job, 列出所有 Job(當前,歷史)
  2. 每個 Job 的運行時間限制(ex, 5min),同時 Job 可以重複運行或是只運行一次等不同用法
  3. Job 本身也有優先度的設計,可以插隊等

非直接功能面如

  1. 可動態擴充規模來支援不同量級的需求
  2. 不論發生任何錯誤問題,使用者提交過的 Job 資訊都不能遺失
  3. 非同步設計,使用者遞交 Job 後就可以繼續別的工作, Job 完成後會主動通知使用者

有了功能面的需求,接下來就是數量大小的需求,譬如該架構要可以達到每秒 1000 個 Job(1000QPS), 從這些需求下去估算大概需要多少 CPU 以及多少 Memory,同時這些數量還可以滿足功能面的需求,譬如每個 Job 可以運行最多五分鐘。

所以也許會得到需要 10,000 台的 (16C) 機器,以及 100 台(16GB) 的機器來提供服務 基本的運算可以快速的理解該需求到底需不需要分散式的架構來處理,本文的範例資料量就很明顯是 scale up 沒有辦法完成的。

接下來就基於分散式的架構去設計相關架構,包含如

  1. Load Balancer
  2. Backend
  3. DB
  4. Job scheduler
  5. Job Executor
  6. Queue
  7. File system

逐步的規劃這些架構,並且探討彼此元件之間的溝通方式,這些方式是如何互相組合來滿足功能面/非功能面的需求

詳細需求可以參考全文

閱讀筆記: 「Cloudflare 06/21 災後報告」

作者 HungWei Chiu
2022年6月23日 08:05

標題: 「Cloudflare 06/21 災後報告」 類別: networks 連結: https://blog.cloudflare.com/cloudflare-outage-on-june-21-2022/

Cloudflare 官方文章詳細解釋 06/21/2022 當天到底發生什麼事情導致用戶受到影響,

這次的問題影響範圍概括了 Cloudflare 底下的 19 個資料中心,而很不幸的這 19 個資料中心剛好都是負責處理繁忙的全球流量,所以受到影響的用戶數量才會如此的多。 問題主因是網路設定的調整(有問題先猜BGP,不行再猜DNS...),整體的發生時間沒有非常長

  1. 06:27 UTC 問題發生
  2. 06:58 UTC 第一個資料中心修復並且上線
  3. 07:42 UTC 所有資料中心修復並且上線

背景

過去 18 個月以來, Cloudflare 致力於將其底下繁忙的資料中心進行架構改造來達成更為堅韌與彈性的網路架構,內部稱該架構為 Multi-Colo POP(MCP),影響的 19 個資料中心包含 Tokyo, Singapore ... 等

新架構最重要的部分就是其網路的部分是基於 Clos network 的架構設計,透過多層次的設計達成類似 mesh network 般的網路連結,該架構使得未來要維護與調整時能夠更輕鬆針對部分網路設備去處理而不會影響到整體網路(文章有架構圖片)。

問題

這次的問題主要跟 BGP 有關,Cloudflare 更新 BGP 的過程中有部分的 subnet 沒有順利的被傳遞出去,最終使得部分 subnet 的流量無法被順利轉發,進而導致整個網路問題。

文章內部有針對 BGP 問題更詳細的介紹,熟悉 BGP 的朋友可以花點時間看一下

反思

這次的問題影響範圍很廣,Cloudflare 針對下列三面向反思了一下問題的發生原因

Process

雖然嶄新的 MCP 架構其目的就是要提供更好更強的可用性,但是將舊架構給升級到新架構的過程中還是不夠完善。整體的更新流程直到最後一步驟才算是真正的接觸到全新 MCP 架構,這使得如果中間更新流程有錯必須要到最後才會觀察到 MCP 資料中心的網路炸了。 改善的方式則是未來的這些流程與自動化必須要加入更多關於 MCP 架構的測試來確保整體部署不會遇到預期外的結果。

Architecture

路由器的錯誤設定使得正確的路由規則沒有辦法順利的被傳達下去,最終使得網路封包無法如預期般地到達這些資料中心。 所以修復過程中就是要找出這些錯誤的設定並且修正,最終使得這些 BGP 能夠將正確的路由政策給轉發下去。

Automaiton

當前的自動化流程中有非常多的部分可以改進,這些改進有機會完全或是部分的去減緩問題發生時的影響程度。 有兩個目標是想要透過改善自動化機制達成的

  1. 減少問題發生時的影響範圍
  2. 減少問題發生時的修復時間

結論

CDN 不通先上社群看同業有沒有哀嚎,大概就可以知道是不是自己的問題了?

閱讀筆記: 「/proc/meminfo 與 free 指令的內容比較」

作者 HungWei Chiu
2022年6月3日 10:05

標題: 「/proc/meminfo 與 free 指令的內容比較」 類別: others 連結: https://access.redhat.com/solutions/406773

本篇文章要探討的是到底 /proc/meminfo 與 free 這個指令所列出來的 memory 相關資訊到底該怎麼匹配

雖然文章有特別強調主要是針對 RedHat Enterprise Linux 5,6,7,8,9,但是我認為大部分的 Linux 發行版的差異不會太大,畢竟整體都是來自於 Kernel 內的實作,我認為還是值得閱讀與理解。

對於大部分的系統管理員來說,勢必都有聽過 free 這個指令,該指令可以列出系統上當前的 memory 使用狀況,舉例來說通常會有 Total, Used, Free, Shared, Buffers, Cached 之類的欄位(不同版本可能會有些許差異)。 不熟悉的人可能會認為系統上的記憶體就只有“全部“,"使用中","閒置" 等三種類型,而實際上的記憶體處理遠比這些複雜,這也是為什麼 free 的輸出欄位會比較多的原因

除了 Free 指令外, Kernel 本身還有提供一個特殊的檔案位置讓使用者可以讀取當前的 memory 狀況,該位置為 /proc/memifno,其會提供如 MemTotal, MemFree, Buffers, Cached 等相關欄位

本文並不會針對每個欄位去探討實際上的意義,取而代之的是簡單的比對,透過幾個列表讓你清楚的知道 free 指令輸出的每個欄位要如何與 /proc/meminfo 去比較,要如何轉換等 特別要注意的是文章內有仔細地針對不同 RedHat Enterprise Linux 版本去分別探討,所以如果是 RedHat 系列的使用者更要好得閱讀並確保能夠理解自己當前使用版本的狀況

閱讀筆記: 「goss, 一個簡易且迅速的 server 驗證工具」

作者 HungWei Chiu
2022年6月1日 08:05

標題: 「goss, 一個簡易且迅速的 server 驗證工具」 類別: others 連結: https://github.com/aelsabbahy/goss

今天要介紹的是一個驗證工具 goss,該工具的目的非常簡單,讓系統管理員可以透過 YAML 的方式幫機器上的服務撰寫 Unit Testing 什麼情況會需要使用這類型工具?

舉例來說,當你今天部署了一個全新機器(手動/自動後),你安裝了下列軟體

  1. sshd
  2. nginx
  3. docker
  4. ....

同時你也根據需求事先創建了一些使用者,接者你想要驗證這些軟體與相關設定是否設定完成 最直覺的方式就是手動檢查,一個一個服務與設定人工檢查

而 goss 這套軟體的目的就是讓你用 YAML 的方式去撰寫你想要驗證的所有服務,可以用來驗證包含

  1. 使用者 (uid, gid, home, shell)
  2. Package: 系統是否有透過 rpm, de, pacman, apk 等安裝套件
  3. File: 檢查檔案資料夾是否存在
  4. Addr: 用來檢查 $IP:$Port 是否可以被存取
  5. Port: 用來檢查 $Port 是否有開啟
  6. DNS: 用來檢查是否可以解析特定 DNS
  7. Process: 檢查特定 Process 是否有開啟
  8. Mount: 檢查是 Mount Point 以及相關參數
  9. Kernel Param: 檢查 Kernel 參數
  10. ...等

Goss 除了基本用法外,也有人基於其概念往上疊加 dgoss,用來驗證 Docker 的運行狀態,還有類似的 dcgoss,針對 docker-compose 來使用。 當然目前也很多人會透過 Ansible 的方式來自動化部屬,而 Ansible 本身其實也有相關的測試框架可以用來測試部署結果,所以到底要用哪類型的工具 來驗證 Server 等級的狀態就根據團隊需求與現有流程而定,比較沒有一個獨大的工具用法。

閱讀筆記: 「如何提供專業 Code Review 意見」

作者 HungWei Chiu
2022年5月27日 08:05

標題: 「如何提供專業 Code Review 意見」 類別: others 連結: https://medium.com/@yar.dobroskok/how-to-review-the-code-like-a-pro-6b656101eb89

作者開門見山提到,如果團隊中沒有任何 code review 文化的話,請直接忽略這篇文章。 當團隊真的有 code review 的經驗時,才有機會透過本篇文章分享的一些概念來改善整個 code review 的流程,高效率低耗時。

作者認為一個好品質的 code review 能夠幫助團隊帶來下列好處

  1. 避免合併一些充滿 bug, 難讀, 無效率的程式碼到專案中
  2. 開發者可以互相分享彼此的知識
  3. 獲得關於實作上的各種意見
  4. 確保團隊內的 coding style 一致

為了讓上述概念可以充分的導入到團隊專案中,作者分享了一些自己常用的概念與招式

事先準備一份 Checklist 一個好的 review 流程就是要有一份檢查清單,這份清單上面描述的是每次程式碼合併都“必須”要符合的規則,同時也是團隊很重視的規則 這份清單沒有絕對標準,主要是根據團隊去思考哪些東西是最重要的,舉例來說

  1. Branch, Commit 內容與名稱是否符合規範
  2. Code 是否有足夠的可讀性
  3. Codesytle 以及命名規範是否符合團隊文化
  4. 資料夾/檔案結構是否符合團隊文化
  5. 是否有包含相關測試
  6. 文件是否有一起準備

這份清單的重點是只要列入那些被視為是非常必須且重要的項目就好,不然整個清單落落長其實意義也不高

盡可能的自動化上述檢查 準備好前述清單後,下一個步驟就是想辦法將上述清單規範給自動化,譬如

  1. 透過 linters 來檢查 codesytle
  2. 運行一些如 SonarQube, Codacy 等工具來幫忙檢查是否有潛在的低效率或是有漏洞的程式碼
  3. 透過相關框架運行自動化測試並且得到相關的覆蓋率報表

當有辦法自動化這些操作後,下一個步驟就是要思考什麼時候執行?

  1. 針對一些快速檢查,譬如 linter, beautifer 等工具,可以考慮整合到 pre-commit hook/ pre-push Git hook 等時間點運行 這樣就可以讓開發者快速檢查簡單錯誤
  2. 針對一些比較花時間的檢查,譬如分析工具,測試以及相關建置流程這些都可以放到 CI pipeline 去運行

一切都準備完畢後就可以將其整合到整個 git 工具中,譬如只有當 CI pipeline 通過的 PR 才有被人 review 的需求,如果連自動化測試都沒有辦法通過,那就是開發者的 責任要去將其完成,一切準備就緒後才要開始最後一步

  • 人工介入 review * 開始人工 review 時,因為前述自動化的過程已經幫忙檢查非常多的事項,所以這時候要專注的就是運作邏輯。 能的話作者建議 review 與其慢慢看 code 猜想不如直接跟開發者一起討論 review,可以避免來回溝通花費的無效時間 此外開發者也可以更清楚地去解釋所有實作的背後理由與考量。

作者也推薦採用 IDE 來進行 code review,很多 IDE 強大的功能都能夠幫助開發者更有效率地去檢視程式碼,譬如快速找到宣告點,被呼叫點以及整個資料結構的面貌等 這些都可以省下不少時間

最後最重要的是每次 PR 的大小不能太大,這點其實也是 Linux Kernel 內一直奉行的原則,過大的修改有太多檔案要看,同時也有更多可能潛在的不相容問題要注意 這對開發者與 reviewer 來說都是個沈重的負擔,因此能的話將修改以拆分成數個有意義的 PR 分別檢視會使得整體流程更講有效率,同時也可以避免 檔案太多時可能看不下去就直接無腦 +2 的蓋章行為

閱讀筆記: 「Tetragon, 基於 eBPF 的 Kubernetes 資安管理工具」

作者 HungWei Chiu
2022年5月23日 08:05

標題: 「Tetragon, 基於 eBPF 的 Kubernetes 資安管理工具」 類別: others 連結: https://isovalent.com/blog/post/2022-05-16-tetragon

Cillium 的開發團隊 isovalent 最近公布其內部一直使用的資安相關專案, Teragon (可愛的蜜蜂戰士)。

Teragon 底層是基於 eBPF 的技術,其目的就是讓你的 Kubernetes 於資安方面可以獲得超級強大的能力,包含

  1. 詳細的視覺化功能,讓你可以一目瞭然到底系統中各項資源的發生過程
  2. 動態強化,可以讓你透過 Kubernetes CRD, OPA, Json 等各種格式來描述相關規範,然後動態無縫的套入到你的 Kubernetes 叢集中

探討 Teragon 前,要先理解以前目前已知的相關解決方案有哪些,而這些解決方案又有什麼樣的優缺點,包含

  1. App Instrumentation
  2. LD_PRELOAD
  3. ptrace
  4. seccomp
  5. SELinux/LSM
  6. Kernel Module

上述六個方式都有各自的特點,這邊簡單敘述

App Instrumentation O 效率高,可以看到非常細部的資訊 X 程式碼需要修改,不夠透明 X 單純的視覺化,不能套入資安規則來防護應用程式 X 應用程式為主,不能理解整個系統的狀況

LD_PRELOAD (動態切換載入的 Library ) O 效率高 O 應用程式不需要修改 X 如果是 Static Llinking 的應用程式那就沒有用了 X 幾乎沒有什麼觀察性可言

ptrace (透過 kernel 提供的功能來檢視使用的 syscall) O 透明,應用程式不用修改 X 效能負擔比較高 X 應用程式有辦法偵測到自己目前被 ptrace 給監控 X 整體範圍只能針對 syscall(系統呼叫)

seccomp (可以過濾應用程式呼叫的 syscall) O 有效率,應用程式不需要修改 X 規則只能針對 syscall 去阻擋 X 沒有很好的視覺化方式

SELinux/LSM (Kernel 內建的 security 框架,可以針對存取去控制) O 有效率,應用程式不需要修改 O 可防 TOCTTOU 攻擊 X 針對 Contaienr/Kubernetes 的整合很有限 X 不容易擴充 X 要針對攻擊類型去設定

Kernel Module O 有效率,應用程式不需要修改 O 不用修改 Kernel 就可以擴充功能 X 不是每個環境都允許使用者去載入 kenrel Module X Module 有問題會打爆你的 Kernel X 沒辦法無縫升級,意味你升級功能的過程中必須要將kernel module給 uninstall ,然後重新安裝

上列六個解決方案有的只能檢視相關流程,有的只能設定規則去防護,但是就是沒有一個工具可以全面處理,而基於 eBPF 實作的 Tetragon 則是一個 能夠提供兩項功能的全新解決方案。

首先資安防護方面, Tetragon 採取的是更底層的概念,不去探討特定的 CVE 操作手法,取而代之的是從幾個常見的攻擊方式來防禦。 假如有任何應用程式有不預期的下列行為,就可以直接將該 Process 移除

  1. 使用到不該使用的 capability
  2. 使用到不該使用的 linux namespace
  3. 使用到不該使用的 binary
  4. 看到不該出現的 Pid
  5. ...

這些規則都可以透過 Kubernetes CRD 來描述,當這些規則被送到 Kubernetes 後,相關的 Controller 就會將規則給轉換後續讓 eBPF 來處理 此外因為 eBPF 以及 kprobe 的架構,Tetragon 能夠看到非常多 kernel 的資源存取與操作,譬如

  1. syscall(系統呼叫)
  2. Virtual FS
  3. TCP/IP
  4. namespace
  5. Storage
  6. Network

Tetragon 收集上列不同資訊的資料後進行二次處理,透過精美的網頁來顯示系統中的各種資訊,這些資訊可以提供包含

  1. 哪些 Pod 一直存取 /etc/passwd, 採用何種方式存取 /etc/passwd
  2. 特定 Pod 中對外的網路流量資訊,從封包內容到用什麼指令去存取都可以看光光
  3. ...

eBPF 的應用愈來愈多,而目前看起來 isovalent 更是 Kubernetes 生態系中的領頭羊,雖然不確定未來是否能夠被廣泛採用,但是至少這方面還沒有看到其他解決方案有這麼積極的基於 eBPF 來開發 有餘力的話花點時間學習一下 eBPF 的概念可以加強自己對於這類型文章的速度與理解度

閱讀筆記: 「提升 DevOps 技術的免費書籍」

作者 HungWei Chiu
2022年5月9日 08:05

標題: 「提升 DevOps 技術的免費書籍」 類別: others 連結: https://vladimir-mukhin.medium.com/free-books-that-will-boost-your-devops-game-to-the-next-level-5940482b0f96

本篇文章的重點很簡單

  1. 閱讀書籍提升對於 DevOps 領域的掌握度
  2. 所有書籍都是免費

這邊節錄文章中列出的所有書籍

  1. Kubernetes Up & Running — Dive into the Future of Infrastructure Kubernetes 從 2014 發行以來的八個年頭席捲全世界,作為一個 DevOps 不論你當下的環境適不適合使用 Kubernetes,你都必須要瞭解到底這個容器管理平台的魅力是什麼 為什麼可以打趴眾多競爭者成為所有容器管理平台的主要首選。 本書從開發者(Dev)以及維運者(Ops)的角度來看到底 Kubernetes 是如何提升整體工作的效率,速度與整體的靈活度

  2. Designing Distributed Systems — Patterns and Paradigms for Scalable, Reliable Services 這本由 Brendan Burns 所攥寫的書籍探討了分散式系統架構上幾個常見的設計模式,事實上這些設計模式有些都可以於 Kubernetes 的設計與用法中反覆發現 所以花點時間去研究一下大師所分享的分散式系統模式的設計理念,對於未來去學習理解新系統,或是設計一套系統都會有所幫助

  3. 97 Things Every Cloud Engineer Should Know — Collective Wisdom from the Experts 這本有紅帽所發行的免費書籍,書中收集了眾多資深雲端工程師的經驗,列舉了 97 個每個雲端工程師都應該要知道的事情,這 97 項包含很多東西,譬如 資料,自動化,網路,公司文化,個人發展,軟體開發以及雲端預算評估等眾多常見議題

  4. Linux — Notes for Professionals

  5. Production Kubernetes — Building Successful Application Platforms

  6. Git — Notes for Professionals

  7. Automate The Boring Stuff with Python — Practical Programming For Total Beginners

剩下的書本也都非常有趣,大家有需要時可以閱讀下列書籍

❌
❌