73 lines
6.4 KiB
Markdown
73 lines
6.4 KiB
Markdown
|
---
|
|||
|
|
title: マスターとノード間の通信
|
|||
|
|
content_template: templates/concept
|
|||
|
|
weight: 20
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
{{% capture overview %}}
|
|||
|
|
|
|||
|
|
本ドキュメントでは、KubernetesにおけるMaster(実態はAPIサーバー)及びクラスター間のコミュニケーション経路についてまとめます。
|
|||
|
|
この文書の目的は、信頼できないネットワーク上（またはクラウドプロバイダ上の完全にパブリックなIP上）でクラスタを実行できるように、ユーザーがインストールをカスタマイズしてネットワーク構成を強化できるようにすることです。
|
|||
|
|
|
|||
|
|
{{% /capture %}}
|
|||
|
|
|
|||
|
|
|
|||
|
|
{{% capture body %}}
|
|||
|
|
|
|||
|
|
## クラスターからマスターへの通信
|
|||
|
|
|
|||
|
|
クラスターからマスターへのすべての通信経路は、APIサーバーで終端します（他のマスターコンポーネントはどれもリモートサービスを公開するように設計されていません）。
|
|||
|
|
一般的には、1つ以上の形式のクライアント[認証](/docs/reference/access-authn-authz/authentication/)が有効になっている状態で、APIサーバーはセキュアなHTTPSポート（443）でリモート接続をlistenするように構成されています。
|
|||
|
|
特に[匿名のリクエスト](/docs/reference/access-authn-authz/authentication/#anonymous-requests)または[サービスアカウントトークン](/docs/reference/access-authn-authz/authentication/#service-account-tokens)が許可されている場合は、1つまたは複数の[認証](/docs/reference/access-authn-authz/authorization/)を有効にする必要があります。
|
|||
|
|
|
|||
|
|
ノードには、有効なクライアント認証情報を使って安全にAPIサーバーに接続できるように、クラスターのパブリックなルート証明書をプロビジョニングする必要があります。
|
|||
|
|
たとえば、GKEのデフォルト設定では、kubeletに提供されるクライアント認証情報はクライアント証明書の形式です。
|
|||
|
|
kubeletのクライアント証明書を自動プロビジョニングする方法については、[kubelet TLSブートストラッピング](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)を参照してください。
|
|||
|
|
|
|||
|
|
APIサーバーに接続したいPodは、サービスアカウントを利用することで接続を安全にすることができます。そうすることで、Podが作成されたときにKubernetesがパブリックなルート証明書と有効なBearer TokenをPodに自動的に挿入します。
|
|||
|
|
|
|||
|
|
`kubernetes`サービスには（すべてのネームスペースで）、APIサーバー上のHTTPSエンドポイントに（kube-proxy経由で）リダイレクトされる仮想IPアドレスが設定されています。
|
|||
|
|
|
|||
|
|
マスターコンポーネントは、セキュアなポートを介してクラスターAPIサーバーとも通信します。
|
|||
|
|
|
|||
|
|
その結果、クラスター（ノードとそのノードで実行されているPod）からマスターへの接続はデフォルトで保護され、信頼できないネットワークやパブリックネットワークを介して実行できます。
|
|||
|
|
|
|||
|
|
## マスターからクラスターへの通信
|
|||
|
|
|
|||
|
|
マスター（APIサーバー）からクラスターへの通信には、2つの主要な通信経路があります。
|
|||
|
|
1つ目は、APIサーバーからクラスター内の各ノードで実行されるkubeletプロセスへの通信です。
|
|||
|
|
2つ目は、APIサーバーのプロキシ機能を介した、APIサーバーから任意のノード、Pod、またはサービスへのアクセスです。
|
|||
|
|
|
|||
|
|
### APIサーバーからkubeletへの通信
|
|||
|
|
|
|||
|
|
APIサーバーからkubeletへの接続は以下の目的で使用されます:
|
|||
|
|
|
|||
|
|
* Podのログを取得する
|
|||
|
|
* 実行中のPodに（kubectlを通して）接続する
|
|||
|
|
* kubeletのポート転送機能を提供する
|
|||
|
|
|
|||
|
|
これらの接続は、kubeletのHTTPSエンドポイントで終了します。
|
|||
|
|
デフォルトでは、APIサーバーはkubeletが提供する証明書を検証しないため、接続は中間者攻撃を受けやすく、**安全でない**信頼できないネットワークやパブリックなネットワークを介して実行されることになります。
|
|||
|
|
|
|||
|
|
この接続を検証するには、`--kubelet-certificate-authority`フラグを使用して、kubeletが提供する証明書を確認するために使用するルート証明書バンドルをAPIサーバーに提供します。
|
|||
|
|
|
|||
|
|
それができない場合は、信頼できないネットワークやパブリックなネットワークを介した接続を回避するために、必要に応じてAPIサーバーとkubeletの間でSSHトンネリングを使用してください。
|
|||
|
|
|
|||
|
|
最後に、kubeletのAPIを保護するために[kubeletの認証認可](/docs/admin/kubelet-authentication-authorization/)を有効にする必要があります。
|
|||
|
|
|
|||
|
|
### APIサーバーからノード、Pod、サービスへの通信
|
|||
|
|
|
|||
|
|
APIサーバーからノード、Pod、またはサービスへの接続はデフォルトで平文のHTTP接続になるため、認証も暗号化もされません。
|
|||
|
|
API URL内のノード、Pod、またはサービス名に`https:`を付けることで安全なHTTPS接続で実行できますが、HTTPSエンドポイントから提供される証明書を検証したりクライアントの資格情報を提供したりすることはありませんし、暗号化されているという完全性を保証するものでもありません。
|
|||
|
|
これらの接続を信頼できないネットワークや公衆ネットワークを介して実行するのは、現時点において安全ではありません。
|
|||
|
|
|
|||
|
|
### SSHトンネル
|
|||
|
|
|
|||
|
|
Kubernetesはマスターからクラスターへの通信経路を保護するためにSSHトンネルをサポートしています。
|
|||
|
|
この設定では、APIサーバーはクラスター内の各ノード（ポート22でlistenしているsshサーバーに接続）へのSSHトンネルを開始し、トンネルを介してkubelet、ノード、Pod、またはサービス宛てのすべてのトラフィックを渡します。
|
|||
|
|
このトンネルにより、ノードが実行されているネットワークの外部にトラフィックが公開されないようにします。
|
|||
|
|
|
|||
|
|
SSHトンネルは現在非推奨なので、自分がしていることが分からない限り、使用しないでください。この通信チャネルに代わるものが設計されています。
|
|||
|
|
|
|||
|
|
{{% /capture %}}
|