先日構築しましたおうちクラスタ。
クラウド・サービス・プロバイダの提供するKubernetesは、色々と付加価値がついた状態で使用できますが、オンプレミスは色々と足らないものがあります。(ミリタリーグレードなのに、ホームメイド＆ハンドメイド的な何か
筆者はクラスタの知識が無いのですが、まあ足りないものをなんとかしながら、得られた知見を記録させて頂こうと思います(誰でも最初は初心者～
よって、この記事は書きかけで、追々書き足させて頂く予定になります。
目次
オンプレミスKubernetes設定覚書
例によって、コピペ用のコマンド覚書です。
リソース一覧情報取得
デプロイ共通で、よく使用すると思われるものです。
# クラスタ情報
kubectl cluster-info
# ノード一覧
kubectl get nodes
kubectl get nodes -o wide
# 名前空間
kubectl get ns
# デプロイ一覧
# -A は--all-namespacesすべての名前空間を表示
kubectl get deployments -A
kubectl get deployments -A -o wide
# ポッド一覧
kubectl get pods -A
kubectl get pods -A -o wide
# サービス一覧
kubectl get services -A
kubectl get services -A -o wide
# ぜんぶ
kubectl get all -Ahelmのインストール
※arm64版のインストールになります。
curl -o https://get.helm.sh/helm-v3.12.2-linux-arm64.tar.gz -o helm-v3.12.2-linux-arm64.tar.gz
tar zxvf helm-v3.12.2-linux-arm64.tar.gz
sudo mv linux-arm64/heml /usr/local/bin
helm repo add stable https://charts.helm.sh/stablehelm本体のインストールは、こちらの方法で大丈夫な気がします。
Kubesprayでhelmをインストールしようとしましたが、どうもFedora CoreOSは対応していないようです。Fedora Linuxはスクリプトがちゃんとありました。Fedora CoreOSの場合は手動でインストールしましょう。
helmによるwordpressのインストール
bitnamiさんのchartはこちらの情報から。
arm64をサポートしているかどうかは、dockerhubで調べる必要があるそうです。bitnamiさんのイメージを検索する感じです
helm install \
my-release \
--set wordpressUsername=admin \
--set wordpressPassword=p@ssw0rd \
--set mariadb.auth.rootPassword=secretp@ssw0rd \
oci://registry-1.docker.io/bitnamicharts/wordpresswordpressコンテナ本体がうまく動かなかったのですが、それはhelmやチャートの問題ではありませんでした。
下記のkubesprayの設定を調整したところ、動くようになりました。
- nodelocaldnsがクラッシュしないように、kubesprayクラスタ構築時にresolvconf_mode=noneを設定
- ネットワークプラグインにFlannel使用
- ロードバランサにMetalLBを使用。こちらもkubesprayでプロビジョニング。
動かなかった原因は、kubesprayで構成したdns等の影響で、ポッド間の通信がホスト名でできなかったためでした。上記の設定調整で問題が解消されました。
helmとコンテナイメージのデバッグモード
–debugがhelmのデバッグ、–set image.debug=trueは、コンテナのデバッグモードになります。
helm install my-release \
--set wordpressUsername=admin \
--set wordpressPassword=p@ssw0rd \
--set mariadb.auth.rootPassword=secretp@ssw0rd \
--debug --set image.debug=true \
oci://registry-1.docker.io/bitnamicharts/wordpressコンテナのデバッグモードは、helmのチャートがどのイメージを使用しているかにより異なります。bitnamiさんのチャートは、こちらのコンテナかと思います。
よって、–set image.debug=trueが有効かどうかは、そちらを見る必要がありそうです。
デバッグモード有効後、終了したポッドのログを見るオプションはこちらのようです。
kubectl logs -p nodelocaldns-7ggssデバッグモードのおかげで、wordpressが動かない理由がdnsのループの影響とわかりました。
Flannel
後述のMetalLBを使用したい場合、CalicoよりもFannelのほうが設定の難易度が下がります。
Kubesprayでプロビジョニングする場合、playbookの実行時に環境変数を指定します。
# Ansibleのコントロール・ノードで実行
# Flannelを使用する環境変数追加
ansible-playbook -i inventory/mycluster/hosts.yaml --user core --become --become-user=root cluster.yml -e kube_network_plugin=flannelMetalLB
MetalLBを使用したい場合は、Kubesprayで設定してしまう方が良いのかもしれません。
# Ansibleのコントロール・ノードで実行
cd kubespray/inventory/mycluster
vi group_vars/k8s_cluster/k8s-cluster.yml
# strict arpを有効化
# kube_proxy_strict_arp: true
vi group_vars/k8s_cluster/addons.yml
# 下図のように変更
176行目付近を有効にしました。
metallb_enabled: true
metallb_speaker_enabled: "{{ metallb_enabled }}"
metallb_version: v0.13.9
metallb_protocol: "layer2"
# metallb_port: "7472"
# metallb_memberlist_port: "7946"
metallb_config:
address_pools:
primary:
ip_range:
- 192.168.xxx.61-192.168.xxx.70
auto_assign: true
pool1:
ip_range:
- 10.6.0.0/16
auto_assign: false
pool2:
ip_range:
- 10.10.0.0/16
auto_assign: false
layer2:
- primaryこちらの設定は、L2の場合のサンプルになります。
そもそも、クラスタの理解と技能が足りていないものですみません。
下記を調べながら進めております。
- PVの構築
- 分散ファイルシステム、CephFSによるstorageClassで問題なく構築できました。
- Kubesprayで構築した場合、ネットワークプラグインはCalicoが既定。
- BGPルータ向けのようです。
- 後述のMetalLBとの相性が。
- LoadBalancerにMetalLBを使用したいのですが、Calicoとの相性が？
- →ネットワークプラグインをFlannelに変更しました。
- MetalLBは、Kubesprayでプロビジョニングしたほうが手間が小さいです。
- corednsとnodelocaldns
- Kubesprayにて、nodelocaldnsがクラッシュする問題があるようです。playbook実行時のオプションを調整して回避しました。
追々、そのあたりを書き足させて頂く予定です。