カスタムのCloud-init初期化スクリプトを使用した管理対象ノードの設定

例1: カスタムCloud-initスクリプトを使用した管理対象ノードでのSELinux (セキュリティ強化Linux)の構成

カスタムcloud-initスクリプトを使用して、管理対象ノードにSELinuxを構成できます。SELinuxは、管理者がポリシー内のルールに基づいてどのユーザーおよびアプリケーションからどのリソースにアクセスできるかを制限できるようにする、Linuxのセキュリティ強化です。SELinuxは、アクセス制御にさらに細かい粒度を追加します。

SELinuxは、有効または無効の2つの状態のいずれかになります。有効にすると、SELinuxを2つのモード(強制または許容)のいずれかで実行できます。

デフォルトでは、SELinuxは有効になっており、ワーカー・ノードで許容モードで実行するように設定されています。許可モードで実行する場合、SELinuxはアクセス・ルールを強制せず、ロギングのみを実行します。

SELinuxでアクセス・ルールを適用する場合は、強制モードで実行するように設定できます。強制モードで実行する場合、SELinuxはポリシーに反するアクションをブロックし、対応するイベントを監査ログに記録します。

SELinuxを強制モードで実行するように設定するには、次のcloud-initスクリプトを使用します。

#!/bin/bash
curl --fail -H "Authorization: Bearer Oracle" -L0 http://169.254.169.254/opc/v2/instance/metadata/oke_init_script | base64 --decode >/var/run/oke-init.sh
bash /var/run/oke-init.sh
setenforce 1
sed -i 's/^SELINUX=.*/SELINUX=enforcing/' /etc/selinux/config 

ワーカー・ノードで実行されているSELinuxのステータスおよびモードを確認するには、ワーカー・ノードに接続し、getenforceコマンドを使用します。前述のcloud-initスクリプトがワーカー・ノードで実行されると、getenforceコマンドはEnforcingを返します。

例2: カスタムCloud-initスクリプトを使用した管理対象ノードでのNodeLocal DNSCacheの設定

カスタムcloud-initスクリプトを使用して、管理対象ノードにNodeLocal DNSCacheを構成できます。NodeLocal DNSCacheは、ワーカー・ノードでDNSキャッシュ・エージェントをデーモンセットとして実行することで、クラスタDNSのパフォーマンスを向上させます。

NodeLocal DNSCacheが有効になっていない場合、ClusterFirst DNSモードのポッドは、DNS問合せのkube-dns serviceIPに到達します。iptablesルールを使用して、このリクエストはkube-proxyによって追加されたkube-dns/CoreDNSエンドポイントに変換されます。詳細は、KubernetesドキュメントのサービスおよびポッドのDNSを参照してください。

NodeLocal DNSCacheが有効な場合、ポッドは、同じワーカー・ノードで実行されているDNSキャッシュ・エージェントに到達し、iptables DNATルールおよび接続トラッキングをバイパスできます。ローカル・キャッシュ・エージェントは、kube-dns/CoreDNSサービスに、クラスタ・ホスト名のキャッシュ・ミス(デフォルトではcluster.local接尾辞)を問い合せます。

NodeLocal DNSCacheを構成するには、次のcloud-initスクリプトを使用します。CLUSTER DNSを、クラスタ内のいずれとも競合しないローカル・リスニングIPアドレスに置き換えます。IPv4の場合は169.254.0.0/16、IPv6の場合はfd00::/8の一意のローカル・アドレス範囲から推奨されるリンク・ローカル範囲があります。

#!/bin/bash
curl --fail -H "Authorization: Bearer Oracle" -L0 http://169.254.169.254/opc/v2/instance/metadata/oke_init_script | base64 --decode >/var/run/oke-init.sh
bash /var/run/oke-init.sh --cluster-dns "[CLUSTER DNS]"

NodeLocal DNSCacheが正常にデプロイされたことを確認するには、ワーカー・ノードに接続し、sudo systemctl status -l kubeletコマンドを使用します。前述のcloud-initスクリプトがワーカー・ノードで実行されると、sudo systemctl status -l kubeletコマンドは、デフォルトのローカル・リンク・アドレス(169.254.20.10など)に設定されたkubeletフラグの1つとして--cluster-dnsを返します。

前述のcloud-initスクリプトを使用してノードを作成した後、KubernetesドキュメントのKubernetesクラスタでのNodeLocal DNSCacheの使用のステップに従って、DNSキャッシュ・エージェントをデプロイします。有効にすると、各クラスタ・ノードのkube-systemネームスペースでnode-local-dnsポッドが実行されます。node-local-dnsポッドはCoreDNSをキャッシュ・モードで実行するため、異なるプラグインによって公開されるすべてのCoreDNSメトリックをノード単位で使用できます。

DNS解決をテストするには、次のコマンドを1つ以上使用します(KubernetesドキュメントのDNS解決のデバッグを参照)。コマンドは両方とも機能し、カスタムcloud-initスクリプトの--cluster-dnsフラグによって設定されたIPアドレスも出力します。

kubectl apply -f https://k8s.io/examples/admin/dns/dnsutils.yaml

kubectl exec -it dnsutils – nslookup kubernetes.default

kubectl exec -it dnsutils – cat /etc/resolv.conf

NodeLocal DNSCacheを無効にするには、デーモンセットを削除し、nodelocaldnsマニフェストを削除します。また、kubelet構成に加えた変更も元に戻す必要があります。

例3: カスタムCloud-initスクリプトを使用した管理対象ノードでのkubelet-extra-argsの設定

カスタムcloud-initスクリプトを使用して、管理対象ノードのkubelet (プライマリ・ノード・エージェント)に多数の追加オプションを構成できます。これらの追加オプションは、kubelet-extra-argsと呼ばれることもあります。そのような kubelet-extra-argsオプションの1つは、デバッグレベルのログ冗長性を構成するオプションです。

デバッグ・レベルのログの詳細度を構成するには、次のcloud-initスクリプトを使用します。

#!/bin/bash
curl --fail -H "Authorization: Bearer Oracle" -L0 http://169.254.169.254/opc/v2/instance/metadata/oke_init_script | base64 --decode >/var/run/oke-init.sh
bash /var/run/oke-init.sh --kubelet-extra-args "--v=4"

デバッグ・レベルのログの詳細度の設定を確認するには、ワーカー・ノードに接続し、sudo systemctl status -l kubeletコマンドを使用します。前述のcloud-initスクリプトがワーカー・ノードで実行されると、sudo systemctl status -l kubeletコマンドは冗長性レベルを4として返します。kubeletログにも詳細が含まれています。

例4: カスタムCloud-initスクリプトを使用したKubernetesおよびOSシステム・デーモンのリソースの予約

カスタムcloud-initスクリプトを使用して、Kubernetesシステム・デーモン(kubeletやcontainer runtimeなど)およびOSシステム・デーモン(sshdやsystemdなど)のCPUおよびメモリー・リソースを予約できます。KubernetesおよびOSシステム・デーモンのリソースを予約するには、カスタムcloud-initスクリプトに--kube-reservedおよび--system-reserved kubeletフラグをそれぞれkubelet-extra-argsオプションとして含めます。

KubernetesおよびOSシステム・デーモンのリソースを予約するには、次のcloud-initスクリプトを使用します:

#!/bin/bash
curl --fail -H "Authorization: Bearer Oracle" -L0 http://169.254.169.254/opc/v2/instance/metadata/oke_init_script | base64 --decode >/var/run/oke-init.sh
bash /var/run/oke-init.sh --kubelet-extra-args "--kube-reserved=cpu=500m,memory=1Gi --system-reserved=cpu=100m,memory=100Mi"

詳細および--kube-reservedおよび--system-reserved kubeletフラグの推奨値については、ベスト・プラクティス: KubernetesおよびOSシステム・デーモンのリソースの予約を参照してください。

例5: カスタムCloud-initスクリプトおよびoci-growfsを使用したブート・ボリューム・パーティションのサイズの増加

カスタムcloud-initスクリプトを使用して、管理対象ノードのブート・ボリュームのパーティションを拡張できます。クラスタとノード・プールを作成および更新するときに、ワーカー・ノード・ブート・ボリュームのカスタム・サイズを指定できます。指定するカスタム・ブート・ボリューム・サイズは、選択したイメージのデフォルトのブート・ボリューム・サイズより大きくする必要があります。ブート・ボリュームのサイズを増やすときに、より大きなブート・ボリューム・サイズを利用するには、ブート・ボリュームのパーティションも拡張する必要があります。

Oracle Linuxプラットフォーム・イメージには、oci-utilsパッケージが含まれています。cloud-initスクリプトでそのパッケージからoci-growfsコマンドを使用して、ルート・パーティションを拡張し、ファイル・システムを拡張できます。

ブート・ボリュームのパーティションを拡張するには、次のcloud-initスクリプトを使用します:

#!/bin/bash
curl --fail -H "Authorization: Bearer Oracle" -L0 http://169.254.169.254/opc/v2/instance/metadata/oke_init_script | base64 --decode >/var/run/oke-init.sh
bash /var/run/oke-init.sh
bash /usr/libexec/oci-growfs -y

詳細は、ブート・ボリュームのパーティションの拡張を参照してください。

例

このサンプル・コマンドは、既存のクラスタ用にmy-cloud-init-test-nodepoolという新しいノード・プールを作成し、Oracle Linuxを実行しているVM 2.1シェイプを持つ単一のKubernetes 1.18.10ノードを使用します。新しいノード・プールでワーカー・ノードをホストしているインスタンスが初めて起動すると、my-custom-cloud-init.yamlというカスタムcloud-initスクリプトが実行されます。

oci ce node-pool create \
--cluster-id ocid1.cluster.oc1.iad.aaaa______m4w \
--name my-cloud-init-test-nodepool \
--node-image-id ocid1.image.oc1.iad.aaaa______zpq \
--compartment-id ocid1.tenancy.oc1..aaa______q4a \
--kubernetes-version v1.18.10 \
--node-shape VM.Standard2.1 \
--placement-configs "[   { \"availabilityDomain\": \"PKGK:US-ASHBURN-AD-1\", \"subnetId\": \"ocid1.subnet.oc1.iad.aaaa______kfa\"   }   ]" \
--size 1 \
--region us-ashburn-1 \
--node-metadata '{"user_data": "'$(cat my-custom-cloud-init.yaml | base64)'"}'