跳至內容

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
BaseOS 使用的記憶體 170

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 
BaseOS 在閒置狀態下使用的 CPU 為 0.7%

獲得的結果與 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 以進行負載平衡

使用 Metallb 原生安裝 - 用於裸機

sudo k0s kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.13.9/config/manifests/metallb-native.yaml

為負載平衡器服務設定 IP 位址

定義要指派給負載平衡器服務的 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 帶到邊緣。

資源:

  1. Neil Cresswell, 比較 K0s vs K3s vs Microk8s 的資源消耗, 2022 年 8 月 23 日 部落格

  2. k0s 快速入門指南

  3. knative 文件

  4. MetalLB

我們使用分析和 Cookie 來了解網站流量。您使用我們網站的資訊將與 Google 分享以達到該目的。了解更多。