Kubernetesクラスターイベントを理解する（後半）

Kubernetesクラスターに関する記事です。長い記事なので前半と後半の２つに分けて投稿します。今回は後半です。EtcdやKubeletについての説明です。

Etcd

Etcdは、Kubernetes APIサーバーの後ろにある標準の永続レイヤーです。このレイヤーはAPIサーバーによってのみ使用されます。そのため、期待どおりに動作しなくなるまで、それほど興味深いものではありません。 この場合、インフラストラクチャーオペレーションエンジニアが特定のイベントが以前にすでに発生しているかどうかを確認したり、詳しい障害についてと、根本原因を追跡したりするために、長期履歴ログも役立ちます。

クラウドプロバイダーが管理するKubernetesオファリングではetcdログにアクセスできませんが、自己管理クラスターの場合はインフラストラクチャーオペレーションでetcdログが必要になる場合があります。 最も一般的なシナリオでは、etcdはマスターホストで実行されていますが、Kubernetesクラスターの外部にあります。 これにより、ログ収集メソッドはAPIサーバーログに非常に似たものになります。

Authenticator

Kubernetesは、外部認証プロバイダーが強力なintegration pointが利用できるようになりますが汎用クラスターはそれがなくても完全に機能します。 たとえば、Kubernetesディストリビューション（Banzai Cloud Pipeline Kubernetes Engine）には認証サービスはありませんが、代わりにクライアント証明書を使用しています。

ほとんどの管理されたKubernetesオファリングでは、オーセンティケーターは外部クライアントから送信されたプロバイダー固有のクレデンシャルに使用し、APIサーバーが承認に必要な情報を提供するユニークなコントロールプレーンコンポーネントです。

注：通常、オーセンティケーターは、クラスター内サービスではなく、ユーザーまたは外部コンポーネントの認証に使用されます。

通常、認証プロバイダーのログにアクセスできるのは、クラウドプロバイダーのログスタックのみです。 オーセンティケーターを自分でオペレーションする場合、ログ収集は、コンポーネントの標準出力を収集するようにBanzai Cloud Loggingオペレーターをコンフィギュアするのと同じくらい簡単です。

Who needs authenticator logs

オーセンティケーターログは、インシデントの調査またはトラブルシューティング中のセキュリティまたはインフラストラクチャーオペレーションチームのいずれかに対して適切なものです。

Controller manager

コントローラーマネージャーは、状態の変更を確認し、Kubernetesのコアとなるコンストラクトの背後にあるロジックを保証する責任があります。