k0sにおけるKnative Serving ¶
公開日: 2023-03-28, 更新日: 2024-01-17
k0sにおけるKnative Serving¶
著者: Naveenraj Muthuraj、アルバータ大学の大学院生
この作業は、最小限のリソースでk0sにknative servingをデプロイする試みです。1つのCPUと1GBのRAMを試してみましょう。
このドキュメントは3つのセクションで構成されています。最初のセクションでは、knative servingとk0sに必要なリソースをキャプチャします。2番目のセクションでは、Knativeとk0sが実際に使用しているリソースを監視して、k0s（エッジ）ノードのサイズを決定します。最後に、1つのCPUと1.5GBのRAMを持つk0sノードに、リソース要求/制限を減らしたknative servingをインストールします（なぜ1.5GB？、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 |
| autoscaler-hpa | 30m | 300m | 40Mi | 400Mi |
| コントローラー | 100m | 1 | 100Mi | 1000Mi |
| default-domain* | 100m | 1 | 100Mi | 1000Mi |
| ドメインマッピング | 30m | 300m | 40Mi | 400Mi |
| domainmapping-webhook | 100m | 500m | 100Mi | 500Mi |
| net-kourier-controller | <なし> | <なし> | <なし> | <なし> |
| webhook | 100m | 500m | 100Mi | 500Mi |
| 合計 | 860m | 5600m | 640Mi | 5400Mi |
注
* default-domainはジョブであり、ジョブが完了するとリソースは解放されます。
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で使用されるメモリ - 558m
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
得られた結果は、ニールによる実験と比較可能です[1]
Knative + k0sのデフォルトリソース要件¶
概算によるVMに必要な最小リソース
| リソース | CPU | メモリ |
|---|---|---|
| k0s | 30m | 558 + 208（スワップ） |
| knative-serving | 860m | 640Mi |
| 合計 | 890m | 1406Mi |
リソース使用量分析¶
Knativeのリソース監視¶
次に、2つのCPUと2GBのメモリを持つVMを作成してknative servingを動作させ、各コンポーネントのメトリクスをキャプチャできるようにします。リソースが完全に利用されていない場合は、各Knativeコンポーネントの最小要件を減らすことができます。
Vagrantではデフォルトで1 CPU VMになるため、1.5 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
1つのKnativeサービスがアイドル状態の場合の、完全にインストールされたKnative servingのリソース分析
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.4GBのメモリ使用量は、メモリを減らす余地がほとんどないことを意味します。
次に、リソース要求と制限を50%削減してみて、問題が発生するかどうかを確認してみましょう。
k0sにおけるKnative¶
エッジのようなノードの作成¶
これを行うには、1つのCPUと1.5GBのメモリを備えた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.5GBの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_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コンポーネントのデプロイメントファイルを編集します。例：CPUリクエスト/制限の元の値が100mの場合、それを50mに減らし、メモリについても同様に行います。
50%の削減はランダムに見えるかもしれませんが、デフォルトファイルをインストールしようとしたときに、CPUが不足しているために一部のポッドが起動しませんでした。890ミリコアの最小リクエスト（Knative + k0sのデフォルトリソース要件を参照）は、一部のポッドが十分なCPUを見つけられなかった理由を説明しています。これは、BaseOS + k0sが110mを超える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
Say Hello Edge!¶
通常の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日 ブログ