Kubernetes: RCおよびポッドでポッドを指定するときのlog-driverおよびlog-optの定義

/ cc @ kubernetes / rh-クラスター-インフラ

うーん、おそらくこれをクラスター全体をデフォルトとして設定し、特定のポッド定義をオーバーライドできるようにしたいと思うでしょう。

cc @sosiouxme @smarterclayton @liggitt @jwhonce @jcantrill @bparees @jwforres

コンテナごとにこれをどのように活用するか（ユースケース）を説明できますか？ 従来、Docker固有のオプションは、ランタイム間で明確に抽象化できない限り、コンテナーで直接公開していません。 これをどのように使用したいかを知ることは、それを正当化するのに役立ちます。

dockerログはまだjson-fileとjournaldドライバーのみをサポートしていることに注意してください。ただし、リストは拡張される可能性があると思います。

おそらく、ユーザーが実際に望んでいるのは、ログドライバーの詳細に触れることではなく、定義されたログ書き込みエンドポイントの選択です。

@ncdc @smarterclayton内部でのユースケースを再検討した後、私はあなたの両方に同意します。

1. 私たちの主な必要性は、ノードを保護することです。 ログをログサーバーに送信しますが、失敗した場合は、Docker内部ログにフォールバックします。 このような場合、ノードの飽和を防ぐために、Dockerログのクラスター全体の動作が必要です。
2. @smarterclaytonが提案したように、pod / Rc定義で特定のDockerオプションを公開することはお勧めできません。 また、可能であれば高レベルのログ動作の定義を可能にする抽象化にも同意します
3. もう1つのオプションは、このようなログの動作を処理するためにkubelet構成ファイルとコードを変更することです。

これをデフォルトにするためのsaltテンプレートへの変更はすべきではありません
ひどく難しい。 それは本当に適切なデーモン構成です（そして
のおかげでfluentdを介してログ集約への変更を処理する
別のソースを選択する）

10:55で火、2015年10月13日には、エポJemba [email protected]
書きました：

@ncdc https://github.com/ncdc @smarterclayton
https://github.com/smarterclayton後、私はあなたの両方に同意します
内部でのユースケースを再検討すると、

1. 私たちの主な必要性は、ノードを保護することです。 ログをログに送信します
   サーバーですが、失敗した場合は、Dockerの内部ログにフォールバックを記録します。 そのような中で
   場合、ノードの飽和を防ぐために、クラスター全体の動作が必要です。
   Dockerログ
2. ポッド/ Rc定義で特定のDockerオプションを公開することは
   @smarterclaytonとしての良いアイデアhttps://github.com/smarterclayton
   それを提案した。 また、高の定義を可能にする抽象化にも同意します
   可能であればレベルログの動作
3. 別のオプションは、kubelet構成ファイルに変更を加えることです。
   このようなログの動作を処理するコード

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/15478#issuecomment -147740136
。

：いいぞ：

現在、 9つのロギングドライバがあることに注意してください。 これを取り入れることについてのコンセンサスは何ですか？

+1

誰もが気付いていない場合は、Dockerデーモンへのフラグ（ --log-driver ）を使用して、ノードごとにデフォルトのログドライバーを定義できます。 私の環境では、この方法でドライバーをjournaldに設定しました。 正直に言うと、コンテナごとにこれをオーバーライドするためのユースケースを考えるのに苦労しています。

ほとんどのクラスタリングでは、ログが「帯域外」になることを望まないため、これによって提供される機能の有効化とは何ですか。

また、運用の観点からは、制御が失われているように見えます。 現在、デフォルトを設定し、ログスタックを集約するように構成しています。

これに+1。
Dockerロギングの処理方法を制御できないということは、正しいロギングオプションがk8sに付属のツールを使用することだけであることを意味します。これは信じられないほどの制限です。

@timothyscここで私たちのユースケース。 複雑な動的インフラストラクチャ（最大100台のマシン）があり、多くの既存のサービスが実行されており、ログを収集するための独自のlogstashがあります。 現在、サービスを1つずつk8sに移行しようとしていますが、既存のインフラストラクチャとk8sにクラスター化されたコンテナーの間でロギングを統合するクリーンな方法はないようです。

K8Sは、ログの収集方法について非常に意見が分かれています。 これは、単純なインフラストラクチャでゼロから始める人にとっては素晴らしいことかもしれません。 深く掘り下げてカスタムロギングメカニズムを実装することを気にしない複雑なインフラストラクチャに取り組んでいる他のすべての人にとって、現時点ではそれを行う方法がないため、非常にイライラします。

うまくいけば、それは理にかなっています。

したがって、シナリオでは、ログは本当に「アプリケーションごと」ですが、
基盤となるホストがこれらのログをサポートしていることを確認しますか？ それが私たちの懸念です
ここで説明します-クラスターレベルまたはノードレベルのいずれかを実行しますが、実行する場合
ポッドレベルの場合、スケジューラはどのログドライバを認識している必要があります
どこに存在します。 可能な限りそれを避けようとします。

2016年5月23日月曜日午前10時50分、Jacopo Nardiello < [email protected]

書きました：

これに+1。
Dockerロギングの処理方法を制御できないということは、
正しいロギングオプションは、k8sに付属のツールを使用することだけです。
信じられないほどの制限。

@timothyschttps ：//github.com/timothyscここに私たちのユースケースがあります。 私たちは
多くの既存の複雑な動的インフラストラクチャ（約100台のマシン）
ログを収集するための独自のlogstashを使用して、それらで実行されているサービス。 さて、私たちは
現在、サービスを1つずつk8sに移動し、そこで私に移動しようとしています。
既存のログを統合するためのクリーンな方法ではないようです
k8にクラスター化されたインフラストラクチャとコンテナ。

K8Sは、ログの収集方法について非常に意見が分かれています。 これは素晴らしいかもしれません
シンプルなインフラストラクチャでゼロから始める人のために。 にとって
気にしない複雑なインフラストラクチャに取り組んでいる他のすべての人
深く掘り下げて、カスタムロギングメカニズムを実装するために、単にありません
現時点でそれを行う方法は、非常にイライラします。

うまくいけば、それは理にかなっています。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/15478#issuecomment -221002545

@smarterclayton私はあなたの懸念について理解しています、そして彼らはうまく配置されています。 クラスター全体がポッドレベルのログの存在を認識している必要があるかどうかはわかりませんが、ポッドstdout / stderrをどこかにログに記録するオプション（現在のポッド名に基づくファイル？）を提供する必要があると思います。そのため、カスタムソリューションを実装する意思のある人は誰でも、コンテンツを取得するための永続的な場所を確保できます。 ログローテーションは簡単ではないので、これは巨大な章を開きます。

これらは私の2セントですが、実際の複雑なシナリオが既存のロギングインフラストラクチャを放棄するだけのふりをすることはできません。

アプリケーションごとにカスタムログオプションを指定していますか？ いくつ違う
クラスタごとにログオプションのセットがありますか？ の小さなセットがある場合
config、オプションはポッド上の注釈をサポートすることです
多数の「標準ログ」を提供するノードレベルの構成に関連付けられています
オプション」。つまり、kubeletの起動時に、「ログモードX」を定義します（これは、
カスタムログオプションとドライバー）、ポッドは「
pod.alpha.kubernetes.io/log.mode=X "。

さらに別のオプションは、デプロイヤーに
開始する直前にコンテナ定義を変更する機会
コンテナ。 今日はシリアル化する必要があるため、これは困難です。
docker def outを中間形式に変換して実行し、実行します
繰り返しますが、将来的にはもっと簡単になる可能性があります。

最後に、コンテナインターフェイスでキーと値のペアを公開できます。
コンテナエンジンに直接渡され、APIの保証はありません
それらを確認し、PodSecurityPolicyがこれらのオプションを規制できるようにします。 それは
発信者のエスケープハッチになりますが、提供することはできません
それらがリリース間で引き続き機能することを保証します。

5：34 AMに木、2016年5月26日には、ヤコポNardiello [email protected]
書きました：

@smarterclaytonhttps ：//github.com/smarterclayton私は理解しています
あなたの懸念と彼らはうまく配置されています。 クラスター全体かどうかはわかりません
ポッドレベルのロギングの存在を認識している必要があります。
ポッドstdout / stderrをどこかにログに記録するオプションを提供する必要があります（ファイル
現在のポッド名に基づいていますか？）
カスタムソリューションは、コンテンツを取得するための永続的な場所があります。
ログローテーションは簡単ではないので、これは巨大な章を開きます。

これらは私の2セントですが、その現実世界の複合体のふりをすることはできません
シナリオは、既存のロギングインフラストラクチャを放棄するだけです。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/15478#issuecomment -221823732

@smarterclaytonはhttps://github.com/kubernetes/kubernetes/issues/24677#issuecomment-220735829を見たことがあり

結構です。 そこに議論を移します。

11:23の木、2016年5月26日には、アンディ・ゴールドスタイン[email protected]
書きました：

@smarterclayton https://github.com/smarterclayton見たことがありますか＃24677
（コメント）
https://github.com/kubernetes/kubernetes/issues/24677#issuecomment -220735829

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/15478#issuecomment -221903781

やあ、
これは、kubernetesで考慮すべき重要な機能だと思います。
Dockerのログドライバーの使用を有効にすると、いくつかの重要な問題を解決できます。

ディスクへのログ記録はアンチパターンだと思います。 ログは本質的に「状態」であり、ディスクに保存しないことが望ましいです。 ログをコンテナからリポジトリに直接転送すると、多くの問題が解決します。

ログドライバーを設定すると、kubectllogsコマンドは何も表示できなくなります。
この機能は「便利」ですが、ログが別のソースから入手できる場合は、この機能は必要ありません。

Dockerには、Google Cloud（gcplogs）とAmazon（awslogs）用のログドライバーがすでにあります。 Dockerデーモン自体に設定することは可能ですが、多くの欠点があります。 2つのDockerオプションを設定できることにより：

--log-driver =コンテナのロギングドライバ
--log-opt = []ログドライバーオプション

ラベル（gcplogsの場合）またはawslogs-group（awslogsの場合）を一緒に送信することが可能です。
ポッドに固有です。 そうすれば、もう一方の端でログを簡単に見つけることができます。

人々がkubernetesでログをどのように処理しているかについて読んでいます。 多くの人が、ログを中央システムに転送する精巧なスクレーパーを設定しているようです。 ログドライバーを設定できると、それが不要になります-より興味深いことに取り組むための時間を解放します:)

また、私を含む一部の人々は、ホストでlogrotateを設定する代わりに、JSONロギングドライバー（dockerにネイティブ）で '--log-optmax-size'オプションを使用してdockerログローテーションを実行したいと考えています。 したがって、「-log-opt」オプションだけを公開することも大歓迎です。

コンテナ構成LogConfigを作成するときに、k8sを変更しました。

+1
Dockerログドライバーを使用して一元化されたログ収集を行うと、ログファイルのシンボリックリンクを作成し、それらを特別なfluentdコンテナーにマウントし、それらを調整し、ログローテーションを管理するよりもはるかに簡単に見えます。

コンテナーごとの構成のユースケース：デプロイするコンテナーについて他の場所または別の方法でログを記録したいのですが、Kubernetesの実行に必要な標準コンテナーのログドライバーを気にしません（または変更したい）。

そこに行きます。 これを実現させてください。

もう1つのアイデアは、すべてのコンテナーが引き続きログを同じエンドポイントに転送するが、ログサーバー上の少なくとも異なるフィールド値を設定できるというものです。

これは、Kubernetesによって作成されたDockerコンテナーにカスタムラベルが付けられていることを確認できれば、gelfdockerドライバーで機能します。 意味：ポッドフィールドの一部は、Dockerコンテナラベルとして転送される可能性があります。 （多分これはすでに可能ですが、私はそれを達成する方法がわかりません）。

Kubernetesを使用せず、dockerデーモンとgelfドライバーのみを使用した例。 Dockerデーモンを--log-driver=gelf --log-opt labels=env,label2で構成し、Dockerコンテナーを作成します。

docker run -dti --label env=testing --label label2=some_value alpine:3.4 /bin/sh -c "while true; do date; sleep 2; done"

および別のDockerコンテナ：

docker run -dti --label env=production --label label2=some_value alpine:3.4 /bin/sh -c "while true; do date; sleep 2; done"

このように、Graylogでは、 env=production env=testingコンテナと

現在、私はそのようなdockerデーモンオプションを使用しています：

--log-driver=gelf --log-opt gelf-address=udp://graylog.example.com:12201 --log-opt tag=k8s-testing --log-opt labels=io.kubernetes.pod.namespace,io.kubernetes.container.name,io.kubernetes.pod.name

@xmik 、それが既存の機能またはあなたの提案であることを確認するために

現在、私はそのようなdockerデーモンオプションを使用しています：

--log-driver=gelf --log-opt gelf-address=udp://graylog.example.com:12201 --log-opt tag=k8s-testing --log-opt labels=io.kubernetes.pod.namespace,io.kubernetes.container.name,io.kubernetes.pod.name

私が現在使用しているDockerデーモンオプションは、すでに機能しています。 Kubernetesは、Dockerコンテナごとにすでにいくつかのラベルを設定しています。 たとえば、kube-apiserverコンテナでdocker inspectを実行する場合：

 "Labels": {
   "io.kubernetes.container.hash": "4959a3f5",
   "io.kubernetes.container.name": "kube-apiserver",
   "io.kubernetes.container.ports": "[{\"name\":\"https\",\"hostPort\":6443,\"containerPort\":6443,\"protocol\":\"TCP\"},{\"name\":\"local\",\"hostPort\":8080,\"containerPort\":8080,\"protocol\":\"TCP\"}]",
   "io.kubernetes.container.restartCount": "1",
   "io.kubernetes.container.terminationMessagePath": "/dev/termination-log",
   "io.kubernetes.pod.name": "kube-apiserver-k8s-production-master-1",
   "io.kubernetes.pod.namespace": "kube-system",
   "io.kubernetes.pod.terminationGracePeriod": "30",
   "io.kubernetes.pod.uid": "a47396d9dae12c81350569f56aea562e"
}

したがって、これらのDockerデーモンオプションは機能します。

ただし、ポッドの仕様に基づいて、KubernetesにDockerコンテナにカスタムラベルを設定させることは現在不可能だと思います。 したがって、たとえば--log-driver=gelf --log-opt labels=env,label2は機能しません。

この面で何かニュースはありますか？ ラベルを指定して--log-opt labels<>する機能があると、かなり良いでしょう。

@portante @jcantrillこれについて説明したので、ここでキャプチャするために、これが役立つと考えていたユースケースを次に示します。

ログ記録ポッドがエラーの検出とログ記録を開始すると、それらのエラーを収集するインフラストラクチャがそれらを取得して記録メカニズムにフィードバックし、記録メカニズムがさらにエラーをスローしてログに記録します。

このフィードバックループは、フィルタリングメカニズムを使用することで回避できますが、少し脆弱です。 別のログドライバーを使用してファイルに記録し、ローテーションオプションを設定することは、良い解決策のようです。

私の2セント。

k8s内でのロギングに対する現在のソリューションは次のとおりです（AFAIK）：

• どこかにログを送信するサイドカーコンテナ
• すべてのログをどこかに送信するレプリケーションコントローラー
• コンテナ自体がログをどこかに送信します

サイドカーコンテナは私にはちょっとやり過ぎのようです。 レプリケーションコントローラーの戦略は良いように見えますが、すべてのデプロイメントからのコンテナーのログが混在しているため、一部のユーザーはそれを必要とし、代わりに各アプリを別のものにログに記録したい場合があります。 この場合、最後のオプションはIMHOで最適に機能しますが、すべてのコンテナーに複製された多くのコードを作成します（例：logentriesデーモンのインストールとセットアップ）。

log-driverフラグにアクセスできれば、これはすべてはるかに簡単になるため、各デプロイメントは、Dockerのネイティブ機能を使用してログに記録する方法を定義します。

私はそれを実装しようと試みることができますが、おそらくいくつかの助けが必要になります-私はkubernetesコードベースに精通していないので。

マルチテナンシーが重要になると、適切に解決するのが難しくなります。

各名前空間は異なるテナントである可能性があるため、それぞれのログは必ずしも集約される必要はありませんが、テナントが指定した場所に送信できるようにする必要があります。

私はこれを行ういくつかの方法を考えることができます：

1. 新しいボリュームタイプcontainer-logsを作成します。 これにより、特定の名前空間によって起動されたデーモンセットが、独自のコンテナからログのみにアクセスできるようになります。 次に、選択したログシッパーを使用して、選択したストレージデーモンにログを送信できます。
2. fluentd-bitなどの1つ（または複数）のログシッパーを変更して、ポッドが含まれる名前空間を読み取り、各ポッドから、その名前空間でサービスとして実行されている別のログシッパーにログをリダイレクトします。 fluentdなど。 これにより、名前空間は、サポートしたいログバックエンドにプッシュするように独自のログシッパーを構成できます。

@ caarlos0 @ kfox1111私はあなたの意見に同意します。 これは、インストルメンテーション、ストレージ、ノード、さらにはさらに多くのチームの調整が必要になるため、複雑なトピックです。 最初に全体的なログアーキテクチャの提案を提示してから、この一貫したビューへの変更について説明することをお勧めします。 私は、この提案が1か月かそこらで現れ、秩序をもたらし、言及されたすべての問題を理解することを期待しています。

@crassirostris理解できません。 log-driver許可するだけであれば、ストレージなどを処理する必要はありません。

Dockerは、コンテナベースで設定されているログドライバにSTDOUTを送信するだけですか？ 私たちは責任をコンテナに移します...私には非常に単純な解決策のように思えます-しかし、私が言ったように、私はコードベースを知らないので、多分私は単に間違っています...

問題は、dockerのログドライバーがk8sメタデータを追加しないため、後でログを使用することが実際に役立つことです。 ：/

@ kfox1111うーん、理にかなっています...

しかし、ユーザーが「アプリケーション」ログのみを必要とし、kubernetesログではなく、dockerログではなく、コンテナーログ内で実行されているアプリのみを必要とする場合はどうでしょうか。

その場合、私には、 log-driverが機能するようです...

@ caarlos0これにはいくつかの影響がある場合があります。たとえば、kubeletは、サーバーkubectlログへのログ形式についていくつかの仮定を行います。

しかし、すべてを除けば、 log-driver自体はDocker固有であり、他のランタイムでは機能しない可能性があります。これが、APIに含めない主な理由です。

理にかなっている

この機能は（問題で説明されているように）追加されないので、おそらくこの問題を閉じる（または編集するなど）必要がありますか？

@ caarlos0ただし、ロギングの設定をより柔軟で透過的にしたいと考えています。 提案に対するフィードバックをお待ちしております。

コンテナからのstdoutロギングは現在、Kubernetes内で帯域外で処理されています。 現在、ロギングを処理するために非Kubernetesソリューション、または帯域外ロギングにアクセスするためにKubernetesをジェイルブレイクする特権コンテナに依存しています。 コンテナーのランタイムロギングはランタイム（docker、rkt、Windows）ごとに異なるため、Docker --log-driverのようにいずれかを選択すると、将来の手荷物が作成されます。

ログストリームを帯域内に戻すには、kubeletが必要であることをお勧めします。 最小限のJSONまたはXMLログ形式を定義または選択します。これにより、各コンテナーからstdout行が収集され、最小限のクラスター+名前空間+ポッド+コンテナーメタデータが追加されます。これにより、ログソースがKubernetesスペース内で識別され、ストリームがKubernetes Service +に転送されます。港。 ユーザーは、好きなログ消費サービスを自由に提供できます。 たぶん、Kubernetesは「kubectllogs」サポートを実装する1つのリファレンス/デフォルトサービスを提供します。

ロギング消費サービスが指定されていない場合、ディスクにまったくヒットしません。 ログを他の場所にストリーミングしたり、永続ストレージに書き込んでローテーションしたりすることは、サービスの責任/決定です。

kubeletコンテナランタイムラッパーは、最小限の処理で各コンテナランタイムからstdoutを抽出し、k8sセルフホストサービスが消費して処理できるように帯域内に戻します。

DeploymentまたはPodのコンテナ仕様では、オプションで、stdoutロギングのターゲットサービスとポートを指定します。 cluster + namespace + pod + containerのk8sメタデータの追加はオプションです（したがって、raw / untouchedまたはメタデータ付きの選択）。 ユーザーは、すべてのログを1つの場所に自由に集約したり、テナント、名前空間、またはアプリケーションごとに集約したりできます。

これに最も近いのは、「kubectl logs -f」を使用して、APIサーバーを介して各コンテナーのコンテナーログをストリーミングするサービスを実行することです。 それはあまり効率的でもスケーラブルでもないようです。 この提案により、コンテナーランタイムラッパーからサービスまたはポッドへの直接のより効率的な直接スチーミングが可能になり、同じノードでのデプロイメントまたはデーモンセットポッドのロギングを優先し、コンテナーがログを生成するなどの最適化が可能になります。

Kubernetesは、Kubernetesスペース内で作成するセルフホスト、同種、または異種のログソリューションに対して、コンテナのランタイムログを効率的にインバンドにするために最小限のことを行う必要があることを提案しています。

人々はどう思いますか？

@whereisaaronロギングエコシステムに関するすべての詳細が一か所にないので、今はこの議論をしたくありません。

たとえば、ネットワークとマシンの問題によってログフローが中断されているのがわかりますが、繰り返しになりますが、まだ説明したくありません。 後で提案の準備ができたら、これについて話し合うのはどうですか？ それはあなたにとって合理的だと思いますか？

確かに@crassirostris。 提案をチェックアウトする準備ができたら、ここでお知らせください。

/ sigスケーラビリティ

--log-driverと--log-optはどちらもDockerデーモンのオプションであり、k8s機能ではありませんが、k8sポッド仕様で次のように指定すると便利です。

1. 単一のノードレベルのログドライバーではなく、ポッドごとのログドライバー
2. 同じノード上のさまざまなタイプのアプリ固有のログドライバー（fluentd、syslog、journald、splunk）
3. --log-optを設定して、ポッドのログローテーションを構成します
4. ポッドごとの--log-opt設定であり、単一のノードレベルの--log-optありません

AFAIK、今日のk8sポッド仕様では上記のいずれもポッドレベルで設定できません。

@vhosakot上記のいずれも、Kubernetesの概念ではないため、Kubernetesのどのレベルでも設定できません。

@crassirostris正確に！ :)

Dockerがポッドレベル/コンテナレベルで行うすべてのことをk8sが実行する場合、ユーザーにとっては簡単ではないでしょうか。 ポッドレベル/コンテナレベルのものがほとんどないために、ユーザーにDockerをまったく使用させないのはなぜですか？

そして、Dockerファンではなくk8s愛好家が同じ質問をするかもしれません。

@vhosakot Pointは、K8で使用できるコンテナランタイムは他にもたくさんありますが、 --log-optはDockerにのみ存在します。 K8sレベルでこのようなオプションを作成すると、意図的に抽象化がリークされます。 これが私たちの行きたい方法ではないと思います。 オプションが存在する場合、それはすべてのコンテナランタイムでサポートされている必要があり、理想的にはCRIの一部である必要があります

そのようなオプションがないと言っているのではなく、Dockerへの直接ルートではないと言っています

@crassirostris確かに、Docker固有ではなく、ポッドレベル/コンテナレベルでCRIが実行/許可することをk8sが実行する必要があるかどうかにかかっているようです。

うん、絶対に正しい

私はこの議論に遅れており、この機能が実装されているのを見ることに興味がありますが、きれいなデザインを持つことと、正気で均一なロギングソリューションを設定する簡単な方法を持つことの間にはトレードオフがあると主張しますクラスター用。 はい、この機能を実装すると、Dockerの内部が公開されますが、これは大したことではありませんが、同時に、K8Sユーザーの大多数がDockerを基盤となるコンテナ技術として使用しており、Dockerには非常に包括的なリストが付属しています。ログドライバの。

@ gabriel-tincu私は現在、元のFRが問題を起こす価値があるとは確信していません

dockerには、ログドライバーの非常に包括的なリストが付属しています

K8sのデプロイ手順中にDockerレベルでログを設定し、この情報をK8sにリークすることなく、これらのログドライバーのいずれかを使用できます。 今日できない唯一のことは、コンテナごと/ポッドごとにこれらのオプションを設定することです（実際には、専用ノードを使用して設定し、ノードセレクタを使用できます）が、それが大きな制限であるかどうかはわかりません。

@crassirostris __before__環境をセットアップする前にセットアップできることに同意しますが、環境がすでにセットアップされた後でDockerログドライバーをアクティブに更新する方法がある場合は、現時点ではわかりません。

@ gabriel-tincu @vhosakot > = 1.5の「昔」にk8sとDockerの間に存在していた直接インターフェースは非推奨になり、コードは完全に削除されたと思います。 kubeletとDocker（またはrkt、cri-o、runc、lxdなどの他のもの）のようなランタイムの間のすべてがCRIを通過します。 現在、多くのコンテナランタイムがあり、Docker自体は非推奨になり、 cri-containerd + containerdを優先して間もなく削除される可能性があります。

http://blog.kubernetes.io/2017/11/containerd-container-runtime-options-kubernetes.html

@crassirostris提案に関する動きはありますか？それは帯域内コンテナロギングの可能性があるかもしれませんか？

CRIコンテナログはファイルベース（https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/kubelet-cri-logging.md）であり、ログパスは明示的に定義されています。

/var/log/pods/PodUID/ContainerName/RestartCount.log

ほとんどのdockerロギングドライバーhttps://docs.docker.com/config/containers/logging/configure/#supported-logging-driversでは、クラスター環境で最も重要なのは、コンテナーログをクラスターに取り込むドライバーです。 splunk 、 awslogs 、 gcplogsなどのロギング管理システム。

CRIの場合、「dockerlogdriver」は使用しないでください。 デーモンセットを実行して、CRIコンテナログディレクトリから必要な場所にコンテナログを取り込むことができます。 彼らはfluentdを使用したり、自分でデーモンセットを作成したりすることもできます。

さらにメタデータが必要な場合は、メタデータファイルを削除するか、ファイルパスを拡張するか、デーモンセットにapiserverからメタデータを取得させることを検討できます。 このhttps://github.com/kubernetes/kubernetes/issues/58638について進行中の議論があり

90日間操作がないと、問題は古くなります。
/remove-lifecycle staleして、問題を新規としてマークします。
古い問題は、さらに30日間非アクティブになると腐敗し、最終的には閉じます。

この問題を今すぐ解決できる場合は、 /close 。

SIG-テスト、kubernetes /テスト・インフラおよび/またはへのフィードバックを送信fejta 。
/ lifecycle stale

古くなった問題は、30日間操作がないと腐敗します。
/remove-lifecycle rottenして、問題を新規としてマークします。
腐った問題は、さらに30日間操作がないと終了します。

この問題を今すぐ解決できる場合は、 /close 。

SIG-テスト、kubernetes /テスト・インフラおよび/またはへのフィードバックを送信fejta 。
/ライフサイクル腐敗
/ remove-lifecyclestale

/ remove-lifecycle rotten

これに関する更新はありますか？ では、Dockerコンテナでk8sを実行している人は、AWSCloudWatchなどのバックエンドへのロギングをどのように解決したのでしょうか。

@ bryan831 fluentdなどを使用してk8sコンテナのログファイルを収集し、それらをバックエンド、CloudWatch、StackDriver、Elastisearchなどの選択したものに集約するのが一般的です。

既製のHelmチャートがあります。たとえば、 fluentd + CloudWatch 、 fluentd + Elastisearch 、 fluent-bit-> fluentd->お好み、 Datadog 、その他の組み合わせなどです。

90日間操作がないと、問題は古くなります。
/remove-lifecycle staleして、問題を新規としてマークします。
古い問題は、さらに30日間非アクティブになると腐敗し、最終的には閉じます。

この問題を今すぐ解決できる場合は、 /close 。

SIG-テスト、kubernetes /テスト・インフラおよび/またはへのフィードバックを送信fejta 。
/ lifecycle stale

Docker--log-optオプションをカスタマイズできると便利です。 私の場合、「-log-opt tag = "{{。ImageName}}/{{。Name}}/{{。ID}}"」などのタグを使用して、ImageNameをログに出力したいと思います。これにより、どのコンテナバージョンがログからのものであるかがわかります。 （参照：https：//docs.docker.com/config/containers/logging/log_tags/）

/ remove-lifecyclestale

@ pmahalwar-intertrust同じ--log-optをdockerデーモンに渡すことができます。これは、すべてのコンテナーに影響します...

@ pmahalwar-kubernetesによってcontainerdから収集されたログには、すでに広範なメタデータが含まれており、コンテナに適用したラベルが含まれています。 fluentd収集すると、たとえば以下のログエントリのように、すべてのメタデータを取得できます。

{
    "log": " - [] - - [25/Oct/2018:06:29:48 +0000] \"GET /nginx_status/format/json HTTP/1.1\" 200 9250 \"-\" \"Go-http-client/1.1\" 118 0.000 [internal] - - - - 5eb73997a372badcb4e3d993ceb44cd9\n",
    "stream": "stdout",
    "docker": {
        "container_id": "3657e1d9a86e629d0dccefec0c3c7624eaf0c4a11f60f53c5045ec0839c37f06"
    },
    "kubernetes": {
        "container_name": "nginx-ingress-controller",
        "namespace_name": "ingress",
        "pod_name": "nginx-ingress-dev-controller-69c644f7f5-vs8vw",
        "pod_id": "53514ad6-d0f4-11e8-a04c-02c433fc5820",
        "labels": {
            "app": "nginx-ingress",
            "component": "controller",
            "pod-template-hash": "2572009391",
            "release": "nginx-ingress-dev"
        },
        "host": "ip-172-29-21-204.us-east-2.compute.internal",
        "master_url": "https://10.3.0.1:443/api",
        "namespace_id": "e262510b-180a-11e8-b763-0a0386e3402c"
    },
    "kubehost": "ip-172-29-21-204.us-east-2.compute.internal"
}

これらの機能をサポートする計画はまだありませんか？
--log-driver =コンテナのロギングドライバ
--log-opt = []ログドライバーオプション

こんにちは@lifubang誰の計画にも話すことはできませんが、これらの機能をサポートしていたデーモンdockerdはKubernetesの一部ではなくなりました（上記の説明を参照してください）。

必要に応じてオプションでインストールできるため、古いdockerdログドライバーを使用するためにインストールできる場合があります。 そのオプションについては、ここで説明します。
https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/

ただし、 fluentdなどの専用のログサービスを使用することをお勧めします。 クラスター用にグローバルにデプロイすることも、サイドカーとしてポッドごとにデプロイすることもできます。 Kubernetesへのログインについてここで説明します。
https://kubernetes.io/docs/concepts/cluster-administration/logging/

@whereisaaronで説明されているようにfluentdを強くお勧めします

この機能リクエストが処理されている限り、kubernetesアーキテクチャロードマップでは、実際にはkubernetesの「一部」ではないものの「エコシステム」セクションにログが記録されているため、このような機能がネイティブでサポートされることはないと思います。
https://github.com/kubernetes/community/blob/master/contributors/devel/architectural-roadmap.md#summarytldr

fluentdにはいくつかのバグがあり、k8sを実行すると人生が悪くなる可能性があるため、fluentdの使用は強くお勧めします。

in_tailは、dockerがコンテナーhttps://github.com/fluent/fluentd/issues/1680を削除できないようにし

in_tailは、起動フェーズ中に追跡されていないファイルの位置を削除します。 これは、pos_fileのコンテンツが再起動するまで増大し、動的パス設定で多数のファイルを追跡すると、大量のCPUスキャンを消費する可能性があることを意味します。
https://github.com/fluent/fluentd/issues/1126。

90日間操作がないと、問題は古くなります。
/remove-lifecycle staleして、問題を新規としてマークします。
古い問題は、さらに30日間非アクティブになると腐敗し、最終的には閉じます。

この問題を今すぐ解決できる場合は、 /close 。

SIG-テスト、kubernetes /テスト・インフラおよび/またはへのフィードバックを送信fejta 。
/ lifecycle stale

@roffeをご利用いただきありがとうございます。 fluent / fluentd＃1680はk8s 1.5に関する問題であり、そのため、当時は「in_tail」を使用していませんでした。 k8sがcontainerdロギングに移行したので、それはまだ問題ではないようですか？ fluent / fluentd＃1126による検出可能な影響は見られませんでした。

fluentdに対してお勧めします。 代わりに何をお勧めしますか？ k8sメタデータを使用したログ集計にfluentd代わりに個人的に何を使用しますか？

古くなった問題は、30日間操作がないと腐敗します。
/remove-lifecycle rottenして、問題を新規としてマークします。
腐った問題は、さらに30日間操作がないと終了します。

この問題を今すぐ解決できる場合は、 /close 。

SIG-テスト、kubernetes /テスト・インフラおよび/またはへのフィードバックを送信fejta 。
/ライフサイクル腐敗

腐った問題は、30日間操作がないと終了します。
/reopen問題を再開します。
/remove-lifecycle rottenして、問題を新規としてマークします。

SIG-テスト、kubernetes /テスト・インフラおよび/またはへのフィードバックを送信fejta 。
/選ぶ

@ fejta-bot：この問題を解決します。

これは閉じられるべきではなかったでしょう？
ポッドごとにlog-optsを設定しようとしているので（デーモンに設定したりlogrotateを使用したりせずに）、機能要求はまだ私には意味があります...

k8sの内部からdocker固有の構成オプションをサポートすることは良い考えではないと私はかなり確信しています。 前述のように、fluentdデーモンセットまたはfluenbitサイドカーが現在のオプションです。 それははるかに安全なので、私はサイドカーを好みます。

@whereisaaron K8s @ containerdのログソリューションを見つけました

--log-driver、-log-optはまだサポートされていませんか？
単一のポッドからSplunkにログを転送する方法を見つけようとしています。 何か案は？

単一ポッドの場合は@ sariel1212ポッドに

クラスター全体@ sariel1212をSplunkに収集する必要がある場合は、Splunk HEC fluentdプラグインを使用してfluentdをデプロイするための公式のSplunk helmチャートがあります。ノードログ、コンテナログ、コントロールプレーンログに加えて、KubernetesオブジェクトとKubernetesクラスターメトリック。 1ポッド@coffeepacのための共有emptydirとサイドカーの提案は良いアプローチです。

クラスターの所有者がDockerログドライバーを使用する方法がまだないのはかなりひどいことです。

Docker-Compose（K8sクラスターをシミュレート）を使用して非常に迅速にセットアップを行い、すべてのstdout / errをログ集約サービスにパイプすることができました。

Kubenetesでこれを実行しようとしていますか？ このスレッドから、すべてのマイクロサービスのコードを拡張する必要があるようです。 良くない。

こんにちは@ashleydavis 、 dockerdはKubernetesで非推奨になったため、Kubernetesの一部ではなくなったもののサポートを導入しても意味がありません。 Kubernetesに加えてインストールすることもできますが。 背景は次のとおりです。
https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/

必要な場合を除いて、コンテナを拡張する必要はありません。Kubernetesは、すべてのコンテナのstdout / stderrログをネイティブに自動的にストリーミングします。 これらのログストリームを収集して選択した集約サービスに送信するには、各ノードに1つのコンテナー（ DaemonSet ）をデプロイする必要があります。 これはとても簡単だ。

https://docs.fluentd.org/container-deployment/kubernetes

既製のfluentd +バックエンドコンテナイメージと、バックアグリゲーションバックエンドのサンプル構成は次のとおりです。

https://github.com/fluent/fluentd-kubernetes-daemonset

DataDogを使用している場合は、代わりに、またはfluentdをインストールするための独自のエージェントがあります。

https://docs.datadoghq.com/integrations/kubernetes/

一般に、 dockerはkitchen sinkになる傾向があり、ロギングとログプラグイン、スウォーム、ランタイムツール、ビルドツール、ネットワーキング、ファイルシステムのマウントなどがすべて1つのデーモンプロセスに含まれています。 Kubernetesは通常、緩く結合されたコンテナ/プロセスがそれぞれ1つのタスクを実行し、APIを介して通信することを好みます。 ですから、慣れるのは少し違うスタイルです。

詳細な回答ありがとうございます。 私は間違いなくこれを調べるつもりです。

dockerdが非推奨になったということは、将来、DockerイメージをKubernetesにデプロイできないということですか？

@ashleydavisは確かに「Docker」イメージを使い続けることができ（ dockerd存在しなくても）、独自の目的で（docker-in-dockerのように）Kubernetesノードにdockerdをデプロイし続けることができますビルド）必要に応じて。 dockerのコア部分は、「OCIコンテナー」およびcontainerdランタイムとして抽出および標準化されています。

https://www.opencontainers.org/
https://containerd.io/

DockerとKubernetesはどちらも、これらの共有標準に基づいています。

https://blog.docker.com/2017/08/what-is-containerd-runtime/
https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/

おかげで、私はたくさん学んでいます。

Loggyと呼ばれるマイクロサービスを作成しました。 Dockerログドライバーによってログが送信され、（Webhookを介して）Slackに転送されることが意図されていました。

ここでコードを見ることができます： https ：

非常に簡単です。ログを受信し、HTTPPOSTを介してSlackに転送します。

ポッドからログを収集して集約できるように、これを適応させる最も簡単な方法は何ですか？

@ashleydavisは、そのマイクロサービスを含むコンテナイメージを構築し、次のいずれかを実行できます。

1. クラスター上のすべてのコンテナーが送信できるサービスを使用したデプロイメントとしてクラスターにサービスのクラスターDNS名を使用）。

2. デプロイメントに追加の「サイドカー」コンテナーとしてデプロイします。 同じポッド内のコンテナは、同じlocalhostへのプライベートアクセスを共有するため、アプリケーションコンテナはlocalhost:12201マイクロサービスコンテナのサイドカーに送信できます。 または、同じポッド内のコンテナで、共有ログファイルまたは名前付きパイプの

これはここでは話題から外れており、誰もがこれを望んでいるわけではないので、GithubでいくつかのSlackチャネルにアクセスしてください。

https://github.com/ramitsurana/awesome-kubernetes
https://slack.k8s.io/
https://kubernetes.io/

よろしくお願いします。 既存のサービスを変更する必要がないことを望んでいました。 彼らのstdout / errorをキャプチャしたいだけです。 とにかくそれをする？

Dockerログドライバーの約束はシンプルさでした。 これを行う簡単な方法はありますか？

確かに@ashleydavis 、クラスターをデプロイし、 fluentdデプロイし、そして強打します、これで完了です😺。 デプロイするすべてのアプリケーションでは、stdout / stderrがお気に入りのアグリゲーターに出荷されます。 👍

K8に時間をかけてログを記録した後、明示的なGELF構成なしで優れたhttps://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.htmlをご覧ください

私のセットアップはFilebeatで、ログをLogstashにパイプします。Logstashは、ログをフィルタリングして抽出し、Elasticsearchにパイプします。 Kibanaを使用すると、ログを表示してデータを集約できます。

また、オペレーティングシステムのネイティブsyslogファイルへのログ記録もサポートしたいと思います。たとえば、Ubuntuでは、ログを/var/log/syslogに書き込むことができます。これは、すぐに使用できるlogrotateによって管理されます。

群れ/作曲で、私はこれを行うことができます：

version: '3.3'
services:
  mysql:
    image: mysql:5.7
    logging:
      driver: syslog
      options:
        tag: mysql

emtpyDirボリュームの使用は問題ありませんが、ログファイルをローテーション/切り捨てるプロセスを追加しない限り、長時間実行されるポッドはボリュームをいっぱいにするリスクがあります。 OSがすでに/ var / log / syslogのローテーションを処理している場合、この追加の複雑さに同意しません。

一部の展開でサイドカーを使用することは素晴らしいアイデアであることに同意します（一部の展開ではすでにこれを行っています）が、環境は人によって異なります。

emtpyDirボリュームの使用は問題ありません

それらには注意してください-それらはKubernetesによって管理されており、その存続期間はあなたによって制御されていません。 ポッドが削除されて別のノードに再スケジュールされると、ログは失われます。 ポッドを更新してそのuidが変更された場合、ポッドは古いボリュームを使用せず、新しいボリュームを作成して古いボリュームを削除します。

@jsirianniすべてのシステムがsyslogを実行しているわけではありません。つまり、特定のポッドのニーズを確実に満たすには、使用可能な機能についてノードごとに注釈を付ける必要があります。 docker composeはローカルでのみ実行されるため、その仮定を行うことができます。

@coffeepacノードにsyslogがない可能性があるからといって、オペレーターにオプションがないことを意味するわけではありません。 Syslogを使用する場合は、ワーカーノードにSyslogがあることを確認します。

この機能のユースケースはまだ十分にあるため、この問題を再開する必要があると思います。
/ reopen

@ saiyam1814 ：この問題を再開しました。

個人的には、KubernetesはDockerログドライバーまたはログを構成するための他の簡単な組み込みの方法をサポートする必要があると思います。

Kubernetesではロギングの設定は簡単だと何度も言われてきましたが、独自のロギング集約システムを設定する過程を経て、本当に簡単ではないと言えます。

Kubernetes用に独自のログ集約システムを手動でロールする最も簡単な方法に関するブログ投稿を作成しました： http ：//www.the-data-wrangler.com/kubernetes-log-aggregation/

うまくいけば、私のブログ投稿は、他の人が自分の戦略を理解するのに役立つでしょう。

それほど難しいことではないはずですが、これが私たちの現在の状況です。

確かに、ログファイルを使用する代わりに、stdoutとstderrから直接Dockerログを使用する方法が必要です。 ホストシステム内の他のログにアクセスできるため、Dockerパスを使用してファイルをログに記録するにはセキュリティ上の問題がいくつかあります。

Dockerログドライバーを実装できますか？ 👍

ポッド内コンテナレベル（ポッドが顧客管理下にある）でDockerログドライバーを構成すると、 gelfドライバーを使用してログをgraylogサービス/ポッド（これも顧客管理下にある）に直接リダイレクトできるようになります。 ）別の即時サービス（ gelfログドライバーを使用するよりも管理オーバーヘッドが大きく、抽象化レベルの中断が悪い）を使用してホスト上のファイルからそれらを収集する代わりに、または顧客のポッドがコンテナーログディレクトリにアクセスすることによってホスト上。

したがって、この機能がkubernetesに実装されることを望んでいます。

https://github.com/cri-o/cri-o/pull/1605のようなことを確認すると便利です。ここでは、ログストリームの解釈をログドライバーから切断して、コンテナーの動作が方法に影響を与えないようにします。ドライバーは動作します。

腐った問題は、30日間操作がないと終了します。
/reopen問題を再開します。
/remove-lifecycle rottenして、問題を新規としてマークします。

SIG-テスト、kubernetes /テスト・インフラおよび/またはへのフィードバックを送信fejta 。
/選ぶ

@ fejta-bot：この問題を解決します。

機能はまだ実装する必要があります
/ reopen

@ M0rdecay ：課題/ PRを作成したか、共同編集者でない限り、再開することはできません。

@ M0rdecay ：課題/ PRを作成したか、共同編集者でない限り、再開することはできません。

わかりました

aws ecsにもこの機能があり、Dockerロギングドライバーを設定できます。
私たちの環境では、コンテナサービスごとに一意のトークンを使用して個別のインデックスを作成しました。

"logConfiguration"：{
"logDriver"： "splunk"、
"オプション"：{
"splunk-format"： "raw"、
"splunk-insecureskipverify"： "true"、
"splunk-token"： "xxxxx-xxxxxxx-xxxxx-xxxxxxx-xxxxxx"、
"splunk-url"： " https://xxxxx.splunk-heavyforwarderxxx.com "、
"タグ"： "{{。Name}} / {{。ID}}"、
"splunk-verify-connection"： "false"、
「モード」：「ノンブロッキング」
}
}

しかし、k8sではこのようなものは見つかりませんでした。 ポッド定義自体に含まれている必要があります。

オプションはまだ実装する必要があります
/ reopen

@ejemba ：この問題を再開しました。

/ sigノード
/ remove-sigインストルメンテーション

/ remove-sigスケーラビリティ

@logicalhan ：これらのラベルは問題に設定されていません： sig/

何か進展はありますか？
Dockerのgelfログドライバーを指定して、外部ログスタッシュにログインするようにポッドのコンテナーをセットアップする機能を特に探していました。 /etc/docker/daemon.json内のすべてのコンテナーに対してデフォルトで設定することは、オーバーヘッドのようです。

腐った問題は、30日間操作がないと終了します。
/reopen問題を再開します。
/remove-lifecycle rottenして、問題を新規としてマークします。

SIG-テスト、kubernetes /テスト・インフラおよび/またはへのフィードバックを送信fejta 。
/選ぶ

@ fejta-bot：この問題を解決します。

/ reopen

@andreswebs ：課題/ PRを作成したか、共同編集者でない限り、再開することはできません。

/ reopen

@ejemba ：この問題を再開しました。

@ejemba ：この問題は現在トリアージを待っています。

SIGまたはサブプロジェクトがこれが関連する問題であると判断した場合、彼らはtriage/acceptedラベルを適用することによってそれを受け入れ、さらなるガイダンスを提供します。

triage/acceptedラベルは、コメントに/triage acceptedを書き込むことで、組織メンバーが追加できます。

この機能を実装してほしいです。 現在、ワークロードをRancher1.xクラスターからk8sを実行するRancher2.xクラスターに移行しています。 docker-compose構成でlog-driverパラメーターとlog-optパラメーターを設定するデプロイメントがあります。

ゲルフドライバーをグローバルに使用し、ポッドにラベルを付け、ホストにラベルを付けるように、特定のホストを構成する必要はありません。

CRI-Oを変更して、両方のコンテナログストリーム（stdout / stderr）がraw形式で収集されるように指定する必要があるようです。後でrawを読み取るときに、ログバイトストリームのさまざまな解釈を適用できます。

https://github.com/cri-o/cri-o/pull/1605を参照して

腐った問題は、30日間操作がないと終了します。
/reopen問題を再開します。
/remove-lifecycle rottenして、問題を新規としてマークします。

SIG-テスト、kubernetes /テスト・インフラおよび/またはへのフィードバックを送信fejta 。
/選ぶ

@ fejta-bot：この問題を解決します。