☰

Docker スタイルのリンクによるポッド環境変数の競合を回避する

tag-icon • tag-icon kubernetes environment-variables
Docker スタイルのリンクによるポッド環境変数の競合を回避する

KubernetesでDockerをコンテナランタイムとして実行したりコンポーネントを実行したりしています。その問題は、ポッド環境がDockerスタイルのリンク変数で汚染されていることです。

  • SERVICENAME_PORT_8181_TCP
  • SERVICENAME_PORT_HTTP
  • .....
  • SERVICENAME_PORT

表示可能なサービスごとに（同じ名前空間内のサービスごとに）です。この状況では、自動的に作成された変数が明示的に宣言された環境と競合することが非常に容易です。これにより、診断が困難な問題が発生することがあります。コンテナが Kubernetes サービス構成の詳細に依存しないようにしたいので、これらの自動変数に依存したくありません。現在、このような競合を回避するために、明示的な変数に一意の名前プレフィックスを追加しています。

表示可能なサービスごとにこれらの自動変数を追加しないようにクラスターを構成する方法はありますか? または、他のランタイムを使用するとcontainerdこの問題が解決しますか? 環境変数による構成は良い方法と考えられているため、これに対する簡単に Google で検索できる解決策がないことに驚いています。一般に、このような名前の競合に遭遇せずに環境を使用するにはどうすればよいでしょうか? または、サービス名はコンテナーとの契約の一部と見なされ、自由に変更すべきではないのでしょうか?

答え1

表示可能なサービスごとにこれらの自動変数を追加しないようにクラスターを構成する方法はありますか?

はい、いいえ。私の知る限り、クラスター全体ではありませんが、enableServiceLinks: falseフィールドインspec:スイッチをオフにできるように設計されています

あるいは、containerd などの他のランタイムを使用すると、この問題は解決しますか?

いいえ、これらの名前はdockerとの互換性のために追加されたものですが、dockerとはまったく関係がありません。kubeletによって注入された

一般的に、このような名前の競合に遭遇せずに環境を使用するにはどうすればよいでしょうか? または、サービス名はコンテナーとの契約の一部と見なされ、自由に変更すべきではないのでしょうか?

もう一つの選択肢は、全面的に禁止するのではなく、特定のアプリに問題を引き起こすもの。で終わるものは、_HTTPSpring Bootでは特に問題になります。Spring Bootでは、Servicewhoseは、またはのmetadata: { name:ような非常に一般的な名前です。serviceserver

デプロイメントごとにこれを行うことができます。

env:
- name: SERVICENAME_PORT_HTTP
  # omitting the value: just sets it to the empty string in the container
# and the rest

または、問題のあるConfigMapを宣言し、それらをすべて上書きすることもできますenvFrom:（影響を受ける各デプロイメントにパッチを当てる必要がないようにするため）。

関連情報