カスタムの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ルールおよび接続トラッキングをバイパスできます。ローカル・キャッシュ・エージェントは、クラスタ・ホスト名(デフォルトではcluster.local接尾辞)のキャッシュ・ミスについてkube-dns/CoreDNSサービスに問い合せます。

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コマンドは、--cluster-dnsをkubeletフラグの1つとして返し、デフォルトのローカル・リンク・アドレス(たとえば、169.254.20.10)に設定します。

前述のcloud-initスクリプトを使用してノードを作成した後、KubernetesドキュメントのKubernetesクラスタでのNodeLocal DNSCacheの使用のステップに従って、DNSキャッシュ・エージェントをデプロイします。有効にすると、ノードローカルdnsポッドは、各クラスタ・ノードのkube-systemネームスペースで実行されます。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システム・デーモンのリソースを予約するには、--kube-reservedおよび--system-reserved kubeletフラグをそれぞれkubelet-extra-argsオプションとしてカスタムcloud-initスクリプトに含めます。

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 /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)'"}'