今度はk3sでございます。
以前、kubeadmを使用してKubernetesを作っておりましたが、いろいろありまして結局のところスタンドアロン構成に戻してみたりした時期がありました。が、リソース集約を考えたときにやっぱりKubernetesが便利だったなーというのと、YAML記法を忘れそうでちょいと自分に心配だったのがありまして、小さなクラスタを再度構成することにしました。
当時のKubernetesも好きだったんですが、何しろ重い。Kubernetes自体の負荷がかなりでかいのです。オートヒーリングなんかは目も当てられないぐらいに処理が重く、それ故にまともに機能しないことが多かったりで。そこで見つけたのがk3sでございます
とにかく軽い
k3sのURLは以下の通りです。
さてこのk3s、Lightweight Kubernetesって書かれてるように、システム要件が非常にリーズナブルで、Kubernetesそれ自身の負荷がだいぶ低いです。加えて、シングルバイナリーで構成されていることもあって、プロセスが散らばってないのがうれしいポイントです。
まずOSを好みに従いインストールし、パッケージをアップデートした後で上記リンクにあるワンライナーのシェルコマンドを打ち込めばMaster/Worker共にインストール＆セットアップまで一通り完了してしまいます。
- CNIにはFlannelが使用されているようです。よって、コンテナネットワークは1セグメントの巨大なL2ネットワークで構成される
- コンテナを動かすソフトウェアはContanerdを使用するようです。Dockerとどのあたりが違うのか・・・とか、その辺りは私自身よくわかってません・・
- 私が導入したk3sはKubernetes v1.16ベースのものだったようです。知らぬうちにいろいろ機能やYAMLで宣言するAPIなどが変わっていてかなーり振り回されました。
# kubectl get nodes NAME STATUS ROLES AGE VERSION blackbeans.bluecore.net Ready master 6d3h v1.16.2-k3s.1 favabeans.bluecore.net Ready <none> 6d2h v1.16.2-k3s.1 soy.bluecore.net Ready <none> 6d2h v1.16.2-k3s.1
上記のように、今回は3台のノードを構成し、1Master/2Worker構成にしました。
Metrics-Server導入でハマる・・
Kubernetesの負荷を確認する際、以前はKube dashboardを使ったり、prometheusを使ったりしてたのですが、コマンドでさっと見れなかったものかなぁ？と情報を探してたらこんなコマンドがあるそうで。
- kubectl top node
- kubectl top pods
さっそく実行してみようじゃないか！と思って実行したらエラーが返ってくるでやんの。
さらに調べてみると「metrics-server」なるものが必要そう。
なるほど、これ入れるのか、じゃぁいけそうだ！と思って取り組み、それが完了したのは開始してから5時間後のことでした・・・・Orz
Gitで拾う
まずはお約束というか、Gitを使って一通りの構成情報を拾います。
git clone https://github.com/kubernetes-incubator/metrics-server
構成ファイルの修正
続いて、以下のファイルを変更します。(コンフィグは長時間格闘の末にたどり着いたものになります・・)
metrics-server/deploy/1.8+/metrics-server-deployment.yaml
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: metrics-server
namespace: kube-system
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: metrics-server
namespace: kube-system
labels:
k8s-app: metrics-server
spec:
selector:
matchLabels:
k8s-app: metrics-server
template:
metadata:
name: metrics-server
labels:
k8s-app: metrics-server
spec:
serviceAccountName: metrics-server
volumes:
# mount in tmp so we can safely use from-scratch images and/or read-only containers
- name: tmp-dir
emptyDir: {}
containers:
- name: metrics-server
image: gcr.io/google-containers/metrics-server:v0.3.3
command:
- /metrics-server
- --metric-resolution=30s
- --requestheader-allowed-names=aggregator
- --kubelet-insecure-tls
- --kubelet-preferred-address-types=InternalIP,Hostname,InternalDNS,ExternalDNS,ExternalIP
args:
- --cert-dir=/tmp
- --secure-port=4443
resources: {}
ports:
- name: main-port
containerPort: 4443
protocol: TCP
securityContext:
readOnlyRootFilesystem: true
runAsNonRoot: false
imagePullPolicy: Always
volumeMounts:
- name: tmp-dir
mountPath: /tmp
hostNetwork: true
dnsPolicy: ClusterFirst
上記、強調させてみるとそれほど修正箇所は多くないんですが、本当に試行錯誤の連続でした。特にきつかったのは「runAsNonRoot」と「hostNetwork」の二点でした。後日こうした設定内容については詳細が書けたらなと思っています。
デプロイメント開始
修正が終わったら以下コマンドで必要リソースが構成され、コンテナが動き出します。
# kubectl apply -f metrics-server/deploy/1.8+/
これでmetrics-serverコンテナが構成され、起動するようになります。
# kubectl top node NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% blackbeans.bluecore.net 114m 1% 1239Mi 15% favabeans.bluecore.net 214m 3% 3346Mi 57% soy.bluecore.net 36m 0% 806Mi 13% # kubectl top pods --all-namespaces NAMESPACE NAME CPU(cores) MEMORY(bytes) default database-sv-68d58cb44b-ptq4h 4m 2897Mi default redis-sv-6654666886-hhtjg 3m 10Mi kube-system coredns-57d8bbb86-gdt7n 4m 14Mi kube-system local-path-provisioner-58fb86bdfd-tllgq 44m 13Mi kube-system metrics-server-897767cd9-vtr59 1m 15Mi kube-system svclb-traefik-7s595 0m 3Mi kube-system svclb-traefik-dv872 0m 2Mi kube-system svclb-traefik-qnrr6 0m 2Mi kube-system traefik-65bccdc4bd-nglz9 6m 25Mi
misskey用に動かしているDBサーバのメモリ使用量が半端ないですが、比較的リソースには余裕をもって動かせているようです。現状RedisとPostgreSQLしか動かしてないんですが、もう少しアプリケーションコンテナを動かそうかねーなどと考えています。