Merge pull request #36632 from t-inu/issue35470
[ja] Rename file and update concepts/architecture/control-plane-node-communication.mdpull/36695/head
Kubernetes Prow Robot
GitHub
commit
23df4fb130
|
|
@ -0,0 +1,75 @@
|
|||
---
|
||||
title: ノードとコントロールプレーン間の通信
|
||||
content_type: concept
|
||||
weight: 20
|
||||
aliases:
|
||||
- master-node-communication
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
本ドキュメントは、APIサーバーとKubernetesクラスター間の通信経路をまとめたものです。
|
||||
その目的は、信頼できないネットワーク上(またはクラウドプロバイダー上の完全なパブリックIP)でクラスターが実行できるよう、ユーザーがインストールをカスタマイズしてネットワーク構成を強固にできるようにすることです。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## ノードからコントロールプレーンへの通信 {#node-to-control-plane}
|
||||
|
||||
Kubernetesには「ハブアンドスポーク」というAPIパターンがあります。ノード(またはノードが実行するPod)からのすべてのAPIの使用は、APIサーバーで終了します。他のコントロールプレーンコンポーネントは、どれもリモートサービスを公開するようには設計されていません。APIサーバーは、1つ以上の形式のクライアント[認証](/ja/docs/reference/access-authn-authz/authentication/)が有効になっている状態で、セキュアなHTTPSポート(通常は443)でリモート接続をリッスンするように設定されています。
|
||||
特に[匿名リクエスト](/ja/docs/reference/access-authn-authz/authentication/#anonymous-requests)や[サービスアカウントトークン](/ja/docs/reference/access-authn-authz/authentication/#service-account-token)が許可されている場合は、1つ以上の[認可](/docs/reference/access-authn-authz/authorization/)形式を有効にする必要があります。
|
||||
|
||||
ノードは、有効なクライアント認証情報とともに、APIサーバーに安全に接続できるように、クラスターのパブリックルート証明書でプロビジョニングされる必要があります。適切なやり方は、kubeletに提供されるクライアント認証情報が、クライアント証明書の形式であることです。kubeletクライアント証明書の自動プロビジョニングについては、[kubelet TLSブートストラップ](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)を参照してください。
|
||||
|
||||
APIサーバーに接続したいPodは、サービスアカウントを利用することで、安全に接続することができます。これにより、Podのインスタンス化時に、Kubernetesはパブリックルート証明書と有効なBearerトークンを自動的にPodに挿入します。
|
||||
`kubernetes`サービス(`デフォルト`の名前空間)は、APIサーバー上のHTTPSエンドポイントに(`kube-proxy`経由で)リダイレクトされる仮想IPアドレスで構成されます。
|
||||
|
||||
また、コントロールプレーンのコンポーネントは、セキュアなポートを介してAPIサーバーとも通信します。
|
||||
|
||||
その結果、ノードやノード上で動作するPodからコントロールプレーンへの接続は、デフォルトでセキュアであり、信頼されていないネットワークやパブリックネットワークを介して実行することができます。
|
||||
|
||||
## コントロールプレーンからノードへの通信 {#control-plane-to-node}
|
||||
|
||||
コントロールプレーン(APIサーバー)からノードへの主要な通信経路は2つあります。
|
||||
1つ目は、APIサーバーからクラスター内の各ノードで実行されるkubeletプロセスへの通信経路です。
|
||||
2つ目は、APIサーバーの _プロキシー_ 機能を介した、APIサーバーから任意のノード、Pod、またはサービスへの通信経路です。
|
||||
|
||||
### APIサーバーからkubeletへの通信 {#api-server-to-kubelet}
|
||||
|
||||
APIサーバーからkubeletへの接続は、以下の目的で使用されます:
|
||||
|
||||
* Podのログの取得。
|
||||
* 実行中のPodへのアタッチ(通常は`kubectl`を使用)。
|
||||
* kubeletのポート転送機能の提供。
|
||||
|
||||
これらの接続は、kubeletのHTTPSエンドポイントで終了します。デフォルトでは、APIサーバーはkubeletのサービング証明書を検証しないため、接続は中間者攻撃の対象となり、信頼されていないネットワークやパブリックネットワークを介して実行するのは**安全ではありません**。
|
||||
|
||||
この接続を検証するには、`--kubelet-certificate-authority`フラグを使用して、kubeletのサービング証明書を検証するために使用するルート証明書バンドルを、APIサーバーに提供します。
|
||||
|
||||
それができない場合は、信頼できないネットワークやパブリックネットワークを介した接続を回避するため、必要に応じてAPIサーバーとkubeletの間で[SSHトンネル](#ssh-tunnels)を使用します。
|
||||
|
||||
|
||||
最後に、kubelet APIを保護するために、[Kubelet認証/認可](/docs/reference/access-authn-authz/kubelet-authn-authz/)を有効にする必要があります。
|
||||
|
||||
### APIサーバーからノード、Pod、サービスへの通信 {#api-server-to-nodes-pods-and-services}
|
||||
|
||||
APIサーバーからノード、Pod、またはサービスへの接続は、デフォルトで平文のHTTP接続になるため、認証も暗号化もされません。API URL内のノード、Pod、サービス名に`https:`を付けることで、セキュアなHTTPS接続を介して実行できますが、HTTPSエンドポイントから提供された証明書を検証したり、クライアント認証情報を提供したりすることはありません。そのため、接続の暗号化はされますが、完全性の保証はありません。これらの接続を、信頼されていないネットワークやパブリックネットワークを介して実行するのは、**現在のところ安全ではありません**。
|
||||
|
||||
### SSHトンネル {#ssh-tunnels}
|
||||
|
||||
Kubernetesは、コントロールプレーンからノードへの通信経路を保護するために、SSHトンネルをサポートしています。この構成では、APIサーバーがクラスター内の各ノードへのSSHトンネルを開始(ポート22でリッスンしているSSHサーバーに接続)し、kubelet、ノード、Pod、またはサービス宛てのすべてのトラフィックをトンネル経由で渡します。
|
||||
このトンネルにより、ノードが稼働するネットワークの外部にトラフィックが公開されないようになります。
|
||||
|
||||
{{< note >}}
|
||||
SSHトンネルは現在非推奨であるため、自分が何をしているのか理解していないのであれば、使用すべきではありません。この通信経路の代替となるものとして、[Konnectivityサービス](#konnectivity-service)があります。
|
||||
{{< /note >}}
|
||||
|
||||
### Konnectivityサービス {#konnectivity-service}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
|
||||
|
||||
SSHトンネルの代替として、Konnectivityサービスは、コントロールプレーンからクラスターへの通信に、TCPレベルのプロキシーを提供します。Konnectivityサービスは、コントロールプレーンネットワークのKonnectivityサーバーと、ノードネットワークのKonnectivityエージェントの、2つの部分で構成されています。
|
||||
Konnectivityエージェントは、Konnectivityサーバーへの接続を開始し、ネットワーク接続を維持します。
|
||||
Konnectivityサービスを有効にすると、コントロールプレーンからノードへのトラフィックは、すべてこの接続を経由するようになります。
|
||||
|
||||
[Konnectivityサービスのセットアップ](/docs/tasks/extend-kubernetes/setup-konnectivity/)に従って、クラスターにKonnectivityサービスをセットアップしてください。
|
||||
|
||||
|
|
@ -1,72 +0,0 @@
|
|||
---
|
||||
title: マスターとノード間の通信
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
本ドキュメントでは、KubernetesにおけるMaster(実態はAPIサーバー)およびクラスター間のコミュニケーション経路についてまとめます。
|
||||
この文書の目的は、信頼できないネットワーク上(またはクラウドプロバイダ上の完全にパブリックなIP上)でクラスタを実行できるように、ユーザーがインストールをカスタマイズしてネットワーク構成を強化できるようにすることです。
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## クラスターからマスターへの通信
|
||||
|
||||
クラスターからマスターへのすべての通信経路は、APIサーバーで終端します(他のマスターコンポーネントはどれもリモートサービスを公開するように設計されていません)。
|
||||
一般的には、1つ以上の形式のクライアント[認証](/ja/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トンネルは現在非推奨なので、自分がしていることが分からない限り、使用しないでください。この通信チャネルに代わるものが設計されています。
|
||||
|
||||
|
||||
Loading…
Reference in New Issue