cos-auditd-loggingのtaintについて

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を利用します。
このサンプルをダウンロードする時期が異なり、サンプル自体の内容が更新されていたためでした。

終わりに

環境の自動アップグレードやソフトウェアのバージョンアップによる動作の変化同様にサンプルスクリプトも入手する時期により動作が異なる場合もあります。
自身の環境にあっているか再確認し構築を進めていっていただければと思います。