第7章 サービス・ディスカバリー サービス検出
この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている:translation-feedback@oreilly.com
Kubernetesは非常にダイナミックなシステムだ。 システムはPodをノードに配置し、それらが稼働していることを確認し、必要に応じて再スケジューリングすることに関与する。 負荷に応じてPodの数を自動的に変更する方法もある(Horizontal Pod Autoscalingなど[「Autoscaling a ReplicaSet」を参照])。 API駆動型であるため、より高度な自動化レベルを作成することができる。
Kubernetesの動的な性質は、多くのものを実行することを容易にする一方で、それらのものを発見することになると問題が生じる。 従来のネットワークインフラのほとんどは、Kubernetesが提示するダイナミズムのレベルに合わせて構築されていなかった。
サービス検出とは何か?
この種の問題と解決策の一般名はサービス検出である。 サービス検出ツールは、どのプロセスがどのサービスのどのアドレスをリッスンしているかを発見するという問題を解決するのに役立つ。 優れたサービス検出システムは、ユーザがこの情報を迅速かつ確実に解決できるようにする。 優れたシステムは遅延も少ない。サービスに関連する情報が変更されると、クライアントはすぐに更新される。 最後に、優れたサービス検出システムは、そのサービスが何であるかのより豊かな定義を保存することができる。 例えば、サービスには複数のポートが関連付けられているかもしれない。
ドメインネームシステム(DNS)は、インターネット上のサービス検出の伝統的なシステムである。 DNSは、幅広く効率的なキャッシュを備えた比較的安定した名前解決のために設計されている。 インターネットにとっては素晴らしいシステムだが、Kubernetesのダイナミックな世界では不十分だ。
残念なことに、多くのシステム(例えば、デフォルトではJava)は、DNSで直接名前を検索し、再解決することはない。 このため、クライアントが古いマッピングをキャッシュし、間違ったIPに接続してしまうことがある。 TTL(有効期間)が短く、行儀のよいクライアントであっても、名前解決が変更されてからクライアントが気づくまでには当然遅れが生じる。一般的なDNSクエリで返される情報の量と種類にも自ずと限界がある。 1つの名前付けに対して20から30個のアドレス(A)レコードを超えたあたりから、物事が壊れ始める。サービス(SRV)レコードで解決できる問題もあるが、非常に使いにくいことが多い。 最後に、クライアントがDNSレコード内の複数のIPを処理する方法は、通常、最初のIPアドレスを取り、DNSサーバがレコードの順序をランダム化またはラウンドロビンすることに頼ることである。 これは、より目的に合ったロードバランサに代わるものではない。
サービスオブジェクト
Kubernetesにおける実際のサービス検出は、Serviceオブジェクトから始まる。 Serviceオブジェクトは、名前付けされたラベルセレクタを作成する方法だ。 これから見ていくように、Serviceオブジェクトは他にもいくつかいいことをしてくれる。
kubectl run コマンドがKubernetesデプロイを作成する簡単な方法であるように、kubectl expose を使ってサービスを作成することができる。 ...