コンテクスト

コンテクスト
場合によっては、ポッドのログを観察し、それらのログをファイルに書き込んでさらに分析する必要があります。
タスク
以下の項目を完了してください。
* /opt/KDOB00201/counter.yaml にある YAMLspec ファイルを使用して、カウンター ポッドをクラスターにデプロイします。
* 実行中のポッドから現在利用可能なすべてのアプリケーションログを取得し、すでに作成されているファイル /opt/KDOB0020l/log_Output.txt に保存します。

形式 A でログ ファイルを書き込むコンテナーと、ログ ファイルを形式 A から形式 B に変換するコンテナーがある場合、最初のコンテナーのログ ファイルが 2 番目のコンテナーによって変換され、形式 B でログが出力されるように、両方のコンテナーを実行するデプロイメントを作成します。
タスク：
* デフォルトの名前空間に、deployment-xyz という名前のデプロイメントを作成します。
*プライマリーを含む
lfccncf/busybox:1 コンテナ、名前は logger-dev
*サイドカーのIfccncf/fluentd:v0.12コンテナ（adapter-zen）を含む
*両方のコンテナに共有ボリューム /tmp/log をマウントします。これはポッドが削除されると保持されません。
*logger-devに指示する
コマンドを実行するコンテナ

ログはプレーンテキスト形式で /tmp/log/input.log に出力されます。例の値は次のとおりです。

* アダプタ zen サイドカー コンテナーは、/tmp/log/input.log を読み取り、データを Fluentd JSON 形式で /tmp/log/output.* に出力する必要があります。このタスクを完了するために Fluentd の知識は必要ありません。これを実現するために必要なのは、/opt/KDMC00102/fluentd-configma p.yaml で提供される仕様ファイルから ConfigMap を作成し、その ConfigMap をアダプタ zen サイドカー コンテナーの /fluentd/etc にマウントすることだけです。以下の解決策を参照してください。

タスク：
buffale-deployment という名前のデプロイメント内、名前空間 gorilla 内のポッドがエラーをログに記録しています。
1) ログを見てエラー メッセージを特定します。
ユーザー「system:serviceaccount:gorilla:default」が名前空間「gorilla」内のリソース「deployment」[...] を一覧表示できないなどのエラーを検索します
2) デプロイメント buffalo-deployment を更新して、Pod のログ内のエラーを解決します。
buffalo-deployment のマニフェストは、-/prompt/escargot/buffalo-deployment.yaml にあります。以下の解決策を参照してください。

別紙を参照してください。

コンテクスト
クラスター内でアプリケーションが消費しているリソースを確認することは常に役立ちます。
タスク
* 名前空間 cpu-stress で実行されているポッドのうち、最も CPU を消費しているポッドの名前のみを、すでに作成されているファイル /opt/KDOBG030l/pod.txt に書き込みます。

コンテクスト

タスク：
craytisn 名前空間の nosql という名前のデプロイメントのポッドは、コンテナーのリソースが不足しているため起動に失敗します。
nosol デプロイメントを更新して、Pod が次の状態になるようにします。
1) コンテナに160MBのメモリを要求する
2) メモリを、crayfah 名前空間に設定された最大メモリ制約の半分に制限します。