k0s 中的 Knative Serving ¶
發佈於:2023-03-28, 修訂於:2024-01-17
k0s 中的 Knative Serving¶
作者:Naveenraj Muthuraj,亞伯達大學研究生
這項工作旨在以最少的資源在 k0s 中部署 knative serving。我們嘗試使用 1 個 CPU 和 1 GB RAM。
本文檔分為三個章節。在第一章節中,我們捕獲 knative serving 和 k0s 所需的資源。在第二章節中,我們監控 Knative 和 k0s 實際使用的資源,以確定我們的 k0s(邊緣)節點的大小。最後,我們以減少的資源請求/限制將 knative serving 安裝到具有 1 個 CPU 和 1.5 GB RAM 的 k0s 節點(為什麼是 1.5 GB?,請參閱Knative + k0s 資源使用情況)
如果您只想在 k0s 中安裝 knative serving,可以直接跳至 k0s 中的 Knative 安裝章節。
資源需求分析¶
在本章節中,我們將確定 knative-serving 和 k0s 所需的預設安裝資源需求。
Knative Serving 預設資源需求¶
knative-serving
kubectl get pods -n knative-serving -o custom-columns="NAME:metadata.name,CPU-REQUEST:spec.containers[*].resources.requests.cpu,CPU-LIMIT:spec.containers[*].resources.limits.cpu,MEM-REQUEST:spec.containers[*].resources.requests.memory,MEM_LIMIT:spec.containers[*].resources.limits.memory"
NAME CPU-REQUEST CPU-LIMIT MEM-REQUEST MEM_LIMIT
activator-7499d967fc-2npcf 300m 1 60Mi 600Mi
autoscaler-568989dd8c-qzrhc 100m 1 100Mi 1000Mi
autoscaler-hpa-854dcfbd44-8vcj8 30m 300m 40Mi 400Mi
controller-76c798ffcb-k96sz 100m 1 100Mi 1000Mi
default-domain-nwbhr 100m 1 100Mi 1000Mi
domain-mapping-7748ff49d4-29mg4 30m 300m 40Mi 400Mi
domainmapping-webhook-755d864f5c-dsc7j 100m 500m 100Mi 500Mi
net-kourier-controller-79c998474f-svzcm <none> <none> <none> <none>
webhook-8466d59795-d8zd8 100m 500m 100Mi 500Mi
kourier-system
kubectl get pods -n kourier-system -o custom-columns="NAME:metadata.name,CPU-REQUEST:spec.containers[*].resources.requests.cpu,CPU-LIMIT:spec.containers[*].resources.limits.cpu,MEM-REQUEST:spec.containers[*].resources.requests.memory,MEM_LIMIT:spec.containers[*].resources.limits.memory"
NAME CPU-REQUEST CPU-LIMIT MEM-REQUEST MEM_LIMIT
3scale-kourier-gateway-5f9f97b454-rqkgh <none> <none> <none> <none>
總計
元件 | CPU 請求 | CPU 限制 | 記憶體請求 | 記憶體限制 |
---|---|---|---|---|
啟動器 | 300m | 1 | 60Mi | 600Mi |
自動調整器 | 100m | 1 | 100Mi | 1000Mi |
自動調整器-hpa | 30m | 300m | 40Mi | 400Mi |
控制器 | 100m | 1 | 100Mi | 1000Mi |
預設網域* | 100m | 1 | 100Mi | 1000Mi |
網域對應 | 30m | 300m | 40Mi | 400Mi |
網域對應-webhook | 100m | 500m | 100Mi | 500Mi |
net-kourier-controller | <無> | <無> | <無> | <無> |
webhook | 100m | 500m | 100Mi | 500Mi |
總計 | 860m | 5600m | 640Mi | 5400Mi |
注意
* 預設網域是一個工作,一旦工作完成,資源將會釋放
k0s 預設資源需求¶
預設 k0s 安裝使用的資源
記憶體使用情況
vagrant@vagrant:~$ free -m
total used free shared buff/cache available
Mem: 971 558 61 0 351 268
Swap: 1941 208 1733
k0s 使用的記憶體 - 558 m
CPU 使用情況
top - 01:55:58 up 2:27, 1 user, load average: 0.70, 0.42, 0.43
Tasks: 110 total, 1 running, 109 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.8 us, 0.7 sy, 0.0 ni, 97.5 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 971.2 total, 60.9 free, 547.8 used, 362.5 buff/cache
MiB Swap: 1942.0 total, 1734.9 free, 207.1 used. 280.4 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1222 kube-ap+ 20 0 1203728 261064 30408 S 1.7 26.2 4:12.43 kube-apiserver
1213 kube-ap+ 20 0 740108 29256 6032 S 1.0 2.9 2:13.01 kine
1376 kube-ap+ 20 0 776892 54388 20112 S 1.0 5.5 1:52.61 kube-controller
602 root 20 0 806420 44088 20408 S 0.7 4.4 0:53.60 k0s
1283 root 20 0 779664 48132 19672 S 0.7 4.8 2:24.79 kubelet
5 root 20 0 0 0 0 I 0.3 0.0 0:00.29 kworker/0:0-events
347 root 19 -1 56140 14772 14244 S 0.3 1.5 0:04.18 systemd-journal
1282 root 20 0 757300 24652 7024 S 0.3 2.5 0:44.78 containerd
1372 kube-sc+ 20 0 765012 24264 13596 S 0.3 2.4 0:16.83 kube-scheduler
1650 root 20 0 757488 14860 8068 S 0.3 1.5 0:03.90 kube-p
k0s 使用 3% ~ 30m?
BaseOS 使用的資源
記憶體
vagrant@vagrant:~$ free -m
total used free shared buff/cache available
Mem: 971 170 502 0 297 668
Swap: 1941 0 1941
CPU
top - 02:02:20 up 2 min, 1 user, load average: 0.04, 0.06, 0.02
Tasks: 95 total, 1 running, 94 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.3 us, 0.3 sy, 0.0 ni, 99.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 971.2 total, 502.7 free, 170.8 used, 297.8 buff/cache
MiB Swap: 1942.0 total, 1942.0 free, 0.0 used. 670.7 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
606 root 20 0 727828 49984 20012 S 1.3 5.0 0:02.68 snapd
獲得的結果與 Neil 的實驗 [1] 相當
Knative + k0s 預設資源需求¶
粗略估計 VM 所需的最小資源
資源 | CPU | 記憶體 |
---|---|---|
k0s | 30m | 558 + 208(交換) |
knative-serving | 860m | 640Mi |
總計 | 890m | 1406Mi |
資源使用情況分析¶
Knative 資源監控¶
現在,讓我們建立一個具有 2 個 CPU 和 2GB 記憶體的 VM,使 knative serving 運作,以便我們可以捕獲每個元件的指標。如果資源未充分利用,我們可以降低每個 knative 元件的最低需求。
建立具有 1.5 個 CPU 的 VM!在 vagrant 中預設為 1 個 CPU VM
# knative core components
vagrant@vagrant:~$ sudo k0s kubectl get pods -n knative-serving
NAME READY STATUS RESTARTS AGE
autoscaler-86796dfc97-2q6b2 1/1 Running 0 19m
controller-7cd4659488-sqz5q 1/1 Running 0 19m
activator-6f78547bf7-xp5jh 1/1 Running 0 19m
domain-mapping-856cc965f5-jv4g9 1/1 Running 0 19m
domainmapping-webhook-6dc8d86dbf-mg8j8 1/1 Running 0 19m
webhook-d9c8c747d-fwhst 1/1 Running 0 19m
net-kourier-controller-54999fc897-st6tn 1/1 Running 0 12m
default-domain-qpvfp 1/1 Running 0 9m48s
# kourier
vagrant@vagrant:~$ sudo k0s kubectl get pods -n kourier-system
NAME READY STATUS RESTARTS AGE
3scale-kourier-gateway-9b477c667-2hdt2 1/1 Running 0 15m
# 1 knative service
vagrant@vagrant:~$ sudo k0s kubectl get ksvc
NAME URL LATESTCREATED LATESTREADY READY REASON
hello http://hello.default.svc.cluster.local hello-00001 hello-00001 True
vagrant@vagrant:~$ sudo k0s kubectl get pods
NAME READY STATUS RESTARTS AGE
hello-00001-deployment-66ddff5b59-jbn6x 2/2 Running 0 84s
完全安裝的 knative serving 和一個 knative 服務(閒置狀態)的資源分析
vagrant@vagrant:~$ sudo k0s kubectl top node
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
vagrant 166m 8% 1341Mi 71%
vagrant@vagrant:~$ sudo k0s kubectl top pod --all-namespaces
NAMESPACE NAME CPU(cores) MEMORY(bytes)
default hello-00001-deployment-66ddff5b59-jbn6x 1m 8Mi
knative-serving activator-6f78547bf7-xp5jh 2m 21Mi
knative-serving autoscaler-86796dfc97-2q6b2 5m 19Mi
knative-serving controller-7cd4659488-sqz5q 5m 27Mi
knative-serving default-domain-6mknr 1m 7Mi
knative-serving domain-mapping-856cc965f5-jv4g9 2m 13Mi
knative-serving domainmapping-webhook-6dc8d86dbf-mg8j8 7m 15Mi
knative-serving net-kourier-controller-54999fc897-st6tn 6m 37Mi
knative-serving webhook-d9c8c747d-fwhst 9m 16Mi
kourier-system 3scale-kourier-gateway-9b477c667-2hdt2 4m 17Mi
kube-system coredns-7bf57bcbd8-b22j4 3m 16Mi
kube-system kube-proxy-pm4ht 1m 13Mi
kube-system kube-router-vdqtv 1m 19Mi
kube-system metrics-server-7446cc488c-zxdxg 5m 18Mi
Knative + k0s 資源使用情況¶
粗略估計 VM 使用的最小資源
資源 | CPU | 記憶體 |
---|---|---|
k0s + knative-serving | < 160m | < 1406Mi |
從這個初步結果來看,我們似乎可以減少 CPU 數量,但約 1.4 GB 的記憶體使用率意味著減少記憶體的空間不大。
現在讓我們嘗試將資源請求和限制減少 50%,看看是否會遇到任何問題。
k0s 中的 Knative¶
建立類似邊緣的節點¶
為此,我們將使用具有 1 個 CPU 和 1.5 GB 記憶體的 vagrant VM。
Vagrantfile
Vagrant.configure("2") do |config|
config.vm.define "k0s"
config.vm.box = "bento/ubuntu-22.04"
config.vm.provider "virtualbox" do |v|
v.memory = 1500
v.cpus = 1
v.name = "k0s"
end
end
vagrant up
vagrant ssh k0s
安裝 k0s¶
# Download k0s
curl -sSLf https://get.k0s.sh | sudo sh
# Install k0s as a service
sudo k0s install controller --single
# Start k0s as a service
sudo k0s start
# Check service, logs and k0s status
sudo k0s status
# Access your cluster using kubectl
sudo k0s kubectl get nodes
vagrant@vagrant:~$ sudo k0s kubectl get nodes
E0318 07:24:18.366073 2692 memcache.go:255] couldn't get resource list for metrics.k8s.io/v1beta1: the server is currently unable to handle the request
E0318 07:24:18.381532 2692 memcache.go:106] couldn't get resource list for metrics.k8s.io/v1beta1: the server is currently unable to handle the request
E0318 07:24:18.387961 2692 memcache.go:106] couldn't get resource list for metrics.k8s.io/v1beta1: the server is currently unable to handle the request
E0318 07:24:18.391539 2692 memcache.go:106] couldn't get resource list for metrics.k8s.io/v1beta1: the server is currently unable to handle the request
NAME STATUS ROLES AGE VERSION
vagrant Ready control-plane 61s v1.26.2+k0s
我們已經可以看到在 1 個 CPU 和 1.5 GB RAM 中執行 k0s 的效果。
沒有任何其他安裝的 k0s 指標
vagrant@vagrant:~$ sudo k0s kubectl top node
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
vagrant 39m 3% 959Mi 71%
安裝 Metallb 以進行負載平衡¶
sudo k0s kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.13.9/config/manifests/metallb-native.yaml
定義要指派給負載平衡器服務的 IP。
ip_pool.yaml
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
name: first-pool
namespace: metallb-system
spec:
addresses:
- 192.168.10.0/24
宣告服務 IP(第 2 層設定)
l2_ad.yaml
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
name: example
namespace: metallb-system
spec:
ipAddressPools:
- first-pool
建立 MatalLB 資源
sudo k0s kubectl apply -f ip_pool.yaml
sudo k0s kubectl apply -f l2_ad.yaml
建立自訂 knative 部署檔案¶
透過將資源減少到原始值的 50%,來編輯所有 knative serving 元件的部署檔案。例如:如果 100m 是 CPU 請求/限制的原始值,我們將其減少到 50m,記憶體也是如此。
雖然減少 50% 可能看起來是隨機的,但當我嘗試安裝預設檔案時,由於 CPU 不足,有些 Pod 沒有啟動。890 毫核心的最小請求(請參閱Knative + k0s 預設資源需求)解釋了為什麼有些 Pod 找不到足夠的 CPU,因為 BaseOS + k0s 可能使用超過 110 m 的 CPU (1000 - 890)。
因此,在監控資源使用情況(請參閱Knative + k0s 資源使用情況)並旨在將所有內容放入 1 個 CPU 時,將資源請求/限制減少 50% 是一個安全的選擇。
您可以使用我已建立的具有減少資源的部署檔案進行下一步。
安裝自訂 knative 部署檔案¶
# crd.yaml
sudo ks0s kubectl apply -f https://gist.githubusercontent.com/naveenrajm7/865756eaf07631c82dcd42278d02d105/raw/f94b4be95a40b5210ed6647c692235d60cebd83d/serving-crds.yaml
# core
sudo k0s kubectl apply -f https://gist.githubusercontent.com/naveenrajm7/6e67e288a3b29b5e7c8b3969d76dca27/raw/0269701bf5331e2b037ec582bfe09c8818cd8e27/serving-core.yaml
# networking
sudo k0s kubectl apply -f https://gist.githubusercontent.com/naveenrajm7/227c4c80a445a373a825f488605d9b1d/raw/ddceae84d378fd600c2115ae0e729e03f7e27a76/kourier.yaml
# Check Load balancer
sudo k0s kubectl --namespace kourier-system get service kourier
# before DNS , you should have external IP (via MetalLB)
# dns
sudo k0s kubectl apply -f https://gist.githubusercontent.com/naveenrajm7/0b8f36752b0246ac680913580a756ed0/raw/ffb00218395c7421332b8d251d8b02b05f5a94ad/serving-default-domain.yaml
檢查 knative-serving 的元件
vagrant@vagrant:~$ sudo k0s kubectl get pods -n knative-serving
NAME READY STATUS RESTARTS AGE
autoscaler-84445c7b8f-f8nwq 1/1 Running 0 37m
activator-5f59946cc4-dsx6w 1/1 Running 0 37m
controller-67cc995548-ncvtw 1/1 Running 0 37m
domainmapping-webhook-57946bc655-vrl68 1/1 Running 0 37m
domain-mapping-5b485cdb5-fqt89 1/1 Running 0 37m
webhook-5c8c986896-f5z8w 1/1 Running 0 37m
net-kourier-controller-6c89f976bf-4w579 1/1 Running 0 7m25s
default-domain-nghzp 0/1 Completed 0 17s
向邊緣說哈囉!¶
安裝慣用的 hello knative 服務
hello.yaml
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: hello
spec:
template:
metadata:
annotations:
autoscaling.knative.dev/minScale: "1"
spec:
containers:
- image: ghcr.io/knative/helloworld-go:latest
env:
- name: TARGET
value: "Edge!!"
# create knative service
vagrant@vagrant:~$ sudo k0s kubectl apply -f hello.yaml
# Check if service is running
vagrant@vagrant:~$ sudo k0s kubectl get ksvc
NAME URL LATESTCREATED LATESTREADY READY REASON
hello http://hello.default.192.168.10.0.sslip.io hello-00001 hello-00001 True
# Visit service
vagrant@vagrant:~$ curl http://hello.default.192.168.10.0.sslip.io
Hello Edge!!
讓我們將 knative 帶到邊緣。
資源:¶
-
Neil Cresswell, 比較 K0s vs K3s vs Microk8s 的資源消耗, 2022 年 8 月 23 日 部落格