Fix markdown. Rewrite some kanji to hiragana. Make parentheses half-width.
This commit is contained in:
TAKAHASHI Shuuji
@@ -6,9 +6,9 @@ weight: 40
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
クラウドコントローラマネージャー(CCM)のコンセプト(バイナリと混同しないでください)は、もともとクラウドベンダー固有のソースコードと、Kubernetesのコアソースコードを独立して進化させることが出来るように作られました。クラウドコントローラーマネージャーは、Kubernetesコントローラーマネージャー、APIサーバー、そしてスケジューラーのような他のマスターコンポーネントと並行して動きます。またKubernetesのアドオンとしても動かすことができ、その場合はKubernetes上で動きます。
|
||||
クラウドコントローラマネージャー(CCM)のコンセプト(バイナリと混同しないでください)は、もともとクラウドベンダー固有のソースコードと、Kubernetesのコアソースコードを独立して進化させることができるように作られました。クラウドコントローラーマネージャーは、Kubernetesコントローラーマネージャー、APIサーバー、そしてスケジューラーのような他のマスターコンポーネントと並行して動きます。またKubernetesのアドオンとしても動かすことができ、その場合はKubernetes上で動きます。
|
||||
|
||||
クラウドコントローラーマネージャーの設計は「プラグインメカニズム」をベースにしています。そうすることで、新しいクラウドプロバイダーがプラグインを使ってKubernetesと簡単に統合出来るようになります。新しいクラウドプロバイダーに向けてKubernetesのオンボーディングを行ったり、古いモデルを利用しているクラウドプロバイダーに、新しいCCMモデルに移行させるような計画があります。
|
||||
クラウドコントローラーマネージャーの設計は「プラグインメカニズム」をベースにしています。そうすることで、新しいクラウドプロバイダーがプラグインを使ってKubernetesと簡単に統合できるようになります。新しいクラウドプロバイダーに向けてKubernetesのオンボーディングを行ったり、古いモデルを利用しているクラウドプロバイダーに、新しいCCMモデルに移行させるような計画があります。
|
||||
|
||||
このドキュメントでは、クラウドコントローラーマネージャーの背景にあるコンセプトと、それに関連する機能の詳細について話します。
|
||||
|
||||
@@ -79,11 +79,11 @@ CCMの大半の機能は、KCMから派生しています。前セクション
|
||||
|
||||
#### ルートコントローラー
|
||||
|
||||
ルートコントローラーは、クラスタ内の異なるノード上で稼働しているコンテナが相互に通信出来るように、クラウド内のルートを適切に設定する責務を持ちます。ルートコントローラーはGoogle Compute Engineのクラスターのみに該当します。
|
||||
ルートコントローラーは、クラスタ内の異なるノード上で稼働しているコンテナが相互に通信できるように、クラウド内のルートを適切に設定する責務を持ちます。ルートコントローラーはGoogle Compute Engineのクラスターのみに該当します。
|
||||
|
||||
#### サービスコントローラー
|
||||
|
||||
サービスコントローラーは、サービスの作成、更新、そして削除イベントの待ち受けに責務を持ちます。Kubernetes内のサービスの現在の状態を、クラウド上のロードバランサー(ELB、Google LB、またOracle Cloud Infrastructure LBなど)に反映するための設定を行います。更に、クラウドロードバランサーのバックエンドが最新の状態になっていることを保証します。
|
||||
サービスコントローラーは、サービスの作成、更新、そして削除イベントの待ち受けに責務を持ちます。Kubernetes内のサービスの現在の状態を、クラウド上のロードバランサー(ELB、Google LB、またOracle Cloud Infrastructure LBなど)に反映するための設定を行います。さらに、クラウドロードバランサーのバックエンドが最新の状態になっていることを保証します。
|
||||
|
||||
### 2. Kubelet
|
||||
|
||||
@@ -93,7 +93,7 @@ CCMの大半の機能は、KCMから派生しています。前セクション
|
||||
|
||||
## プラグインメカニズム
|
||||
|
||||
クラウドコントローラーマネージャーは、Goのインターフェースを利用してクラウドの実装をプラグイン化出来るようにしています。具体的には、[こちら](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62)で定義されているクラウドプロバイダーインターフェースを利用しています。
|
||||
クラウドコントローラーマネージャーは、Goのインターフェースを利用してクラウドの実装をプラグイン化できるようにしています。具体的には、[こちら](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62)で定義されているクラウドプロバイダーインターフェースを利用しています。
|
||||
|
||||
上で強調した4つの共有コントローラーの実装、そしていくつかの共有クラウドプロバイダーインターフェースと一部の連携機能は、Kubernetesのコアにとどまります。クラウドプロバイダー特有の実装はコア機能外で構築され、コア機能内で定義されたインターフェースを実装します。
|
||||
|
||||
|
||||
@@ -6,8 +6,8 @@ weight: 20
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
本ドキュメントでは、KubernetesにおけるMaster(実態はAPIサーバー)及びクラスター間のコミュニケーション経路についてまとめます。
|
||||
この文書の目的は、信頼できないネットワーク上（またはクラウドプロバイダ上の完全にパブリックなIP上）でクラスタを実行できるように、ユーザーがインストールをカスタマイズしてネットワーク構成を強化できるようにすることです。
|
||||
本ドキュメントでは、KubernetesにおけるMaster(実態はAPIサーバー)およびクラスター間のコミュニケーション経路についてまとめます。
|
||||
この文書の目的は、信頼できないネットワーク上(またはクラウドプロバイダ上の完全にパブリックなIP上)でクラスタを実行できるように、ユーザーがインストールをカスタマイズしてネットワーク構成を強化できるようにすることです。
|
||||
|
||||
|
||||
|
||||
@@ -16,8 +16,8 @@ weight: 20
|
||||
|
||||
## クラスターからマスターへの通信
|
||||
|
||||
クラスターからマスターへのすべての通信経路は、APIサーバーで終端します（他のマスターコンポーネントはどれもリモートサービスを公開するように設計されていません）。
|
||||
一般的には、1つ以上の形式のクライアント[認証](/docs/reference/access-authn-authz/authentication/)が有効になっている状態で、APIサーバーはセキュアなHTTPSポート（443）でリモート接続をlistenするように構成されています。
|
||||
クラスターからマスターへのすべての通信経路は、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サーバーに接続できるように、クラスターのパブリックなルート証明書をプロビジョニングする必要があります。
|
||||
@@ -26,15 +26,15 @@ kubeletのクライアント証明書を自動プロビジョニングする方
|
||||
|
||||
APIサーバーに接続したいPodは、サービスアカウントを利用することで接続を安全にすることができます。そうすることで、Podが作成されたときにKubernetesがパブリックなルート証明書と有効なBearer TokenをPodに自動的に挿入します。
|
||||
|
||||
`kubernetes`サービスには（すべてのネームスペースで）、APIサーバー上のHTTPSエンドポイントに（kube-proxy経由で）リダイレクトされる仮想IPアドレスが設定されています。
|
||||
`kubernetes`サービスには(すべてのネームスペースで)、APIサーバー上のHTTPSエンドポイントに(kube-proxy経由で)リダイレクトされる仮想IPアドレスが設定されています。
|
||||
|
||||
マスターコンポーネントは、セキュアなポートを介してクラスターAPIサーバーとも通信します。
|
||||
|
||||
その結果、クラスター（ノードとそのノードで実行されているPod）からマスターへの接続はデフォルトで保護され、信頼できないネットワークやパブリックネットワークを介して実行できます。
|
||||
その結果、クラスター(ノードとそのノードで実行されているPod)からマスターへの接続はデフォルトで保護され、信頼できないネットワークやパブリックネットワークを介して実行できます。
|
||||
|
||||
## マスターからクラスターへの通信
|
||||
|
||||
マスター（APIサーバー）からクラスターへの通信には、2つの主要な通信経路があります。
|
||||
マスター(APIサーバー)からクラスターへの通信には、2つの主要な通信経路があります。
|
||||
1つ目は、APIサーバーからクラスター内の各ノードで実行されるkubeletプロセスへの通信です。
|
||||
2つ目は、APIサーバーのプロキシ機能を介した、APIサーバーから任意のノード、Pod、またはサービスへのアクセスです。
|
||||
|
||||
@@ -43,7 +43,7 @@ APIサーバーに接続したいPodは、サービスアカウントを利用
|
||||
APIサーバーからkubeletへの接続は以下の目的で使用されます:
|
||||
|
||||
* Podのログを取得する
|
||||
* 実行中のPodに（kubectlを通して）接続する
|
||||
* 実行中のPodに(kubectlを通して)接続する
|
||||
* kubeletのポート転送機能を提供する
|
||||
|
||||
これらの接続は、kubeletのHTTPSエンドポイントで終了します。
|
||||
@@ -64,7 +64,7 @@ API URL内のノード、Pod、またはサービス名に`https:`を付ける
|
||||
### SSHトンネル
|
||||
|
||||
Kubernetesはマスターからクラスターへの通信経路を保護するためにSSHトンネルをサポートしています。
|
||||
この設定では、APIサーバーはクラスター内の各ノード（ポート22でlistenしているsshサーバーに接続）へのSSHトンネルを開始し、トンネルを介してkubelet、ノード、Pod、またはサービス宛てのすべてのトラフィックを渡します。
|
||||
この設定では、APIサーバーはクラスター内の各ノード(ポート22でlistenしているsshサーバーに接続)へのSSHトンネルを開始し、トンネルを介してkubelet、ノード、Pod、またはサービス宛てのすべてのトラフィックを渡します。
|
||||
このトンネルにより、ノードが実行されているネットワークの外部にトラフィックが公開されないようにします。
|
||||
|
||||
SSHトンネルは現在非推奨なので、自分がしていることが分からない限り、使用しないでください。この通信チャネルに代わるものが設計されています。
|
||||
|
||||
Reference in New Issue
Block a user