以前のブログでは「バンドエイド」式の修正を適用する前に、インシデント中に関連する全ての診断結果を取得することの難しさについて説明しました。最も一般的で具体的な例としては、コンテナで動作しているアプリが、目先の問題を解決するために、コンテナを以前のバージョンや同じバージョンに再デプロイしてしまうことが挙げられます。１ミリ秒単位のパフォーマンスと１秒単位のアップタイムがカスタマーエクスペリエンスに結果的な影響を与える企業では、こうした短期間での修正をする必要があります。ただし、エンジニアがこれらのインシデントに対する長期的なソリューションの開発を任されると、ビジネスのコストは非常に大きくなります。メジャーインシデントと（再発する）マイナーインシデントの両方で、エンジニアは、インシデント発生時のアプリと環境の状態の証拠を収集するために、途方もない時間を費やさなければなりません。このような診断データの大部分はモニタリングツールにあるため永続的に記録されていますが、コンテナのライフタイムにしか利用できない情報を取得するためには、コンテナ内でシェルを取得しなければならない場合があります。Kubernetesでは、これはkubectl execコマンドを使用して行われます。適切なパラメーターを指定すると、ユーザーは実行中のコンテナでライブシェルを取得して、コマンドの実行を開始して診断データを取得できます。例えば、ユーザーがJavaコンテナにシェルを作れば、jstackを呼び出してアプリのスレッドダンプを取得できます。
しかし、多くの運用チームは誰にもその権限を許可していません。セキュリティー上の理由と、Kubernetesでの操作に精通している人数が限られているため、** 実稼働中のポッド**（重大なインシデントが発生する場所）に実行権限を持つ人は非常に限られています。その結果、インシデント中に診断データを取得するために、Kubernetesへのアクセス権と専門知識を持つ個人は定期的に助けを求める必要があります。このプロセスでMTTRが増え、関与する必要がある人の数が増えるため、インシデントのコストが増加します。
これらの理由から、ユーザーが実行中のポッドにexecする必要をなくす自動化を使うことをお勧めします。この自動化アーキテクチャーでは、問題が発生すると、自動化されたランブックが呼び出され、そのランブックがデバッグデータを取得して、それを永続的なストレージの場所（S3、Blob Storage、SFTPサーバーなど）に送信し、エンジニアにデバッグ データがどこにあるかを通知して、彼らがそのデータを見つけて使えるようにします。
PagerDuty Process Automationは、まさにこのユースケース用に、事前に構築されたテンプレート化されたランブックを提供します。アラートがPagerDuty内でインシデントを作成すると、これは自動的に（またはボタンのクリックによって）ランブックをトリガーして、ポッドでコマンドを実行し、永続的なストレージに出力し、インシデント内のそのデータの場所に関する詳細を提供します。
インシデントの発生中と発生後に、デバッグデータへのリンクがエンジニアに提供されます
当社の商用自動化製品（Process AutomationとRunbook Automation ）とオープンソースのRundeckの両方のユーザーは、こちらの手順に従って自動化されたランブックをダウンロードして開始できます。
この自動化されたRunbookは、デバッグに必要なコマンドラインユーティリティー（バイナリー）がコンテナイメージに既に含まれている場合に最適です。例えば、コンテナ化されたJavaアプリの多くは、コンテナイメージにjstackユーティリティーが付属しています。しかし、デバッグユーティリティーがコンテナイメージの一部として出荷されていない場合はどうなりますか？または、ますます一般的になっているように、コンテナが「distro-less」であり、シェルさえ提供しない場合はどうなりますか？
ここでKubernetesエフェメラルコンテナの出番です。ポッドの定義を変更したり、ポッドを再展開したりする必要なく、実行中のポッドに（任意のイメージの）コンテナをアタッチするメカニズムをユーザーに提供します。 プロセスの名前空間を共有することで、元のコンテナがクラッシュした状態であっても、エフェメラルコンテナはPod内の別のコンテナに対してデバッグユーティリティーを使用できます。 Ivan Velichkoによるブログで、エフェメラルコンテナとのプロセス名前空間の共有について詳しく説明しています。
ソース: https://iximiuz.com/en/posts/kubernetes-ephemeral-containers/
kubectl execを使う場合と同じく、エフェメラルコンテナを適切に活用するには、Kubernetesクラスターでkubectlコマンドを実行するためのアクセスが必要です。そして前述したように、コマンドを適切に構築する方法を知るには、Kubernetesに関する高度な知識が必要です。
kubectl debug -it -n ${namespace} -c debugger --image=busybox --share-processes ${pod_name}
(Kubernetesエフェメラルコンテナを使うためのサンプル コマンド)
デバッグユーティリティーのないコンテナやdistro-lessコンテナを使うユーザーに対応するために、私たちは、エフェメラルコンテナの機能を利用する新しい Kubernetes プラグインを作成しました。
このプラグインを私たちは、診断出力をキャプチャーし、出力を永続的な場所に送信する自動ランブックのテンプレート内で使いました。Process AutomationとRunbook Automationのユーザーは、ここから、Runbook Automation診断プロジェクトの一部としてダウンロードすることで、このテンプレートジョブを使い始められます。
Process AutomationやRunbook Automationアカウントをまだお持ちでない場合は、ここをクリックしてPagerDuty の自動化製品を使い始めてください。
この記事は、PagerDutyサイトで公開されている原文をDigital Stacksが日本語に翻訳したものです。 無断転載を禁じます。 原文はこちらです。
カテゴリー ：インテグレーション＆ガイド
