cos-auditd-logging のPod起動数が環境によって違ったので確認してみました。
cos-auditd-logging
GKEのノードのオペレーティング システムログには、エラー メッセージ、ログイン試行、バイナリ実行など、クラスタとワークロードの状態に関する重要な情報が記録されます。この情報を活用して、問題のデバッグやセキュリティ インシデントの調査が可能となります。cos-auditd-loggingはDaemonSetであり、各ノードごとに一つのPodをデプロイします。デプロイすることにより、GKEノード上のLinuxのAuditdロギングが有効化されます。
・cos-auditd-logging
事象
クラスタA、クラスタBはノードプールが3つ、それぞれにノードが3つずつ存在し、計9ノード存在します。
計9ノードのため、cos-auditd-loggingも9/9podとなります。
クラスタAでは9/9pod起動しましたが、クラスタBでは3/3podしか起動しませんでした。
原因
cos-auditd-loggingのtolerationsが原因でした。
まず、クラスタAとクラスタBに差異はありませんが、
ノードプールの3つの内2つにtaintセットが設定されています。
このtaintセットが設定されていることにより、許可されたワークロード(Pod)のみtaintセットが設定してあるノードプールにPodの配置が可能となります。
その為、クラスタAでは9/9pod起動し、クラスタBでは3/3podしか起動しませんでした。
対策
クラスタAのtolerationsにすることで、Taint の key や value を問わず、存在するすべての Taint を持つノードに Pod をスケジュールできる ようになります。
クラスタAとクラスタBのcos-auditd-loggingのtolerationsは以下となります。
クラスタAのtolerations
tolerations:
- effect: NoExecute
operator: Exists
- effect: NoSchedule
operator: Exists
クラスタBのtolerations
tolerations:
- effect: NoSchedule
key: node.alpha.kubernetes.io/ismaster
- effect: NoExecute
operator: Exists
- effect: NoSchedule
key: sandbox.gke.io/runtime
operator: Equal
value: gvisor
根本原因
cos-auditd-loggingをデプロイする際にサンプルdeploymentを利用します。
このサンプルをダウンロードする時期が異なり、サンプル自体の内容が更新されていたためでした。
終わりに
環境の自動アップグレードやソフトウェアのバージョンアップによる動作の変化同様にサンプルスクリプトも入手する時期により動作が異なる場合もあります。
自身の環境にあっているか再確認し構築を進めていっていただければと思います。