whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'dev-1.17-ja.3' into fix-22359

Browse Source
This commit is contained in:
hikkie3110
2020-07-28 15:51:57 +09:00
committed by GitHub
parent 7d70644720 dc90225ada
commit b1bf36fafc
1403 changed files with 43015 additions and 24406 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ja/docs/concepts/architecture/cloud-controller.md
+5 -5
View File
@@ -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のコアにとどまります。クラウドプロバイダー特有の実装はコア機能外で構築され、コア機能内で定義されたインターフェースを実装します。
content/ja/docs/concepts/architecture/master-node-communication.md
+9 -9
View File
@@ -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トンネルは現在非推奨なので、自分がしていることが分からない限り、使用しないでください。この通信チャネルに代わるものが設計されています。
content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md
+5 -5
View File
@@ -16,13 +16,13 @@ Kubernetesクラスターの計画、セットアップ、設定の例を知る
ガイドを選択する前に、いくつかの考慮事項を挙げます。
- ユーザーのコンピューター上でKubernetesを試したいでしょうか、それとも高可用性のあるマルチノードクラスターを構築したいでしょうか? あなたのニーズにあったディストリビューションを選択してください。
- ユーザーのコンピューター上でKubernetesを試したいでしょうか、それとも高可用性のあるマルチノードクラスターを構築したいでしょうか？あなたのニーズにあったディストリビューションを選択してください。
- **もしあなたが高可用性を求める場合**、 [複数ゾーンにまたがるクラスター](/docs/concepts/cluster-administration/federation/)の設定について学んでください。
- [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/)のような**ホストされているKubernetesクラスター**を使用するのか、それとも**自分自身でクラスターをホストするのでしょうか**?
- 使用するクラスターは**オンプレミス**なのか、それとも**クラウド (IaaS)**でしょうか? Kubernetesはハイブリッドクラスターを直接サポートしていません。その代わりユーザーは複数のクラスターをセットアップできます。
- Kubernetesを**"ベアメタル"なハードウェア** 上で稼働させますか? それとも**仮想マシン (VMs)** 上で稼働させますか?
- [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/)のような**ホストされているKubernetesクラスター**を使用するのか、それとも**自分自身でクラスターをホストするのでしょうか**？
- 使用するクラスターは**オンプレミス**なのか、それとも**クラウド(IaaS)** でしょうか？Kubernetesはハイブリッドクラスターを直接サポートしていません。その代わりユーザーは複数のクラスターをセットアップできます。
- Kubernetesを **「ベアメタル」なハードウェア**上で稼働させますか？それとも**仮想マシン(VMs)** 上で稼働させますか？
- **もしオンプレミスでKubernetesを構築する場合**、どの[ネットワークモデル](/ja/docs/concepts/cluster-administration/networking/)が最適か検討してください。
- **ただクラスターを稼働させたいだけ**でしょうか、それとも**Kubernetesプロジェクトのコードの開発**を行いたいでしょうか? もし後者の場合、開発が進行中のディストリビューションを選択してください。いくつかのディストリビューションはバイナリリリースのみ使用していますが、多くの選択肢があります。
- **ただクラスターを稼働させたいだけ**でしょうか、それとも**Kubernetesプロジェクトのコードの開発**を行いたいでしょうか？もし後者の場合、開発が進行中のディストリビューションを選択してください。いくつかのディストリビューションはバイナリリリースのみ使用していますが、多くの選択肢があります。
- クラスターを稼働させるのに必要な[コンポーネント](/ja/docs/concepts/overview/components/)についてよく理解してください。
注意: 全てのディストリビューションがアクティブにメンテナンスされている訳ではありません。最新バージョンのKubernetesでテストされたディストリビューションを選択してください。
content/ja/docs/concepts/cluster-administration/networking.md
+2 -3
View File
@@ -81,7 +81,7 @@ Details on how the AOS system works can be accessed here: http://www.apstra.com/
[AWS VPC CNI](https://github.com/aws/amazon-vpc-cni-k8s)は、Kubernetesクラスター向けの統合されたAWS Virtual Private Cloud(VPC)ネットワーキングを提供します。このCNIプラグインは、高いスループットと可用性、低遅延、および最小のネットワークジッタを提供します。さらに、ユーザーは、Kubernetesクラスターを構築するための既存のAWS VPCネットワーキングとセキュリティのベストプラクティスを適用できます。これには、ネットワークトラフィックの分離にVPCフローログ、VPCルーティングポリシー、およびセキュリティグループを使用する機能が含まれます。
このCNIプラグインを使用すると、Kubernetes PodはVPCネットワーク上と同じIPアドレスをPod内に持つことができます。CNIはAWS Elastic Networking Interfaces（ENI）を各Kubernetesノードに割り当て、ノード上のPodに各ENIのセカンダリIP範囲を使用します。このCNIには、Podの起動時間を短縮するためのENIとIPアドレスの事前割り当ての制御が含まれており、最大2,000ノードの大規模クラスターが可能です。
このCNIプラグインを使用すると、Kubernetes PodはVPCネットワーク上と同じIPアドレスをPod内に持つことができます。CNIはAWS Elastic Networking Interface(ENI)を各Kubernetesノードに割り当て、ノード上のPodに各ENIのセカンダリIP範囲を使用します。このCNIには、Podの起動時間を短縮するためのENIとIPアドレスの事前割り当ての制御が含まれており、最大2,000ノードの大規模クラスターが可能です。
さらに、このCNIは[ネットワークポリシーの適用のためにCalico](https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/calico.html)と一緒に実行できます。AWS VPC CNIプロジェクトは、[GitHubのドキュメント](https://github.com/aws/amazon-vpc-cni-k8s)とともにオープンソースで公開されています。
@@ -89,7 +89,7 @@ Details on how the AOS system works can be accessed here: http://www.apstra.com/
[Azure CNI](https://docs.microsoft.com/en-us/azure/virtual-network/container-networking-overview) is an [open source](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md) plugin that integrates Kubernetes Pods with an Azure Virtual Network (also known as VNet) providing network performance at par with VMs. Pods can connect to peered VNet and to on-premises over Express Route or site-to-site VPN and are also directly reachable from these networks. Pods can access Azure services, such as storage and SQL, that are protected by Service Endpoints or Private Link. You can use VNet security policies and routing to filter Pod traffic. The plugin assigns VNet IPs to Pods by utilizing a pool of secondary IPs pre-configured on the Network Interface of a Kubernetes node.
Azure CNI is available natively in the [Azure Kubernetes Service (AKS)] (https://docs.microsoft.com/en-us/azure/aks/configure-azure-cni).
### Big Cloud Fabric from Big Switch Networks
@@ -289,4 +289,3 @@ to run, and in both cases, the network provides one IP address per pod - as is s
ネットワークモデルの初期設計とその根拠、および将来の計画については、[ネットワーク設計ドキュメント](https://git.k8s.io/community/contributors/design-proposals/network/networking.md)で詳細に説明されています。
content/ja/docs/concepts/configuration/assign-pod-node.md
+1 -1
View File
@@ -211,7 +211,7 @@ PodアフィニティとPodアンチアフィニティで使用できるオペ
#### 実際的なユースケース
Pod間アフィニティとアンチアフィニティは、ReplicaSet、StatefulSet、Deploymentなどのより高レベルなコレクションと併せて使用すると更に有用です。
Pod間アフィニティとアンチアフィニティは、ReplicaSet、StatefulSet、Deploymentなどのより高レベルなコレクションと併せて使用するとさらに有用です。
Workloadが、Node等の定義された同じトポロジーに共存させるよう、簡単に設定できます。
content/ja/docs/concepts/configuration/overview.md
+2 -2
View File
@@ -31,7 +31,7 @@ weight: 10
- 可能な限り、"真っ裸"のPod([ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)や[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)にバインドされていないPod)は使わないでください。Nodeに障害が発生した場合、これらのPodは再スケジュールされません。
明示的に[`restartPolicy: Never`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)を使いたいシーンを除いて、DeploymentはPodを直接作成するよりもほとんど常に望ましい方法です。Deploymentには、希望する数のPodが常に使用可能であることを確認するためにReplicaSetを作成したり、Podを置き換えるための戦略（RollingUpdateなど）を指定したりできます。[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)のほうが適切な場合もあるかもしれません。
明示的に[`restartPolicy: Never`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)を使いたいシーンを除いて、DeploymentはPodを直接作成するよりもほとんど常に望ましい方法です。Deploymentには、希望する数のPodが常に使用可能であることを確認するためにReplicaSetを作成したり、Podを置き換えるための戦略(RollingUpdateなど)を指定したりできます。[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)のほうが適切な場合もあるかもしれません。
## Service
@@ -89,7 +89,7 @@ weight: 10
{{< /note >}}
{{< note >}}
ベースイメージのプロバイダーのキャッシュセマンティクスにより、`imagePullPolicy：Always`もより効率的になります。たとえば、Dockerでは、イメージが既に存在する場合すべてのイメージレイヤーがキャッシュされ、イメージのダウンロードが不要であるため、pullが高速になります。
ベースイメージのプロバイダーのキャッシュセマンティクスにより、`imagePullPolicy：Always`もより効率的になります。たとえば、Dockerでは、イメージがすでに存在する場合すべてのイメージレイヤーがキャッシュされ、イメージのダウンロードが不要であるため、pullが高速になります。
{{< /note >}}
## kubectlの使い方
content/ja/docs/concepts/containers/container-lifecycle-hooks.md
+1 -1
View File
@@ -30,7 +30,7 @@ Angularなどのコンポーネントライフサイクルフックを持つ多
`PreStop`
このフックは、liveness probeの失敗、プリエンプション、リソース競合などのAPI要求または管理イベントが原因でコンテナが終了する直前に呼び出されます。コンテナが既に終了状態または完了状態にある場合、preStopフックの呼び出しは失敗します。
このフックは、liveness probeの失敗、プリエンプション、リソース競合などのAPI要求または管理イベントが原因でコンテナが終了する直前に呼び出されます。コンテナがすでに終了状態または完了状態にある場合、preStopフックの呼び出しは失敗します。
これはブロッキング、つまり同期的であるため、コンテナを削除するための呼び出しを送信する前に完了する必要があります。
ハンドラーにパラメーターは渡されません。
content/ja/docs/concepts/containers/runtime-class.md
+3 -3
View File
@@ -29,7 +29,7 @@ RuntimeClassはコンテナランタイムの設定を選択するための機
RuntimeClass機能のフィーチャーゲートが有効になっていることを確認してください(デフォルトで有効です)。フィーチャーゲートを有効にする方法については、[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を参照してください。
その`RuntimeClass`のフィーチャーゲートはApiServerとkubeletのどちらも有効になっていなければなりません。
1. ノード上でCRI実装を設定する。（ランタイムに依存）
1. ノード上でCRI実装を設定する。(ランタイムに依存)
2. 対応するRuntimeClassリソースを作成する。
#### 1. ノード上でCRI実装を設定する。
@@ -129,7 +129,7 @@ CRI-Oの[設定に関するドキュメント][100]の詳細は下記を参照
Kubernetes 1.16では、RuntimeClassは`scheduling`フィールドを使ったクラスター内での異なる設定をサポートしています。
このフィールドによって、設定されたRuntimeClassをサポートするノードに対してPodがスケジュールされることを保証できます。
スケジューリングをサポートするためにはRuntimeClass [アドミッションコントローラー][]を有効にしなければなりません。（1.16ではデフォルトです）
スケジューリングをサポートするためにはRuntimeClass [アドミッションコントローラー][]を有効にしなければなりません。(1.16ではデフォルトです)
特定のRuntimeClassをサポートしているノードへPodが配置されることを保証するために、各ノードは`runtimeclass.scheduling.nodeSelector`フィールドによって選択される共通のラベルを持つべきです。
RuntimeClassのnodeSelectorはアドミッション機能によりPodのnodeSelectorに統合され、効率よくノードを選択します。
@@ -147,7 +147,7 @@ RuntimeClassのnodeSelectorはアドミッション機能によりPodのnodeSele
{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
Kubernetes 1.16ではRuntimeClassは[`PodOverhead`](/docs/concepts/configuration/pod-overhead/)機能の一部である、Podが稼働する時に関連するオーバーヘッドを指定することをサポートしています。
`PodOverhead`を使うためには、PodOverhead[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にしなければなりません。（デフォルトではoffです）
`PodOverhead`を使うためには、PodOverhead[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にしなければなりません。(デフォルトではoffです)
PodのオーバーヘッドはRuntimeClass内の`Overhead`フィールドによって定義されます。
このフィールドを使用することで、RuntimeClassを使用して稼働するPodのオーバーヘッドを指定することができ、Kubernetes内部で使用されるオーバーヘッドを確保することができます。
content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
+4 -4
View File
@@ -67,7 +67,7 @@ APIが宣言的ではない兆候として、次のものがあります:
- APIをオブジェクトとして簡単に表現できない
- 停止している処理を処理ID、もしくは処理オブジェクトで表現することを選択している
## ConfigMapとカスタムリソースのどちらを使うべきか?
## ConfigMapとカスタムリソースのどちらを使うべきか？
下記のいずれかに該当する場合は、ConfigMapを使ってください:
@@ -99,7 +99,7 @@ Kubernetesは、クラスターへカスタムリソースを追加する2つの
Kubernetesは、さまざまなユーザーのニーズを満たすためにこれら2つのオプションを提供しており、使いやすさや柔軟性が損なわれることはありません。
アグリゲートAPIは、プロキシーとして機能するプライマリAPIサーバーの背後にある、下位のAPIServerです。このような配置は[APIアグリゲーション](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) (AA)と呼ばれています。ユーザーにとっては、単にAPIサーバーが拡張されているように見えます。
アグリゲートAPIは、プロキシーとして機能するプライマリAPIサーバーの背後にある、下位のAPIServerです。このような配置は[APIアグリゲーション](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)(AA)と呼ばれています。ユーザーにとっては、単にAPIサーバーが拡張されているように見えます。
CRDでは、APIサーバーの追加なしに、ユーザーが新しい種類のリソースを作成できます。CRDを使うには、APIアグリゲーションを理解する必要はありません。
@@ -156,7 +156,7 @@ CRDは、アグリゲートAPIと比べ、簡単に作れます。
| その他のサブリソース | "logs"や"exec"のような、CRUD以外の処理の追加 | いいえ | はい |
| strategic-merge-patch |`Content-Type: application/strategic-merge-patch+json`で、PATCHをサポートする新しいエンドポイント。ローカル、サーバー、どちらでも更新されうるオブジェクトに有用。さらなる情報は["APIオブジェクトをkubectl patchで決まった場所で更新"](/docs/tasks/run-application/update-api-object-kubectl-patch/)を参照 | いいえ | はい |
| プロトコルバッファ | プロトコルバッファを使用するクライアントをサポートする新しいリソース | いいえ | はい |
| OpenAPIスキーマ | サーバーから動的に取得できる型のOpenAPI(スワッガー)スキーマはあるか、許可されたフィールドのみが設定されるようにすることで、ユーザーはフィールド名のスペルミスから保護されているか、型は強制されているか(言い換えると、「文字列」フィールドに「int」を入れさせない) | はい、[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) スキーマがベース(1.16でGA) | はい |
| OpenAPIスキーマ | サーバーから動的に取得できる型のOpenAPI(Swagger)スキーマはあるか、許可されたフィールドのみが設定されるようにすることで、ユーザーはフィールド名のスペルミスから保護されているか、型は強制されているか(言い換えると、「文字列」フィールドに「int」を入れさせない) | はい、[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) スキーマがベース(1.16でGA) | はい |
### 一般的な機能
@@ -185,7 +185,7 @@ CRD、またはアグリゲートAPI、どちらを使ってカスタムリソ
### サードパーティのコードと新しい障害点
CRDを作成しても、勝手に新しい障害点が追加されてしまうことはありませんが（たとえば、サードパーティのコードをAPIサーバーで実行することによって）、パッケージ（たとえば、チャート）またはその他のインストールバンドルには、多くの場合、CRDと新しいカスタムリソースのビジネスロジックを実装するサードパーティコードが入ったDeploymentが含まれます。
CRDを作成しても、勝手に新しい障害点が追加されてしまうことはありませんが(たとえば、サードパーティのコードをAPIサーバーで実行することによって)、パッケージ(たとえば、Chart)またはその他のインストールバンドルには、多くの場合、CRDと新しいカスタムリソースのビジネスロジックを実装するサードパーティコードが入ったDeploymentが含まれます。
アグリゲートAPIサーバーのインストールすると、常に新しいDeploymentが付いてきます。
content/ja/docs/concepts/extend-kubernetes/extend-cluster.md
+7 -7
View File
@@ -32,7 +32,7 @@ Kubernetesは柔軟な設定が可能で、高い拡張性を持っています
ホスティングされたKubernetesサービスやマネージドなKubernetesでは、フラグと設定ファイルが常に変更できるとは限りません。変更可能な場合でも、通常はクラスターの管理者のみが変更できます。また、それらは将来のKubernetesバージョンで変更される可能性があり、設定変更にはプロセスの再起動が必要になるかもしれません。これらの理由により、この方法は他の選択肢が無いときにのみ利用するべきです。
[ResourceQuota](/docs/concepts/policy/resource-quotas/)、[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)、[NetworkPolicy](/docs/concepts/services-networking/network-policies/)、そしてロールベースアクセス制御([RBAC](/docs/reference/access-authn-authz/rbac/))といった *ビルトインポリシーAPI* は、ビルトインのKubernetes APIです。APIは通常、ホスティングされたKubernetesサービスやマネージドなKubernetesで利用されます。これらは宣言的で、Podのような他のKubernetesリソースと同じ慣例に従っています。そのため、新しいクラスターの設定は繰り返し再利用することができ、アプリケーションと同じように管理することが可能です。更に、安定版（stable）を利用している場合、他のKubernetes APIのような[定義済みのサポートポリシー](/docs/reference/deprecation-policy/)を利用することができます。これらの理由により、この方法は、適切な用途の場合、 *設定ファイル* や *フラグ* よりも好まれます。
[ResourceQuota](/docs/concepts/policy/resource-quotas/)、[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)、[NetworkPolicy](/docs/concepts/services-networking/network-policies/)、そしてロールベースアクセス制御([RBAC](/docs/reference/access-authn-authz/rbac/))といった *ビルトインポリシーAPI* は、ビルトインのKubernetes APIです。APIは通常、ホスティングされたKubernetesサービスやマネージドなKubernetesで利用されます。これらは宣言的で、Podのような他のKubernetesリソースと同じ慣例に従っています。そのため、新しいクラスターの設定は繰り返し再利用することができ、アプリケーションと同じように管理することが可能です。さらに、安定版(stable)を利用している場合、他のKubernetes APIのような[定義済みのサポートポリシー](/docs/reference/deprecation-policy/)を利用することができます。これらの理由により、この方法は、適切な用途の場合、 *設定ファイル* や *フラグ* よりも好まれます。
## エクステンション
@@ -57,8 +57,8 @@ Kubernetes上でうまく動くクライアントプログラムを書くため
呼び出されるサービスは *Webhookバックエンド* と呼ばれます。コントローラーのように、Webhookも障害点を追加します。
Webhookのモデルでは、Kubernetesは外部のサービスを呼び出します。
*バイナリプラグイン* モデルでは、Kubernetesはバイナリ（プログラム）を実行します。
バイナリプラグインはkubelet（例、[FlexVolumeプラグイン](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md)、[ネットワークプラグイン](/docs/concepts/cluster-administration/network-plugins/)）、またkubectlで利用されています。
*バイナリプラグイン* モデルでは、Kubernetesはバイナリ(プログラム)を実行します。
バイナリプラグインはkubelet(例、[FlexVolumeプラグイン](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md)、[ネットワークプラグイン](/docs/concepts/cluster-administration/network-plugins/))、またkubectlで利用されています。
下図は、それぞれの拡張ポイントが、Kubernetesのコントロールプレーンとどのように関わっているかを示しています。
@@ -103,7 +103,7 @@ Webhookのモデルでは、Kubernetesは外部のサービスを呼び出しま
### ビルトインリソースの変更
カスタムリソースを追加し、KubernetesAPIを拡張する場合、新たに追加されたリソースは常に新しいAPIグループに分類されます。既存のAPIグループを置き換えたり、変更することはできません。APIを追加することは直接、既存のAPI（例、Pod）の振る舞いに影響を与えることは無いですが、APIアクセスエクステンションの場合、その可能性があります。
カスタムリソースを追加し、KubernetesAPIを拡張する場合、新たに追加されたリソースは常に新しいAPIグループに分類されます。既存のAPIグループを置き換えたり、変更することはできません。APIを追加することは直接、既存のAPI(例、Pod)の振る舞いに影響を与えることは無いですが、APIアクセスエクステンションの場合、その可能性があります。
### APIアクセスエクステンション
@@ -111,7 +111,7 @@ Webhookのモデルでは、Kubernetesは外部のサービスを呼び出しま
これらの各ステップごとに拡張ポイントが用意されています。
Kubdernetesはいくつかのビルトイン認証方式をサポートしています。それは認証プロキシの後ろに配置することも可能で、認可ヘッダーを通じて（Webhookの）検証のために外部サービスにトークンを送ることもできます。全てのこれらの方法は[認証ドキュメント](/docs/reference/access-authn-authz/authentication/)でカバーされています。
Kubdernetesはいくつかのビルトイン認証方式をサポートしています。それは認証プロキシの後ろに配置することも可能で、認可ヘッダーを通じて(Webhookの)検証のために外部サービスにトークンを送ることもできます。全てのこれらの方法は[認証ドキュメント](/docs/reference/access-authn-authz/authentication/)でカバーされています。
### 認証
@@ -138,7 +138,7 @@ Kubernetesはいくつかのビルトイン認証方式と、それらが要件
### デバイスプラグイン
[デバイスプラグイン](/docs/concepts/cluster-administration/device-plugins/)を通じて、ノードが新たなノードのリソース（CPU、メモリなどのビルトインのものに加え）を見つけることを可能にします。
[デバイスプラグイン](/docs/concepts/cluster-administration/device-plugins/)を通じて、ノードが新たなノードのリソース(CPU、メモリなどのビルトインのものに加え)を見つけることを可能にします。
### ネットワークプラグイン
@@ -150,7 +150,7 @@ Kubernetesはいくつかのビルトイン認証方式と、それらが要件
これはかなりの大きな作業で、ほとんど全てのKubernetesユーザーはスケジューラーを変更する必要はありません。
スケジューラは[Webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)もサポートしており、Webhookバックエンド（スケジューラーエクステンション）を通じてPodを配置するために選択されたノードをフィルタリング、優先度付けすることが可能です。
スケジューラは[Webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)もサポートしており、Webhookバックエンド(スケジューラーエクステンション)を通じてPodを配置するために選択されたノードをフィルタリング、優先度付けすることが可能です。
content/ja/docs/concepts/extend-kubernetes/operator.md
+1 -1
View File
@@ -24,7 +24,7 @@ Kubernetes上でワークロードを稼働させている人は、しばしば
## Kubernetesにおけるオペレーター
Kubernetesは自動化のために設計されています。追加の作業、設定無しに、Kubernetesのコア機能によって多数のビルトインされた自動化機能が提供されます。
ワークロードのデプロイ及び稼働を自動化するためにKubernetesを使うことができます。 *更に* Kubernetesがそれをどのように行うかの自動化も可能です。
ワークロードのデプロイおよび稼働を自動化するためにKubernetesを使うことができます。 *さらに* Kubernetesがそれをどのように行うかの自動化も可能です。
Kubernetesの{{< glossary_tooltip text="コントローラー" term_id="controller" >}}コンセプトは、Kubernetesのソースコードを修正すること無く、クラスターの振る舞いを拡張することを可能にします。
オペレーターはKubernetes APIのクライアントで、[Custom Resource](/docs/concepts/api-extension/custom-resources/)にとっての、コントローラーのように振る舞います。
content/ja/docs/concepts/overview/kubernetes-api.md
+11 -11
View File
@@ -16,7 +16,7 @@ APIエンドポイント、リソースタイプ、そしてサンプルは[API
APIへの外部からのアクセスは、[APIアクセス制御ドキュメント](/docs/reference/access-authn-authz/controlling-access/)に記載されています。
Kubernetes APIは、システムの宣言的設定スキーマの基礎としても機能します。[kubectl](/docs/reference/kubectl/overview/)コマンドラインツールから、APIオブジェクトを作成、更新、削除、取得することが出来ます。
Kubernetes APIは、システムの宣言的設定スキーマの基礎としても機能します。[kubectl](/docs/reference/kubectl/overview/)コマンドラインツールから、APIオブジェクトを作成、更新、削除、取得することができます。
また、Kubernetesは、シリアライズされた状態を(現在は[etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/)に)APIリソースの単位で保存しています。
@@ -41,10 +41,10 @@ Kubernetes 1.10から、KubernetesAPIサーバーは`/openapi/v2`のエンドポ
ヘッダ | 設定可能な値
------ | ---------------
Accept | `application/json`, `application/com.github.proto-openapi.spec.v2@v1.0+protobuf` （デフォルトのcontent-typeは、`*/*`に対して`application/json`か、もしくはこのヘッダーを送信しません）
Accept-Encoding | `gzip` （このヘッダーを送信しないことも許容されています）
Accept | `application/json`, `application/com.github.proto-openapi.spec.v2@v1.0+protobuf` (デフォルトのcontent-typeは、`*/*`に対して`application/json`か、もしくはこのヘッダーを送信しません)
Accept-Encoding | `gzip` (このヘッダーを送信しないことも許容されています)
1.14より前のバージョンでは、フォーマット分離エンドポイント（`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`）が、OpenAPI仕様を違うフォーマットで提供しています。これらのエンドポイントは非推奨となっており、Kubernetes1.14で削除されました。
1.14より前のバージョンでは、フォーマット分離エンドポイント(`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`)が、OpenAPI仕様を違うフォーマットで提供しています。これらのエンドポイントは非推奨となっており、Kubernetes1.14で削除されました。
**OpenAPI仕様の取得サンプル**:
@@ -67,16 +67,16 @@ APIが、システムリソースと動作について明確かつ一貫した
APIとソフトウエアのバージョニングは、間接的にしか関連していないことに注意してください。[APIとリリースバージョニング提案](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)で、APIとソフトウェアのバージョニングの関連について記載しています。
異なるバージョンのAPIは、異なるレベル（版）の安定性とサポートを持っています。それぞれのレベル（版）の基準は、[API変更ドキュメント](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)に詳細が記載されています。下記に簡潔にまとめます:
異なるバージョンのAPIでは、安定性やサポートのレベルも変わります。各レベルの詳細な条件は、[API変更ドキュメント](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)に記載されています。下記に簡潔にまとめます:
- アルファレベル（版）:
- バージョン名に`alpha`を含みます（例、`v1alpha1`）。
- アルファレベル(版):
- バージョン名に`alpha`を含みます(例、`v1alpha1`)。
- バグが多いかもしれません。アルファ機能の有効化がバグを顕在化させるかもしれません。デフォルトでは無効となっています。
- アルファ機能のサポートは、いつでも通知無しに取りやめられる可能性があります。
- ソフトウェアリリース後、APIが通知無しに互換性が無い形で変更される可能性があります。
- バグが増えるリスク、また長期サポートが無いことから、短期間のテスト用クラスターでの利用を推奨します。
- ベータレベル（版）:
- バージョン名に`beta`を含みます（例、`v2beta3`）。
- ベータレベル(版):
- バージョン名に`beta`を含みます(例、`v2beta3`)。
- コードは十分にテストされています。ベータ機能の有効化は安全だと考えられます。デフォルトで有効化されています。
- 全体的な機能のサポートは取りやめられませんが、詳細は変更される可能性があります。
- オブジェクトのスキーマ、意味はその後のベータ、安定版リリースで互換性が無い形で変更される可能性があります。その場合、次のバージョンへアップデートするための手順を提供します。その手順ではAPIオブジェクトの削除、修正、再作成が必要になるかもしれません。修正のプロセスは多少の検討が必要になるかもしれません。これは、この機能を利用しているアプリケーションでダウンタイムが必要になる可能性があるためです。
@@ -93,9 +93,9 @@ APIグループは、RESTのパスとシリアライズされたオブジェク
現在、いくつかのAPIグループが利用されています:
1. *core* グループ（度々、*legacy group* と呼ばれます）は、`/api/v1`というRESTのパスで、`apiVersion: v1`を使います。
1. *core* グループ(たびたび、*legacy group* と呼ばれます)は、`/api/v1`というRESTのパスで、`apiVersion: v1`を使います。
1. 名前付きのグループは、`/apis/$GROUP_NAME/$VERSION`というRESTのパスで、`apiVersion: $GROUP_NAME/$VERSION`（例、`apiVersion: batch/v1`）を使います。サポートされているAPIグループの全リストは、[Kubernetes APIリファレンス](/docs/reference/)を参照してください。
1. 名前付きのグループは、`/apis/$GROUP_NAME/$VERSION`というRESTのパスで、`apiVersion: $GROUP_NAME/$VERSION`(例、`apiVersion: batch/v1`)を使います。サポートされているAPIグループの全リストは、[Kubernetes APIリファレンス](/docs/reference/)を参照してください。
[カスタムリソース](/docs/concepts/api-extension/custom-resources/)でAPIを拡張するために、2つの方法がサポートされています:
content/ja/docs/concepts/overview/what-is-kubernetes.md
+56 -71
View File
@@ -1,8 +1,11 @@
---
reviewers:
title: Kubernetesとは何か？
description: >
Kubernetesは、宣言的な構成管理と自動化を促進し、コンテナ化されたワークロードやサービスを管理するための、ポータブルで拡張性のあるオープンソースのプラットフォームです。Kubernetesは巨大で急速に成長しているエコシステムを備えており、それらのサービス、サポート、ツールは幅広い形で利用可能です。
content_type: concept
weight: 10
card:
card:
name: concepts
weight: 10
---
@@ -12,94 +15,76 @@ card:
<!-- body -->
Kubernetesは、宣言的な構成管理と自動化を促進し、コンテナ化されたワークロードやサービスを管理するための、ポータブルで拡張性のあるオープンソースプラットホームです。
Kubernetesは、宣言的な構成管理と自動化を促進し、コンテナ化されたワークロードやサービスを管理するための、ポータブルで拡張性のあるオープンソースのプラットフォームです。Kubernetesは巨大で急速に成長しているエコシステムを備えており、それらのサービス、サポート、ツールは幅広い形で利用可能です。
Kubernetesは膨大で、急速に成長しているエコシステムを備えており、それらのサービス、サポート、ツールは幅広い形で利用可能です。
Kubernetesの名称は、ギリシャ語に由来し、操舵手やパイロットを意味しています。Googleは2014年にKubernetesプロジェクトをオープンソース化しました。Kubernetesは、本番環境で大規模なワークロードを稼働させた[Googleの15年以上の経験](/blog/2015/04/borg-predecessor-to-kubernetes/)と、コミュニティからの最高のアイディアや実践を組み合わせています。
Googleは2014年にKubernetesプロジェクトをオープンソース化しました。Kubernetesは[Googleが大規模な本番ワークロードを動かしてきた10年半の経験](https://research.google.com/pubs/pub43438.html)と、コミュニティから得られた最善のアイデア、知見に基づいています。
## 過去を振り返ってみると
## なぜKubernetesが必要で、どんなことができるのか？
過去を振り返って、Kubernetesがなぜこんなに便利なのかを見てみましょう。
Kubernetesには多くの機能があります。考えられるものとしては
![Deployment evolution](/images/docs/Container_Evolution.svg)
- コンテナ基盤
- マイクロサービス基盤
- ポータブルなクラウド基盤
**仮想化ができる前の時代におけるデプロイ (Traditional deployment):** 初期の頃は、組織は物理サーバー上にアプリケーションを実行させていました。物理サーバー上でアプリケーションのリソース制限を設定する方法がなかったため、リソースの割当問題が発生していました。例えば、複数のアプリケーションを実行させた場合、ひとつのアプリケーションがリソースの大半を消費してしまうと、他のアプリケーションのパフォーマンスが低下してしまうことがありました。この解決方法は、それぞれのアプリケーションを別々の物理サーバーで動かすことでした。しかし、リソースが十分に活用できなかったため、拡大しませんでした。また組織にとって多くの物理サーバーを維持することは費用がかかりました。
など、他にもいろいろ
**仮想化を使ったデプロイ (Virtualized deployment):** ひとつの解決方法として、仮想化が導入されました。1台の物理サーバーのCPU上で、複数の仮想マシン(VM)を実行させることができるようになりました。仮想化によりアプリケーションをVM毎に隔離する事ができ、ひとつのアプリケーションの情報が他のアプリケーションから自由にアクセスさせないといったセキュリティレベルを提供することができます。
Kubernetesは、**コンテナを中心とした**管理基盤です。ユーザーワークロードの代表格であるコンピューティング、ネットワーキング、ストレージインフラストラクチャのオーケストレーションを行います。それによって、Platform as a Service(PaaS)の簡単さの大部分を、Infrastructure as a Service(IaaS)の柔軟さとともに提供し、インフラストラクチャプロバイダの垣根を超えたポータビリティを実現します。
仮想化により、物理サーバー内のリソース使用率が向上し、アプリケーションの追加や更新が容易になり、ハードウェアコストの削減などスケーラビリティが向上します。仮想化を利用すると、物理リソースのセットを使い捨て可能な仮想マシンのクラスターとして提示することができます。
## Kubernetesが基盤になるってどういうこと？
各VMは、仮想ハードウェア上で各自のOSを含んだ全コンポーネントを実行する完全なマシンです。
Kubernetesが多くの機能を提供すると言いつつも、新しい機能から恩恵を受ける新しいシナリオは常にあります。アプリケーション固有のワークフローを効率化して開発者のスピードを早めることができます。最初は許容できるアドホックなオーケストレーションでも、大規模で堅牢な自動化が必要となることはしばしばあります。これが、Kubernetesがアプリケーションのデプロイ、拡張、および管理を容易にするために、コンポーネントとツールのエコシステムを構築するための基盤としても機能するように設計された理由です。
**コンテナを使ったデプロイ (Container deployment):** コンテナはVMと似ていますが、アプリケーション間でオペレーティング・システム(OS)を共有できる緩和された分離特性を持っています。そのため、コンテナは軽量だといわれます。VMと同じように、コンテナは各自のファイルシステム、CPU、メモリー、プロセス空間等を持っています。基盤のインフラストラクチャから分離されているため、クラウドやOSディストリビューションを越えて移動することが可能です。
[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を使用すると、ユーザーは自分のリソースを整理できます。[アノテーション](/ja/docs/concepts/overview/working-with-objects/annotations/)を使用すると、ユーザーは自分のワークフローを容易にし、管理ツールが状態をチェックするための簡単な方法を提供するためにカスタムデータを使ってリソースを装飾できるようになります。
コンテナは、その他にも次のようなメリットを提供するため、人気が高まっています。
さらに、[Kubernetesコントロールプレーン](/ja/docs/concepts/overview/components/)は、開発者やユーザーが使える[API](/docs/reference/using-api/api-overview/)の上で成り立っています。ユーザーは[スケジューラー](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/scheduler.md)などの独自のコントローラーを、汎用の[コマンドラインツール](/docs/user-guide/kubectl-overview/)で使える[独自のAPI](/docs/concepts/api-extension/custom-resources/)を持たせて作成することができます。
* アジャイルアプリケーションの作成とデプロイ: VMイメージの利用時と比較して、コンテナイメージ作成の容易さと効率性が向上します。
* 継続的な開発、インテグレーションとデプロイ: 信頼できる頻繁なコンテナイメージのビルドと、素早く簡単にロールバックすることが可能なデプロイを提供します。(イメージが不変であれば)
* 開発者と運用者の関心を分離: アプリケーションコンテナイメージの作成は、デプロイ時ではなく、ビルド/リリース時に行います。それによって、インフラストラクチャとアプリケーションを分離します。
* 可観測性はOSレベルの情報とメトリクスだけではなく、アプリケーションの稼働状態やその他の警告も表示します。
* 開発、テスト、本番環境を越えた環境の一貫性: クラウドで実行させるのと同じようにノートPCでも実行させる事ができます。
* クラウドとOSディストリビューションの可搬性: Ubuntu、RHEL、CoreOS上でも、オンプレミスも、主要なパブリッククラウドでも、それ以外のどんな環境でも、実行できます。
* アプリケーション中心の管理: 仮想マシン上でOSを実行するから、論理リソースを使用してOS上でアプリケーションを実行するへと抽象度のレベルを向上させます。
* 疎結合、分散化、拡張性、柔軟性のあるマイクロサービス: アプリケーションを小さく、同時にデプロイと管理が可能な独立した部品に分割されます。1台の大きな単一目的のマシン上に実行するモノリシックなスタックではありません。
* リソースの分割: アプリケーションのパフォーマンスが予測可能です。
* リソースの効率的な利用: 高い効率性と集約性が可能です。
この[デザイン](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md)によって、他の多くのシステムがKubernetes上で構築できるようになりました。
## Kubernetesが必要な理由と提供する機能 {#why-you-need-kubernetes-and-what-can-it-do}
## Kubernetesにないこと
コンテナは、アプリケーションを集約して実行する良い方法です。本番環境では、アプリケーションを実行しダウンタイムが発生しないように、コンテナを管理する必要があります。例えば、コンテナがダウンした場合、他のコンテナを起動する必要があります。このような動作がシステムに組込まれていると、管理が簡単になるのではないでしょうか？
Kubernetesは伝統的な何でも入りのPaaSシステムではありません。Kubernetesはハードウェアレベルではなくコンテナレベルで動作するため、PaaS製品が提供するような、共通のいくつかの一般的に適用可能な機能(デプロイ、拡張、負荷分散、ログ記録、監視など)を提供します。ただし、Kubernetesはモノリシックではなく、これらのデフォルトのソリューションは任意に脱着可能です。Kubernetesは開発者の基盤を構築するための構成要素を提供しますが、重要な場合はユーザーの選択と柔軟性を維持します。
そこを助けてくれるのがKubernetesです! Kubernetesは分散システムを弾力的に実行するフレームワークを提供してくれます。あなたのアプリケーションのためにスケーリングとフェイルオーバーの面倒を見てくれて、デプロイのパターンなどを提供します。例えば、Kubernetesはシステムにカナリアデプロイを簡単に管理することができます。
Kubernetesは以下を提供します。
* **サービスディスカバリーと負荷分散**
Kubernetesは、DNS名または独自のIPアドレスを使ってコンテナを公開することができます。コンテナへのトラフィックが多い場合は、Kubernetesは負荷分散し、ネットワークトラフィックを振り分けることができるたため、デプロイが安定します。
* **ストレージ オーケストレーション**
Kubernetesは、ローカルストレージやパブリッククラウドプロバイダーなど、選択したストレージシステムを自動でマウントすることができます。
* **自動化されたロールアウトとロールバック**
Kubernetesを使うとデプロイしたコンテナのあるべき状態を記述することができ、制御されたスピードで実際の状態をあるべき状態に変更することができます。例えば、アプリケーションのデプロイのために、新しいコンテナの作成や既存コンテナの削除、新しいコンテナにあらゆるリソースを適用する作業を、Kubernetesで自動化できます。
* **自動ビンパッキング**
コンテナ化されたタスクを実行するノードのクラスターをKubernetesへ提供します。各コンテナがどれくらいCPUやメモリー(RAM)を必要とするのかをKubernetesに宣言することができます。Kubernetesはコンテナをノードにあわせて調整することができ、リソースを最大限に活用してくれます。
* **自己修復**
Kubernetesは、処理が失敗したコンテナを再起動し、コンテナを入れ替え、定義したヘルスチェックに応答しないコンテナを強制終了します。処理の準備ができるまでは、クライアントに通知しません。
* **機密情報と構成管理**
Kubernetesは、パスワードやOAuthトークン、SSHキーのよう機密の情報を保持し、管理することができます。機密情報をデプロイし、コンテナイメージを再作成することなくアプリケーションの構成情報を更新することができます。スタック構成の中で機密情報を晒してしまうこともありません。
## Kubernetesにないもの
Kubernetesは、従来型の全部入りなPaaS(Platform as a Service)のシステムではありません。Kubernetesはハードウェアレベルではなく、コンテナレベルで動作するため、デプロイ、スケーリング、負荷分散、ロギングやモニタリングといったPasSが提供するのと共通の機能をいくつか提供しています。また一方、Kubernetesはモノリシックでなく、標準のソリューションは選択が自由で、追加と削除が容易な構成になっています。Kubernetesは開発プラットフォーム構築のためにビルディングブロックを提供しますが、重要な部分はユーザーの選択と柔軟性を維持しています。
Kubernetesは...
* サポートするアプリケーションの種類を限定しません。Kubernetesはステートレス、ステートフル、およびデータ処理ワークロードなど、非常に多様なワークロードをサポートするように作られています。アプリケーションをコンテナ内で実行できる場合は、Kubernetes上でもうまく動作するはずです。
* ソースコードのデプロイやアプリケーションのビルドを行いません。継続的インテグレーション、デリバリー、デプロイ(CI/CD)ワークフローは、技術選定がそうであるように、組織の文化や好みによって決まるからです。
* ミドルウェア(例: メッセージバス)、データ処理フレームワーク(例: Spark)、データベース(例: mysql)、キャッシュ、クラスターストレージシステム(例: Ceph) のような、アプリケーションレベルの機能は組み込みでは提供しません。これらのコンポーネントはKubernetesの上で動作できますし、Open Service Brokerのようなポータブルメカニズムを経由してKubernetes上のアプリケーションからアクセスすることもできます。
* ロギング、モニタリング、アラーティングソリューションへの指示は行いません。概念実証(PoC)としていくつかのインテグレーション、およびメトリックを収集およびエクスポートするためのメカニズムを提供します。
* 設定言語/システム(例： jsonnet)を提供も強制もしません。任意の形式の宣言仕様の対象となる可能性がある宣言APIを提供します。
* 包括的なインフラ構成、保守、管理、またはセルフヒーリングシステムを提供、導入しません。
さらに、Kubernetesは単なる *オーケストレーションシステム* ではありません。実際、オーケストレーションは不要です。*オーケストレーション* の技術的定義は、定義されたワークフローの実行です。最初にA、次にB、次にCを実行します。対照的に、Kubernetesは現在の状態を提供された望ましい状態に向かって継続的に推進する一連の独立した構成可能な制御プロセスで構成されます。AからCへのアクセス方法は関係ありません。集中管理も必要ありません。これにより、使いやすく、より強力で、堅牢で、回復力があり、そして拡張性のあるシステムが得られます。
## なぜコンテナなのか？
コンテナを使うべき理由をお探しですか？
![なぜコンテナなのか？](/images/docs/why_containers.svg)
アプリケーションをデプロイするための古い方法は、オペレーティングシステムのパッケージマネージャを使用してアプリケーションをホストにインストールすることでした。これには、アプリケーションの実行ファイル、構成、ライブラリ、ライフサイクルがそれぞれ、またホストOS自身と絡み合うというデメリットがありました。予測可能なロールアウトとロールバックを実現するために、不変の仮想マシンイメージを作成することもできますが、VMは重く、移植性がありません。
新しい方法は、ハードウェア仮想化ではなく、オペレーティングシステムレベルの仮想化に基づいてコンテナを展開することです。各コンテナは互いに、そしてホストから隔離されています。また、独自のファイルシステムを持ち、お互いのプロセスを見ることができず、計算リソースの使用量を制限することができます。これはVMよりも構築が簡単で、基盤となるインフラストラクチャとホストのファイルシステムから分離されているため、クラウドやOSのディストリビューション間で移植性があります。
コンテナは小さくて速いので、1つのアプリケーションを各コンテナイメージにまとめることができます。この1対1のアプリケーションとイメージの関係により、コンテナの利点が完全に引き出されます。コンテナを使用すると、各アプリケーションを残りのアプリケーションスタックと合成したり、本番インフラストラクチャ環境と結合したりする必要がないため、不変のコンテナイメージをデプロイ時ではなく、ビルド時またはリリース時に作成できます。ビルド/リリース時にコンテナイメージを生成することで、開発から運用に一貫した環境を持ち込むことができます。同様に、コンテナはVMよりもはるかに透過的であるため、監視と管理が容易になります。これは、コンテナのプロセスライフサイクルがコンテナ内のプロセススーパーバイザによって隠されるのではなく、インフラストラクチャによって管理される場合に特に当てはまります。最後に、コンテナごとに1つのアプリケーションを使用すると、コンテナの管理はアプリケーションのデプロイ管理と同等になります。
コンテナの利点をまとめると:
* **アジャイルなアプリケーション作成とデプロイ**:
VMイメージの使用と比べ、コンテナイメージ作成は容易で効率も高いです。
* **継続的な開発、インテグレーション、デプロイ**:
迅速で簡単なロールバックで、信頼性の高い頻繁なコンテナイメージのビルドとデプロイを提供します(イメージの不変性にもよります)。
* **開発と運用の懸念を分離**:
デプロイ時ではなくビルド時またはリリース時にアプリケーションのコンテナイメージを作成することで、アプリケーションをインフラストラクチャから切り離します。
* **可観測性**
OSレベルの情報や測定基準だけでなく、アプリケーションの正常性やその他のシグナルも明確にします。
* **開発、テスト、本番環境に跨った環境の一貫性**:
手元のノートPC上でも、クラウド上と同じように動作します。
* **クラウドとOSディストリビューションの移植性**:
Ubuntu、RHEL、CoreOS、オンプレミス、Google Kubernetes Engine、その他のどこでも動作します。
* **アプリケーション中心の管理**:
仮想ハードウェア上でのOS実行から、論理リソースを使用したOS上でのアプリケーション実行へと、抽象度のレベルを上げます。
* **疎結合で、分散された、伸縮自在の遊離した[マイクロサービス](https://martinfowler.com/articles/microservices.html)**:
アプリケーションは小さな独立した欠片に分割され、動的に配置および管理できます。1つの大きな単一目的のマシンで実行されるモノリシックなスタックではありません。
* **リソース分割**:
アプリケーションパフォーマンスが予測可能です。
* **リソースの効率利用**:
高効率で高密度です。
## Kubernetesってどういう意味？K8sって何？
**Kubernetes** という名前はギリシャ語で *操舵手* や *パイロット* という意味があり、*知事* や[サイバネティックス](http://www.etymonline.com/index.php?term=cybernetics)の語源にもなっています。*K8s* は、8文字の「ubernete」を「8」に置き換えた略語です。
* サポートするアプリケーションの種類を制限しません。Kubernetesは、スレートレス、ステートフルやデータ処理のワークロードなど、非常に多様なワークロードをサポートすることを目的としています。アプリケーションがコンテナで実行できるのであれば、Kubernetes上で問題なく実行できるはずです。
* ソースコードのデプロイやアプリケーションのビルドは行いません。継続的なインテグレーション、デリバリー、デプロイ(CI/CD)のワークフローは、技術的な要件だけでなく組織の文化や好みで決められます。
* ミドルウェア(例:メッセージバス)、データ処理フレームワーク(例:Spark)、データベース(例:MySQL)、キャッシュ、クラスターストレージシステム(例:Ceph)といったアプリケーションレベルの機能を組み込んで提供しません。それらのコンポーネントは、Kubernetes上で実行することもできますし、[Open Service Broker](https://openservicebrokerapi.org/)のようなポータブルメカニズムを経由してKubernetes上で実行されるアプリケーションからアクセスすることも可能です。
* ロギング、モニタリングやアラートを行うソリューションは指定しません。PoCとしていくつかのインテグレーションとメトリクスを収集し出力するメカニズムを提供します。
* 構成言語/システム(例:Jsonnet)の提供も指示もしません。任意の形式の宣言型仕様の対象となる可能性のある宣言型APIを提供します。
* 統合的なマシンの構成、メンテナンス、管理、または自己修復を行うシステムは提供も採用も行いません。
* さらに、Kubernetesは単なるオーケストレーションシステムではありません。実際には、オーケストレーションの必要性はありません。オーケストレーションの技術的な定義は、「最初にAを実行し、次にB、その次にCを実行」のような定義されたワークフローの実行です。対照的にKubernetesは、現在の状態から提示されたあるべき状態にあわせて継続的に維持するといった、独立していて構成可能な制御プロセスのセットを提供します。AからCへどのように移行するかは問題ではありません。集中管理も必要ありません。これにより、使いやすく、より強力で、堅牢で、弾力性と拡張性があるシステムが実現します。
## {{% heading "whatsnext" %}}
* [はじめる](/docs/setup/)準備はできましたか？
* さらなる詳細については、[Kubernetesのドキュメント](/ja/docs/home/)を御覧ください。
* [Kubernetesのコンポーネント](/ja/docs/concepts/overview/components/)を御覧ください。
* [はじめる](/ja/docs/setup/)準備はできましたか？
content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md
+7 -7
View File
@@ -14,29 +14,29 @@ card:
<!-- body -->
## Kubernetesオブジェクトを理解する {#kubernetes-objects}
*Kubernetesオブジェクト* は、Kubernetes上で永続的なエンティティです。Kubernetesはこれらのエンティティを使い、クラスターの状態を表現します。具体的に言うと、下記のような内容が表現出来ます:
*Kubernetesオブジェクト* は、Kubernetes上で永続的なエンティティです。Kubernetesはこれらのエンティティを使い、クラスターの状態を表現します。具体的に言うと、下記のような内容が表現できます:
* どのようなコンテナ化されたアプリケーションが稼働しているか（またそれらはどのノード上で動いているか）
* どのようなコンテナ化されたアプリケーションが稼働しているか(またそれらはどのノード上で動いているか)
* それらのアプリケーションから利用可能なリソース
* アプリケーションがどのように振る舞うかのポリシー、例えば再起動、アップグレード、耐障害性ポリシーなど
Kubernetesオブジェクトは"意図の記録"です。一度オブジェクトを作成すると、Kubernetesは常にそのオブジェクトが存在し続けるように動きます。オブジェクトを作成することで、Kubernetesに対し効果的にあなたのクラスターのワークロードがこのようになっていて欲しいと伝えているのです。これが、あなたのクラスターの**望ましい状態**です。
Kubernetesオブジェクトは「意図の記録」です。一度オブジェクトを作成すると、Kubernetesは常にそのオブジェクトが存在し続けるように動きます。オブジェクトを作成することで、Kubernetesに対し効果的にあなたのクラスターのワークロードがこのようになっていて欲しいと伝えているのです。これが、あなたのクラスターの**望ましい状態**です。
Kubernetesオブジェクトを操作するには、作成、変更、または削除に関わらず[Kubernetes API](/ja/docs/concepts/overview/kubernetes-api/)を使う必要があるでしょう。例えば`kubectl`コマンドラインインターフェースを使った場合、このCLIが処理に必要なKubernetes API命令を、あなたに代わり発行します。あなたのプログラムから[クライアントライブラリ](/docs/reference/using-api/client-libraries/)を利用し、直接Kubernetes APIを利用することも可能です。
### オブジェクトのspec（仕様）とstatus（状態）
### オブジェクトのspec(仕様)とstatus(状態)
ほとんどのKubernetesオブジェクトは、オブジェクトの設定を管理する２つの入れ子になったオブジェクトのフィールドを持っています。それはオブジェクト *`spec`* とオブジェクト *`status`* です。`spec`を持っているオブジェクトに関しては、オブジェクト作成時に`spec`を設定する必要があり、望ましい状態としてオブジェクトに持たせたい特徴を記述する必要があります。
`status` オブジェクトはオブジェクトの *現在の状態* を示し、その情報はKubernetesとそのコンポーネントにより提供、更新されます。Kubernetes{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}は、あなたから指定された望ましい状態と現在の状態が一致するよう常にかつ積極的に管理をします。
例えば、KubernetesのDeploymentはクラスター上で稼働するアプリケーションを表現するオブジェクトです。Deploymentを作成するとき、アプリケーションの複製を３つ稼働させるようDeploymentのspecで指定するかもしれません。KubernetesはDeploymentのspecを読み取り、指定されたアプリケーションを３つ起動し、現在の状態がspecに一致するようにします。もしこれらのインスタンスでどれかが落ちた場合（statusが変わる）、Kubernetesはspecと、statusの違いに反応し、修正しようとします。この場合は、落ちたインスタンスの代わりのインスタンスを立ち上げます。
例えば、KubernetesのDeploymentはクラスター上で稼働するアプリケーションを表現するオブジェクトです。Deploymentを作成するとき、アプリケーションの複製を３つ稼働させるようDeploymentのspecで指定するかもしれません。KubernetesはDeploymentのspecを読み取り、指定されたアプリケーションを３つ起動し、現在の状態がspecに一致するようにします。もしこれらのインスタンスでどれかが落ちた場合(statusが変わる)、Kubernetesはspecと、statusの違いに反応し、修正しようとします。この場合は、落ちたインスタンスの代わりのインスタンスを立ち上げます。
spec、status、metadataに関するさらなる情報は、[Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)をご確認ください。
### Kubernetesオブジェクトを記述する
Kubernetesでオブジェクトを作成する場合、オブジェクトの基本的な情報（例えば名前）と共に、望ましい状態を記述したオブジェクトのspecを渡さなければいけません。KubernetesAPIを利用しオブジェクトを作成する場合（直接APIを呼ぶか、`kubectl`を利用するかに関わらず）、APIリクエストはそれらの情報をJSON形式でリクエストのBody部に含んでいなければなりません。
Kubernetesでオブジェクトを作成する場合、オブジェクトの基本的な情報(例えば名前)と共に、望ましい状態を記述したオブジェクトのspecを渡さなければいけません。KubernetesAPIを利用しオブジェクトを作成する場合(直接APIを呼ぶか、`kubectl`を利用するかに関わらず)、APIリクエストはそれらの情報をJSON形式でリクエストのBody部に含んでいなければなりません。
ここで、KubernetesのDeploymentに必要なフィールドとオブジェクトのspecを記載した`.yaml`ファイルの例を示します:
@@ -63,7 +63,7 @@ Kubernetesオブジェクトを`.yaml`ファイルに記載して作成する場
* `metadata` - オブジェクトを一意に特定するための情報、文字列の`name`、`UID`、また任意の`namespace`が該当する
* `spec` - オブジェクトの望ましい状態
`spec`の正確なフォーマットは、Kubernetesオブジェクトごとに異なり、オブジェクトごとに特有な入れ子のフィールドを持っています。[Kubernetes API リファレンス](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)が、Kubernetesで作成出来る全てのオブジェクトに関するspecのフォーマットを探すのに役立ちます。
`spec`の正確なフォーマットは、Kubernetesオブジェクトごとに異なり、オブジェクトごとに特有な入れ子のフィールドを持っています。[Kubernetes API リファレンス](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)が、Kubernetesで作成できる全てのオブジェクトに関するspecのフォーマットを探すのに役立ちます。
例えば、`Pod`オブジェクトに関する`spec`のフォーマットは[PodSpec v1 core](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)を、また`Deployment`オブジェクトに関する`spec`のフォーマットは[DeploymentSpec v1 apps](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps)をご確認ください。
content/ja/docs/concepts/overview/working-with-objects/labels.md
+1 -1
View File
@@ -185,7 +185,7 @@ kubectl get pods -l 'environment in (production),tier in (frontend)'
```
すでに言及したように、*集合ベース* の要件は、*等価ベース* の要件より表現力があります。
例えば、値に対する_OR_ オペレーターを実装して以下のように書けます。
例えば、値に対する _OR_ オペレーターを実装して以下のように書けます。
```shell
kubectl get pods -l 'environment in (production, qa)'
content/ja/docs/concepts/overview/working-with-objects/object-management.md
+5 -5
View File
@@ -63,7 +63,7 @@ kubectl create deployment nginx --image nginx
## 命令型オブジェクト設定
命令型オブジェクト設定では、kubectlコマンドに処理内容（create、replaceなど）、任意のフラグ、そして最低1つのファイル名を指定します。
命令型オブジェクト設定では、kubectlコマンドに処理内容(create、replaceなど)、任意のフラグ、そして最低1つのファイル名を指定します。
指定されたファイルは、YAMLまたはJSON形式でオブジェクトの全ての定義情報を含んでいなければいけません。
オブジェクト定義の詳細は、[APIリファレンス](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)を参照してください。
@@ -150,7 +150,7 @@ kubectl apply -R -f configs/
命令型オブジェクト設定手法に対する長所:
- 現行オブジェクトに直接行われた変更が、それらが設定ファイルに反映されていなかったとしても、保持されます
- 宣言型オブジェクト設定は、ディレクトリごとの処理をより良くサポートしており、自動的にオブジェクトごとに操作のタイプ（作成、パッチ、削除）を検出します
- 宣言型オブジェクト設定は、ディレクトリごとの処理をより良くサポートしており、自動的にオブジェクトごとに操作のタイプ(作成、パッチ、削除)を検出します
命令型オブジェクト設定手法に対する短所:
@@ -163,9 +163,9 @@ kubectl apply -R -f configs/
- [命令型コマンドを利用したKubernetesオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/imperative-command/)
- [オブジェクト設定（命令型）を利用したKubernetesオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/imperative-config/)
- [オブジェクト設定（宣言型）を利用したKubernetesオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/declarative-config/)
- [Kustomize（宣言型）を利用したKubernetesオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/kustomization/)
- [オブジェクト設定(命令型)を利用したKubernetesオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/imperative-config/)
- [オブジェクト設定(宣言型)を利用したKubernetesオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/declarative-config/)
- [Kustomize(宣言型)を利用したKubernetesオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/kustomization/)
- [Kubectlコマンドリファレンス](/docs/reference/generated/kubectl/kubectl-commands/)
- [Kubectl Book](https://kubectl.docs.kubernetes.io)
- [Kubernetes APIリファレンス](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
content/ja/docs/concepts/scheduling/kube-scheduler.md
+1 -1
View File
@@ -104,7 +104,7 @@ kube-schedulerは、デフォルトで用意されているスケジューリン
- `ImageLocalityPriority`: すでにPodに対するコンテナイメージをローカルにキャッシュしているNodeを優先します。
- `ServiceSpreadingPriority`: このポリシーの目的は、特定のServiceに対するバックエンドのPodが、それぞれ異なるNodeで実行されるようにすることです。このポリシーではServiceのバックエンドのPodが既に実行されていないNode上にスケジュールするように優先します。これによる結果として、Serviceは単体のNode障害に対してより耐障害性が高まります。
- `ServiceSpreadingPriority`: このポリシーの目的は、特定のServiceに対するバックエンドのPodが、それぞれ異なるNodeで実行されるようにすることです。このポリシーではServiceのバックエンドのPodがすでに実行されていないNode上にスケジュールするように優先します。これによる結果として、Serviceは単体のNode障害に対してより耐障害性が高まります。
- `CalculateAntiAffinityPriorityMap`: このポリシーは[PodのAnti-Affinity](/ja/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)の実装に役立ちます。
content/ja/docs/concepts/scheduling/scheduler-perf-tuning.md
+3 -3
View File
@@ -10,7 +10,7 @@ weight: 70
[kube-scheduler](/docs/concepts/scheduling/kube-scheduler/#kube-scheduler)はKubernetesのデフォルトのスケジューラーです。クラスター内のノード上にPodを割り当てる責務があります。
クラスター内に存在するノードで、Podのスケジューリング要求を満たすものはPodに対して_割り当て可能_ なノードと呼ばれます。スケジューラーはPodに対する割り当て可能なノードをみつけ、それらの割り当て可能なノードにスコアをつけます。その中から最も高いスコアのノードを選択し、Podに割り当てるためのいくつかの関数を実行します。スケジューラーは_Binding_ と呼ばれる処理中において、APIサーバーに対して割り当てが決まったノードの情報を通知します。
クラスター内に存在するノードで、Podのスケジューリング要求を満たすものはPodに対して*割り当て可能*なノードと呼ばれます。スケジューラーはPodに対する割り当て可能なノードをみつけ、それらの割り当て可能なノードにスコアをつけます。その中から最も高いスコアのノードを選択し、Podに割り当てるためのいくつかの関数を実行します。スケジューラーは*Binding*と呼ばれる処理中において、APIサーバーに対して割り当てが決まったノードの情報を通知します。
このページでは、大規模のKubernetesクラスターにおけるパフォーマンス最適化のためのチューニングについて説明します。
@@ -35,11 +35,11 @@ algorithmSource:
percentageOfNodesToScore: 50
```
{{< note >}}
{{< note >}}
割り当て可能なノードが50未満のクラスターにおいては、割り当て可能なノードの探索を止めるほどノードが多くないため、スケジューラーは全てのノードをチェックします。
{{< /note >}}
**この機能を無効にするためには**、`percentageOfNodesToScore`を100に設定してください。
**この機能を無効にするためには**、`percentageOfNodesToScore`を100に設定してください。
### percentageOfNodesToScoreのチューニング
content/ja/docs/concepts/workloads/controllers/cron-jobs.md
+1 -1
View File
@@ -46,7 +46,7 @@ Cannot determine if job needs to be started. Too many missed start time (> 100).
例として、CronJobが`08:30:00`を開始時刻として1分ごとに新しいJobをスケジュールするように設定され、`startingDeadlineSeconds`フィールドが設定されていない場合を想定します。CronJobコントローラーが`08:29:00` から`10:21:00`の間にダウンしていた場合、スケジューリングを逃したジョブの数が100を超えているため、ジョブは開始されません。
このコンセプトを更に掘り下げるために、CronJobが`08:30:00`から1分ごとに新しいJobを作成し、`startingDeadlineSeconds`が200秒に設定されている場合を想定します。CronJobコントローラーが前回の例と同じ期間(`08:29:00` から`10:21:00`まで)にダウンしている場合でも、10:22:00時点でJobはまだ動作しています。このようなことは、過去200秒間(言い換えると、3回の失敗)に何回スケジュールが間に合わなかったをコントローラーが確認するときに発生します。これは最後にスケジュールされた時間から今までのものではありません。
このコンセプトをさらに掘り下げるために、CronJobが`08:30:00`から1分ごとに新しいJobを作成し、`startingDeadlineSeconds`が200秒に設定されている場合を想定します。CronJobコントローラーが前回の例と同じ期間(`08:29:00` から`10:21:00`まで)にダウンしている場合でも、10:22:00時点でJobはまだ動作しています。このようなことは、過去200秒間(言い換えると、3回の失敗)に何回スケジュールが間に合わなかったをコントローラーが確認するときに発生します。これは最後にスケジュールされた時間から今までのものではありません。
CronJobはスケジュールに一致するJobの作成にのみ関与するのに対して、JobはJobが示すPod管理を担います。
content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md
+1 -1
View File
@@ -29,7 +29,7 @@ TTLコントローラーは、そのリソースが終了したあと指定し
TTL秒はいつでもセット可能です。下記はJobの`.spec.ttlSecondsAfterFinished`フィールドのセットに関するいくつかの例です。
* Jobがその終了後にいくつか時間がたった後に自動的にクリーンアップできるように、そのリソースマニフェストにこの値を指定します。
* この新しい機能を適用させるために、存在していて既に終了したリソースに対してこのフィールドをセットします。
* この新しい機能を適用させるために、存在していてすでに終了したリソースに対してこのフィールドをセットします。
* リソース作成時に、このフィールドを動的にセットするために、[管理webhookの変更](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)をさせます。クラスター管理者は、終了したリソースに対して、このTTLポリシーを強制するために使うことができます。
* リソースが終了した後に、このフィールドを動的にセットしたり、リソースステータスやラベルなどの値に基づいて異なるTTL値を選択するために、[管理webhookの変更](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)をさせます。
content/ja/docs/concepts/workloads/pods/init-containers.md
+4 -5
View File
@@ -8,7 +8,7 @@ weight: 40
このページでは、Initコンテナについて概観します。Initコンテナとは、{{< glossary_tooltip text="Pod" term_id="pod" >}}内でアプリケーションコンテナの前に実行される特別なコンテナです。
Initコンテナにはアプリケーションコンテナのイメージに存在しないセットアップスクリプトやユーティリティーを含めることができます。
Initコンテナは、Podの仕様のうち`containers`という配列（これがアプリケーションコンテナを示します）と並べて指定します。
Initコンテナは、Podの仕様のうち`containers`という配列(これがアプリケーションコンテナを示します)と並べて指定します。
<!-- body -->
## Initコンテナを理解する {#understanding-init-containers}
@@ -213,7 +213,7 @@ Podは全てのInitコンテナが完了するまで`Ready`状態となりませ
Initコンテナの仕様の変更は、コンテナイメージのフィールドのみに制限されています。
Initコンテナのイメージフィールド値を変更すると、そのPodは再起動されます。
Initコンテナは何度も再起動およびリトライ可能なため、べき等（Idempotent）である必要があります。特に、`EmptyDirs`にファイルを書き込むコードは、書き込み先のファイルがすでに存在している可能性を考慮に入れる必要があります。
Initコンテナは何度も再起動およびリトライ可能なため、べき等(Idempotent)である必要があります。特に、`EmptyDirs`にファイルを書き込むコードは、書き込み先のファイルがすでに存在している可能性を考慮に入れる必要があります。
Initコンテナはアプリケーションコンテナの全てのフィールドを持っています。しかしKubernetesは、Initコンテナが完了と異なる状態を定義できないため`readinessProbe`が使用されることを禁止しています。これはバリデーションの際に適用されます。
@@ -230,11 +230,11 @@ Initコンテナの順序と実行を考えるとき、リソースの使用に
* リソースに対する全てのアプリケーションコンテナのリクエスト／リミットの合計
* リソースに対する有効なinitリクエスト／リミット
* スケジューリングは有効なリクエスト／リミットに基づいて実行されます。つまり、InitコンテナはPodの生存中には使用されない初期化用のリソースを確保することができます。
* Podの*有効なQos（quality of service）ティアー* は、Initコンテナとアプリケーションコンテナで同様です。
* Podの*有効なQoS(quality of service)ティアー* は、Initコンテナとアプリケーションコンテナで同様です。
クォータとリミットは有効なPodリクエストとリミットに基づいて適用されます。
Podレベルのコントロールグループ（cgroups）は、スケジューラーと同様に、有効なPodリクエストとリミットに基づいています。
Podレベルのコントロールグループ(cgroups)は、スケジューラーと同様に、有効なPodリクエストとリミットに基づいています。
### Podの再起動の理由 {#pod-restart-reasons}
@@ -250,4 +250,3 @@ Podレベルのコントロールグループ（cgroups）は、スケジュー
* [Initコンテナを含むPodの作成](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container)方法について学ぶ。
* [Initコンテナのデバッグ](/ja/docs/tasks/debug-application-cluster/debug-init-containers/)を行う方法について学ぶ。
content/ja/docs/concepts/workloads/pods/pod-overview.md
+4 -4
View File
@@ -1,5 +1,5 @@
---
title: Podについての概観(Pod Overview)
title: Podの概観
content_type: concept
weight: 10
card:
@@ -8,7 +8,7 @@ card:
---
<!-- overview -->
このページでは、Kubernetesのオブジェクトモデルにおいて、デプロイ可能な最小単位のオブジェクトである`Pod`に関して概観します。
このページでは、Kubernetesのオブジェクトモデルにおいて、デプロイ可能な最小単位のオブジェクトである`Pod`に関して説明します。
<!-- body -->
@@ -62,7 +62,7 @@ Podは、Podによって構成されたコンテナ群のために2種類の共
## Podを利用する
ユーザーはまれに、Kubenetes内で独立したPodを直接作成する場合があります(シングルトンPodなど)。
これはPodが比較的、一時的な使い捨てエンティティとしてデザインされているためです。Podが作成された時（ユーザーによって直接的、またはコントローラーによって間接的に作成された場合）、ユーザーのクラスター内の単一の{{< glossary_tooltip term_id="node" >}}上で稼働するようにスケジューリングされます。そのPodはプロセスが停止されたり、Podオブジェクトが削除されたり、Podがリソースの欠如のために*追い出され* たり、ノードが故障するまでノード上に残り続けます。
これはPodが比較的、一時的な使い捨てエンティティとしてデザインされているためです。Podが作成された時(ユーザーによって直接的、またはコントローラーによって間接的に作成された場合)、ユーザーのクラスター内の単一の{{< glossary_tooltip term_id="node" >}}上で稼働するようにスケジューリングされます。そのPodはプロセスが停止されたり、Podオブジェクトが削除されたり、Podがリソースの欠如のために*追い出され* たり、ノードが故障するまでノード上に残り続けます。
{{< note >}}
単一のPod内でのコンテナを再起動することと、そのPodを再起動することを混同しないでください。Podはそれ自体は実行されませんが、コンテナが実行される環境であり、削除されるまで存在し続けます。
@@ -111,7 +111,7 @@ spec:
## {{% heading "whatsnext" %}}
* [Pod](/ja/docs/concepts/workloads/pods/pod/)について更に学びましょう
* [Pod](/ja/docs/concepts/workloads/pods/pod/)についてさらに学びましょう
* Podの振る舞いに関して学ぶには下記を参照してください
* [Podの停止](/ja/docs/concepts/workloads/pods/pod/#termination-of-pods)
* [Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)
content/ja/docs/concepts/workloads/pods/pod.md
+23 -25
View File
@@ -16,7 +16,7 @@ _Pod_ は、Kubernetesで作成および管理できる、デプロイ可能な
## Podとは
_Pod_ は（クジラの小群やエンドウ豆のさやのように）、共有のストレージ/ネットワークを持つ1つ以上のコンテナ（例えばDockerコンテナ）、およびコンテナを実行する方法についての仕様です。Pod内のコンテナ群は常に同じ場所に配置され、協調してスケジューリングされ、共通のコンテキストで実行されます。Podは、アプリケーション固有の「論理ホスト」――やや密に結合した1つ以上のアプリケーション・コンテナを含むもの――をモデル化します。コンテナ以前の世界では、同じ物理または仮想マシン上で実行されることが、同じ論理ホスト上で実行されることを意味するでしょう。
_Pod_ は(クジラの小群やエンドウ豆のさやのように)、共有のストレージ/ネットワークを持つ1つ以上のコンテナ(例えばDockerコンテナ)、およびコンテナを実行する方法についての仕様です。Pod内のコンテナ群は常に同じ場所に配置され、協調してスケジューリングされ、共通のコンテキストで実行されます。Podは、アプリケーション固有の「論理ホスト」――やや密に結合した1つ以上のアプリケーション・コンテナを含むもの――をモデル化します。コンテナ以前の世界では、同じ物理または仮想マシン上で実行されることが、同じ論理ホスト上で実行されることを意味するでしょう。
Kubernetesは、Dockerだけでなくより多くのコンテナ・ランタイムをサポートしていますが、Dockerは最もよく知られているランタイムであり、Dockerの用語を使ってPodを説明することが可能です。
@@ -24,7 +24,7 @@ Pod内では、Linux namespaceやcgroupなどのDockerコンテナを分離す
Podのコンテキスト内で、個々のアプリケーションに更なる分離が適用されることがあります。
Pod内のコンテナはIPアドレスとポートの空間を共有し、 `localhost` を通じてお互いを見つけることができます 。
また、SystemVセマフォやPOSIX共有メモリなどの標準のプロセス間通信（IPC）を使用して互いに通信することもできます。
また、SystemVセマフォやPOSIX共有メモリなどの標準のプロセス間通信(IPC)を使用して互いに通信することもできます。
異なるPodのコンテナは異なるIPアドレスを持ち、[特別な設定](/docs/concepts/policy/pod-security-policy/)がなければIPCでは通信できません。
これらのコンテナは通常、Pod IPアドレスを介して互いに通信します。
@@ -33,18 +33,18 @@ Pod内のアプリケーションからアクセスできる共有ボリュー
[Docker](https://www.docker.com/)の用語でいえば、Podは共有namespaceと共有[ボリューム](/docs/concepts/storage/volumes/)を持つDockerコンテナのグループとしてモデル化されています。
個々のアプリケーションコンテナと同様に、Podは（永続的ではなく）比較的短期間の存在と捉えられます。
[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)で説明しているように、Podが作成されると、一意のID（UID）が割り当てられ、（再起動ポリシーに従って）終了または削除されるまでNodeで実行されるようにスケジュールされます。
個々のアプリケーションコンテナと同様に、Podは(永続的ではなく)比較的短期間の存在と捉えられます。
[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)で説明しているように、Podが作成されると、一意のID(UID)が割り当てられ、(再起動ポリシーに従って)終了または削除されるまでNodeで実行されるようにスケジュールされます。
Nodeが停止した場合、そのNodeにスケジュールされたPodは、タイムアウト時間の経過後に削除されます。
特定のPod（UIDで定義）は新しいNodeに「再スケジュール」されません。
代わりに、必要に応じて同じ名前で、新しいUIDを持つ同一のPodに置き換えることができます（詳細については[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)を参照してください）。
特定のPod(UIDで定義)は新しいNodeに「再スケジュール」されません。
代わりに、必要に応じて同じ名前で、新しいUIDを持つ同一のPodに置き換えることができます(詳細については[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)を参照してください)。
ボリュームなど、Podと同じ存続期間を持つものがあると言われる場合、それは（そのUIDを持つ）Podが存在する限り存在することを意味します。
そのPodが何らかの理由で削除された場合、たとえ同じ代替物が作成されたとしても、関連するもの（例えばボリューム）も同様に破壊されて再作成されます。
ボリュームなど、Podと同じ存続期間を持つものがあると言われる場合、それは(そのUIDを持つ)Podが存在する限り存在することを意味します。
そのPodが何らかの理由で削除された場合、たとえ同じ代替物が作成されたとしても、関連するもの(例えばボリューム)も同様に破壊されて再作成されます。
{{< figure src="/images/docs/pod.svg" title="Podの図" width="50%" >}}
*file puller（ファイル取得コンテナ）とWebサーバーを含むマルチコンテナのPod。コンテナ間の共有ストレージとして永続ボリュームを使用している。*
*file puller(ファイル取得コンテナ)とWebサーバーを含むマルチコンテナのPod。コンテナ間の共有ストレージとして永続ボリュームを使用している。*
## Podを用いる動機
@@ -53,13 +53,13 @@ Nodeが停止した場合、そのNodeにスケジュールされたPodは、タ
Podは、まとまったサービスの単位を形成する複数の協調プロセスのパターンをモデル化したものです。
構成要素であるアプリケーションの集まりよりも高いレベルの抽象化を提供することによって、アプリケーションのデプロイと管理を単純化します。
Podは、デプロイや水平スケーリング、レプリケーションの単位として機能します。
Pod内のコンテナに対しては、同じ場所への配置（共同スケジューリング）、命運の共有（つまり停止）、協調レプリケーション、リソース共有や依存関係の管理が自動的に取り扱われます。
Pod内のコンテナに対しては、同じ場所への配置(共同スケジューリング)、命運の共有(つまり停止)、協調レプリケーション、リソース共有や依存関係の管理が自動的に取り扱われます。
### リソース共有と通信
Podは、構成要素間でのデータ共有および通信を可能にします。
Pod内のアプリケーションはすべて同じネットワーク名前空間（同じIPおよびポートスペース）を使用するため、 `localhost` としてお互いを「見つけて」通信できます。
Pod内のアプリケーションはすべて同じネットワーク名前空間(同じIPおよびポートスペース)を使用するため、 `localhost` としてお互いを「見つけて」通信できます。
このため、Pod内のアプリケーションはそれぞれ使用するポートを調整する必要があります。
各Podは、他の物理コンピュータやPodと自由に通信するためのフラットな共有ネットワーク空間上にIPアドレスを持ちます。
@@ -71,7 +71,7 @@ Podで実行されるアプリケーションコンテナの定義に加えて
## Podの用途
Podは、垂直に統合されたアプリケーションスタック（例：LAMP）をホストするために使用できます。
Podは、垂直に統合されたアプリケーションスタック(例:LAMP)をホストするために使用できます。
しかし、Podを使う主な動機は、次のように同じ場所に配置され、共に管理されるヘルパープログラムをサポートすることです。
* コンテンツ管理システム(CMS)、ファイルやデータのローダー、ローカルのキャッシュマネージャーなど
@@ -83,11 +83,11 @@ Podは、垂直に統合されたアプリケーションスタック（例：LA
個々のPodは、一般に、同じアプリケーションの複数のインスタンスを実行することを目的としていません。
詳細については、[The Distributed System ToolKit: Patterns for
Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)（分散システムツールキット：複合コンテナのパターン）を参照してください。
Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)(分散システムツールキット：複合コンテナのパターン)を参照してください。
## 考えられる代替案
_単一の（Docker）コンテナで複数のプログラムを実行しないのはなぜですか？_
_単一の(Docker)コンテナで複数のプログラムを実行しないのはなぜですか？_
1. 透明性のため。Pod内のコンテナをインフラストラクチャから見えるようにすることで、インフラストラクチャはプロセス管理やリソース監視などのサービスをコンテナに提供できます。
これは、ユーザーに多くの便益を提供します。
@@ -97,13 +97,13 @@ Kubernetesはいつか個々のコンテナのライブアップデートをサ
1. 使いやすさのため。ユーザーは独自のプロセスマネージャーを実行する必要はありません。シグナルや終了コードの伝播などについて心配する必要はありません。
1. 効率のため。インフラストラクチャがより責任を負うため、コンテナはより軽量になります。
_アフィニティ（結合性、親和性）ベースのコンテナの共同スケジューリングをサポートしないのはなぜですか？_
_アフィニティ(結合性、親和性)ベースのコンテナの共同スケジューリングをサポートしないのはなぜですか？_
このアプローチによって、コンテナの共同配置は提供されるでしょう。
しかし、リソース共有やIPC、保証された命運の共有、および簡素化された管理といったPodの利点のほとんどは提供されないでしょう。
## Podの耐久性（またはその欠如）
## Podの耐久性(またはその欠如) {#pod-durability}
Podは、耐久性のある存在として扱われることを意図していません。
スケジューリングの失敗や、Nodeの故障には耐えられません。
@@ -128,7 +128,7 @@ Podは、以下のことを容易にするためにプリミティブとして
## Podの終了 {#termination-of-pods}
Podは、クラスター内のNodeで実行中のプロセスを表すため、不要になったときにそれらのプロセスを正常に終了できるようにすることが重要です（対照的なケースは、KILLシグナルで強制終了され、クリーンアップする機会がない場合）。
Podは、クラスター内のNodeで実行中のプロセスを表すため、不要になったときにそれらのプロセスを正常に終了できるようにすることが重要です(対照的なケースは、KILLシグナルで強制終了され、クリーンアップする機会がない場合)。
ユーザーは削除を要求可能であるべきで、プロセスがいつ終了するかを知ることができなければなりませんが、削除が最終的に完了することも保証できるべきです。
ユーザーがPodの削除を要求すると、システムはPodが強制終了される前に意図された猶予期間を記録し、各コンテナのメインプロセスにTERMシグナルが送信されます。
猶予期間が終了すると、プロセスにKILLシグナルが送信され、PodはAPIサーバーから削除されます。
@@ -136,17 +136,17 @@ Podは、クラスター内のNodeで実行中のプロセスを表すため、
フローの例は下のようになります。
1. ユーザーがデフォルトの猶予期間（30秒）でPodを削除するコマンドを送信する
1. ユーザーがデフォルトの猶予期間(30秒)でPodを削除するコマンドを送信する
1. APIサーバー内のPodは、猶予期間を越えるとPodが「死んでいる」と見なされるように更新される
1. クライアントのコマンドに表示されたとき、Podは「終了中」と表示される
1. （3と同時に）Kubeletは、2の期間が設定されたためにPodが終了中となったことを認識すると、Podのシャットダウン処理を開始する
1. (3と同時に)Kubeletは、2の期間が設定されたためにPodが終了中となったことを認識すると、Podのシャットダウン処理を開始する
1. Pod内のコンテナの1つが[preStopフック](/docs/concepts/containers/container-lifecycle-hooks/#hook-details)を定義している場合は、コンテナの内側で呼び出される。
猶予期間が終了した後も `preStop`フックがまだ実行されている場合は、一度だけ猶予期間を延長して（2秒）、ステップ2が呼び出される。`preStop`フックが完了するまでにより長い時間が必要な場合は、`terminationGracePeriodSeconds`を変更する必要がある。
猶予期間が終了した後も `preStop`フックがまだ実行されている場合は、一度だけ猶予期間を延長して(2秒)、ステップ2が呼び出される。`preStop`フックが完了するまでにより長い時間が必要な場合は、`terminationGracePeriodSeconds`を変更する必要がある。
1. コンテナにTERMシグナルが送信される。Pod内のすべてのコンテナが同時にTERMシグナルを受信するわけではなく、シャットダウンの順序が問題になる場合はそれぞれに `preStop` フックが必要になることがある
1. （3と同時に）Podはサービスを提供するエンドポイントのリストから削除され、ReplicationControllerの実行中のPodの一部とは見なされなくなる。
ゆっくりとシャットダウンするPodは、（サービスプロキシのような）ロードバランサーがローテーションからそれらを削除するので、トラフィックを処理し続けることはできない
1. (3と同時に)Podはサービスを提供するエンドポイントのリストから削除され、ReplicationControllerの実行中のPodの一部とは見なされなくなる。
ゆっくりとシャットダウンするPodは、(サービスプロキシのような)ロードバランサーがローテーションからそれらを削除するので、トラフィックを処理し続けることはできない
1. 猶予期間が終了すると、Pod内でまだ実行中のプロセスはSIGKILLで強制終了される
1. Kubeletは猶予期間を0（即時削除）に設定することでAPIサーバー上のPodの削除を終了する。
1. Kubeletは猶予期間を0(即時削除)に設定することでAPIサーバー上のPodの削除を終了する。
PodはAPIから消え、クライアントからは見えなくなる
デフォルトでは、すべての削除は30秒以内に正常に行われます。
@@ -186,5 +186,3 @@ spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'
PodはKubernetes REST APIのトップレベルのリソースです。
APIオブジェクトの詳細については、[Pod APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)を参照してください 。
content/ja/docs/contribute/_index.md
+1 -1
View File
@@ -32,7 +32,7 @@ Kubernetesのドキュメントは、GitHubのリポジトリーにあります
## 貢献するためのベストプラクティス
- 明快で意味のあるGitコミットメッセージを書いてください。
- PRがマージされたときにissueを参照し、自動的にissueをクローズする_Github Special Keywords_を必ず含めるようにしてください。
- PRがマージされたときにissueを参照し、自動的にissueをクローズする _Github Special Keywords_ を必ず含めるようにしてください。
- タイプミスの修正や、スタイルの変更、文法の変更などのような小さな変更をPRに加える場合は、比較的小さな変更のためにコミットの数が増えすぎないように、コミットはまとめてください。
- あなたがコードを変更をした理由を示し、レビュアーがあなたのPRを理解するのに十分な情報を確保した適切なPR説明を、必ず含めるようにしてください。
- 追加文献 :
content/ja/docs/contribute/localization.md
+94 -218
View File
@@ -9,272 +9,148 @@ card:
<!-- overview -->
このページでは、ドキュメントを異なる言語に[翻訳](https://blog.mozilla.org/l10n/2011/12/14/i18n-vs-l10n-whats-the-diff/)する方法について紹介します。
このページでは、Kubernetesドキュメントにおける日本語翻訳の方針について説明します。
<!-- body -->
## はじめる
## ドキュメントを日本語に翻訳するまでの流れ
コントリビューターが自分自身のプルリクエストを承認することはできないため、翻訳を始めるには、最低でも2人が必要です。
翻訳を行うための基本的な流れについて説明します。不明点がある場合は[Kubernetes公式Slack](http://slack.kubernetes.io/)の`#kubernetes-docs-ja`チャンネルにてお気軽にご質問ください。
すべての翻訳チームは、自分たちのリソースを継続的に自己管理しなければいけません。私たちはドキュメントを喜んでホストしますが、あなたの代わりに翻訳することはできないからです。
### 前提知識
### 2文字の言語コードを探す
翻訳作業は全て[GitHubのIssue](https://github.com/kubernetes/website/issues?q=is%3Aissue+is%3Aopen+label%3Alanguage%2Fja)によって管理されています。翻訳作業を行いたい場合は、Issueの一覧をまず最初にご確認ください。
最初に、[ISO 639-1標準](https://www.loc.gov/standards/iso639-2/php/code_list.php)のドキュメントから、翻訳先の言語に対応する2文字の国コードを探してください。たとえば、韓国語の国コードは`ko`です。
また、Kubernetes傘下のリポジトリでは`CLA`と呼ばれる同意書に署名しないと、Pull Requestをマージすることができません。詳しくは[英語のドキュメント](https://github.com/kubernetes/community/blob/master/CLA.md)や、[Qiitaに有志の方が書いてくださった日本語のまとめ](https://qiita.com/jlandowner/items/d14d9bc8797a62b65e67)をご覧ください。
### リポジトリをフォーク・クローンする {#fork-and-clone-the-repo}
### 翻訳を始めるまで
初めに、[kubernetes/website](https://github.com/kubernetes/website)リポジトリの[自分用のフォークを作成](/docs/contribute/start/#improve-existing-content)します。
#### 翻訳を希望するページのIssueが存在しない場合
そして、フォークをクローンして、ディレクトリに`cd`します。
1. [こちらのサンプル](https://github.com/kubernetes/website/issues/22340)に従う形でIssueを作成する
2. 自分自身を翻訳作業に割り当てたい場合は、Issueのメッセージまたはコメントに`/assign`と書く
3. [新規ページを翻訳する場合](#translate-new-page)のステップに進む
```shell
git clone https://github.com/<username>/website
cd website
```
**不明点がある場合は[Kubernetes公式Slack](http://slack.kubernetes.io/)の`#kubernetes-docs-ja`チャンネルにてお気軽にご質問ください。**
### プルリクエストを開く
#### 翻訳を希望するページのIssueが存在する場合
次に、`kubernetes/website`リポジトリに翻訳を追加するための[プルリクエスト(PR)を開きます](/docs/contribute/start/#submit-a-pull-request)。
1. 自分自身を翻訳作業に割り当てるために、Issueのコメントに`/assign`と書く
2. [新規ページを翻訳する場合](#translate-new-page)のステップに進む
このPRが承認されるためには、[最低限必要なコンテンツ](#minimum-required-content)が含まれていなければなりません。
### Pull Requestを送るまで
新しい翻訳を追加する例としては、[フランス語版ドキュメントを追加するPR](https://github.com/kubernetes/website/pull/12548)を参考にしてください。
未翻訳ページの新規翻訳作業と既存ページの修正作業でそれぞれ手順が異なります。
### Kubernetes GitHub organizationに参加する
既存ページへの追加修正については、後述の[マイルストーンについて](#milestones)に目を通すことをおすすめします。
翻訳のPRを作ると、Kubernetes GitHub organizationのメンバーになることができます。チームの各個人は、それぞれ`kubernetes/org`リポジトリに[Organization Membership Request](https://github.com/kubernetes/org/issues/new/choose)を作成する必要があります。
#### 新規ページを翻訳する場合の手順 {#translate-new-page}
### 翻訳チームをGitHubに追加する {#add-your-localization-team-in-github}
1. `kubernetes/website`リポジトリをフォークする
2. `master`から任意の名前でブランチを作成する
3. `content/en`のディレクトリから必要なファイルを`content/ja`にコピーし、翻訳する
4. `master`ブランチに向けてPull Requestを作成する
次に、Kubernetesの翻訳チームを[`sig-docs/teams.yaml`](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml)に追加します。翻訳チームを追加する例として、[スペイン語の翻訳チーム](https://github.com/kubernetes/org/pull/685)を追加するPRを見てください。
#### 既存のページの誤字脱字や古い記述を修正する場合の手順
`@kubernetes/sig-docs-**-owners`のメンバーは、翻訳のディレクトリ`/content/**/`以下のコンテンツのみを変更するPRを承認できます。
1. `kubernetes/website`リポジトリをフォークする
2. `dev-1.18-ja.1`(最新のマイルストーンブランチに適宜読み替えること)から任意の名前でブランチを作成し、該当箇所を編集する
3. `dev-1.18-ja.1`(最新のマイルストーンブランチに適宜読み替えること)ブランチに向けてPull Requestを作成する
各翻訳ごとに、新しいPRに対して`@kubernetes/sig-docs-**-reviews`チームがレビューに自動的にアサインされます。
### マイルストーンについて {#milestones}
`@kubernetes/website-maintainers`のメンバーは、翻訳作業を調整するために新しい開発ブランチを作ることができます。
翻訳作業を集中的に管理するために、日本語を含む複数の言語ではマイルストーンを採用しています。
`@kubernetes/website-milestone-maintainers`のメンバーは、issueやPRにマイルストーンをアサインするために、`/milestone`[Prowコマンド](https://prow.k8s.io/command-help)が使用できます。
各マイルストーンでは、
### ワークフローを設定する {#configure-the-workflow}
- 最低要件のコンテンツの追加・更新(項目については[こちら](https://kubernetes.io/docs/contribute/localization/#translating-documents)を参照してください)
- バージョンに追従できていない翻訳済みコンテンツの更新
次に、`kubernetes/test-infra`リポジトリに新しい翻訳用のGitHubラベルを追加します。ラベルを利用すると、issueやプルリクエストを特定の言語のものだけにフィルタできます。
を行い、ドキュメントの全体的なメンテナンスを行っています。
ラベルを追加する例としては、[イタリア語の言語ラベル](https://github.com/kubernetes/test-infra/pull/11316)を追加するPRを見てください。
マイルストーンのバージョンはOwner権限を持つメンバーが管理するものとします。
### コミュニティを見つける
## 翻訳スタイルガイド
Kubernetes SIG Docsに、新しく翻訳チームを作りたいという意思を知らせてください！[SIG Docs Slackチャンネル](https://kubernetes.slack.com/messages/C1J0BPD2M/)に参加してください。他の言語のメンバーが、翻訳を始めるのを喜んで助けてくれ、どんな疑問にも答えてくれます。
### 基本方針
`kubernetes/community`リポジトリ内で、翻訳用のSlackチャンネルを作ることもできます。Slackチャンネルを追加する例としては、[インドネシア語とポルトガル語用のチャンネルを追加する](https://github.com/kubernetes/community/pull/3605)ためのPRを見てください。
- 本文を、敬体（ですます調）で統一
- 特に、「〜になります」「〜となります」という表現は「〜です」の方が適切な場合が多いため注意
- 句読点は「、」と「。」を使用
- 漢字、ひらがな、カタカナは全角で表記
- 数字とアルファベットは半角で表記
- スペースと括弧 `()` 、コロン `:` は半角、それ以外の記号類は全角で表記
- 英単語と日本語の間に半角スペースは不要
## 最低限必要なコンテンツ {#minimum-required-content}
### 頻出単語
### サイトの設定を修正する
英語 | 日本語
--------- | ---------
cluster|クラスター
orchestrate(動詞)|オーケストレーションする
Persistent Volume|KubernetesリソースとしてのPersistentVolumeはママ表記、一般的な用語としての場合は、永続ボリューム
Deployment/Deploy|KubernetesリソースとしてのDeploymentはママ表記、一般的な用語としてのdeployの場合は、デプロイ
Addon/Add-on|アドオン
Quota|クォータ
For more information|さらなる情報(一時的)
prefix | プレフィックス
container | コンテナ
directory | ディレクトリ
binary | バイナリ
controller | コントローラー
opeartor | オペレーター
Aggregation Layer | アグリゲーションレイヤー
Issue | Issue (ママ表記)
Pull Request | Pull Request (ママ表記)
GitHub | GitHub (ママ表記)
registry | レジストリ
architecture | アーキテクチャ
secure | セキュア
stacked | 積層(例: stacked etcd clusterは積層etcdクラスター)
a set of ~ | ～の集合
Kubernetesのウェブサイトでは、Hugoをウェブフレームワークとして使用しています。ウェブサイトのHugoの設定は、[`config.toml`](https://github.com/kubernetes/website/tree/master/config.toml)ファイルの中に書かれています。新しい翻訳をサポートするには、`config.toml`を修正する必要があります。
### 備考
`config.toml`の既存の`[languages]`ブロックの下に、新しい言語の設定ブロックを追加してください。たとえば、ドイツ語のブロックの場合、次のようになります。
ServiceやDeploymentなどのKubernetesのAPIオブジェクトや技術仕様的な固有名詞は、無理に日本語訳せずそのまま書いてください。
```toml
[languages.de]
title = "Kubernetes"
description = "Produktionsreife Container-Verwaltung"
languageName = "Deutsch"
contentDir = "content/de"
weight = 3
```
また、日本語では名詞を複数形にする意味はあまりないので、英語の名詞を利用する場合は原則として単数形で表現してください。
ブロックの`weight`パラメーターの設定では、言語の一覧から最も数字の大きい番号を探し、その値に1を加えた値を指定してください。
例:
Hugoの多言語サポートについての詳しい情報は、「[多言語モード](https://gohugo.io/content-management/multilingual/)」を参照してください。
- Kubernetes Service
- Node
- Pod
### 新しい翻訳のディレクトリを追加する
外部サイトへの参照の記事タイトルは翻訳しましょう。(一時的)
[`content`](https://github.com/kubernetes/website/tree/master/content)フォルダーに、言語用のサブディレクトリを追加してください。2文字の言語コードが`de`であるドイツ語の場合、次のようにディレクトリを作ります。
### 頻出表記（日本語）
```shell
mkdir content/de
```
よくある表記 | あるべき形
--------- | ---------
〜ので、〜から、〜だから| 〜のため 、〜ため
（あいうえお。）| （あいうえお）。
〇,〇,〇|〇、〇、〇（※今回列挙はすべて読点で統一）
### Community Code of Conductを翻訳する
### 単語末尾に長音記号(「ー」)を付けるかどうか
あなたの言語のcode of conductを追加するために、PRを[`cncf/foundation`](https://github.com/cncf/foundation/tree/master/code-of-conduct-languages)リポジトリに対して開いてください。
「サーバー」「ユーザー」など英単語をカタカナに訳すときに、末尾の「ー」を付けるかどうか。
### 翻訳したREADMEを追加する
- 「r」「re」「y」などで終わる単語については、原則付ける
- 上の頻出語のように、別途まとめたものは例外とする
他の翻訳のコントリビューターをガイドするために、kubernetes/websiteのトップレベルに新しい[`README-**.md`](https://help.github.com/articles/about-readmes/)を追加してください。ここで、`**`は2文字の言語コードです。たとえば、ドイツ語のREADMEファイルは`README-de.md`です。
参考: https://kubernetes.slack.com/archives/CAG2M83S8/p1554096635015200 辺りのやりとり
翻訳された`README-**.md`ファイルの中で、翻訳のコントリビューターにガイダンスを提供してください。`README.md`に含まれているのと同じ情報に加えて、以下の情報も追加してください。
### cron jobの訳し方に関して
- 翻訳プロジェクトのための連絡先
- 翻訳固有の情報
混同を避けるため、cron jobはcronジョブと訳し、CronJobはリソース名としてのままにする。
cron「の」ジョブは、「の」が続く事による解釈の難から基本的にはつけないものとする。
翻訳されたREADMEを作成したら、メインの英語の`README.md`からそのファイルへのリンクを追加し、英語で連絡先情報も書いてください。GitHub ID、メールアドレス、[Slackチャンネル](https://slack.com)、その他の連絡手段を提供できます。翻訳されたCommunity Code of Conductへのリンクも必ず提供してください。
### その他基本方針など
### OWNERSファイルを設定する
翻訳にコントリビュートする各ユーザーのロールを設定するには、言語用のサブディレクトリの中に`OWNERS`ファイルを作成し、以下の項目を設定します。
- **レビュアー**: レビュアーのロールを持つkubernetesチームのリストです。この場合は、[GitHubで翻訳チームを追加](#add-your-localization-team-in-github)で作成した`sig-docs-**-reviews`チームです。
- **承認者**: 承認者のロールを持つkubernetesチームのリストです。この場合は、[GitHubで翻訳チームを追加](#add-your-localization-team-in-github)で追加した`sig-docs-**-owners`チームです。
- **ラベル**: PRに自動的に適用されるGitHub上のラベルのリストです。この場合は、[ワークフローを設定する](#configure-the-workflow)で作成した言語ラベルです。
`OWNERS`ファイルに関するより詳しい情報は、[go.k8s.io/owners](https://go.k8s.io/owners)を参照してください。
言語コードが`es`の[スペイン語のOWNERSファイル](https://git.k8s.io/website/content/es/OWNERS)は次のようになります。
```yaml
# See the OWNERS docs at https://go.k8s.io/owners
# This is the localization project for Spanish.
# Teams and members are visible at https://github.com/orgs/kubernetes/teams.
reviewers:
- sig-docs-es-reviews
approvers:
- sig-docs-es-owners
labels:
- language/es
```
特定の言語用の`OWNERS`ファイルを追加したら、[ルートの`OWNERS_ALIASES`](https://git.k8s.io/website/OWNERS_ALIASES)ファイルを、翻訳のための新しいKuerbetesチーム、`sig-docs-**-owners`および`sig-docs-**-reviews`で更新します。
各チームごとに、[翻訳チームをGitHubに追加する](#add-your-localization-team-in-github)でリクエストしたGitHubユーザーのリストをアルファベット順で追加してください。
```diff
--- a/OWNERS_ALIASES
+++ b/OWNERS_ALIASES
@@ -48,6 +48,14 @@ aliases:
- stewart-yu
- xiangpengzhao
- zhangxiaoyu-zidif
+ sig-docs-es-owners: # Admins for Spanish content
+ - alexbrand
+ - raelga
+ sig-docs-es-reviews: # PR reviews for Spanish content
+ - alexbrand
+ - electrocucaracha
+ - glo-pena
+ - raelga
sig-docs-fr-owners: # Admins for French content
- perriea
- remyleone
```
## コンテンツを翻訳する
Kubernetesのドキュメントの *すべて* を翻訳するのは、非常に大きな作業です。小さく始めて、時間をかけて拡大していけば大丈夫です。
最低限、すべての翻訳には以下のコンテンツが必要です。
説明 | URL
-----|-----
ホーム | [すべての見出しと小見出しのURL](/docs/home/)
セットアップ | [すべての見出しと小見出しのURL](/docs/setup/)
チュートリアル | [Kubernetes Basics](/docs/tutorials/kubernetes-basics/)、[Hello Minikube](/docs/tutorials/hello-minikube/)
サイト文字列 | [翻訳された新しいTOMLファイル内のすべてのサイト文字列](https://github.com/kubernetes/website/tree/master/i18n)
翻訳されたドキュメントは、言語ごとに`content/**/`サブディレクトリに置き、英語のソースと同じURLパスに従うようにしなければいけません。たとえば、[Kubernetes Basics](/docs/tutorials/kubernetes-basics/)のチュートリアルをドイツ語に翻訳する準備をするには、次のように、`content/de/`フォルダ以下にサブディレクトリを作り、英語のソースをコピーします。
```shell
mkdir -p content/de/docs/tutorials
cp content/en/docs/tutorials/kubernetes-basics.md content/de/docs/tutorials/kubernetes-basics.md
```
翻訳ツールを使えば、翻訳のプロセスをスピードアップできます。たとえば、エディタによってはテキストを高速に翻訳してくれるプラグインがあります。
{{< caution >}}
機械生成された翻訳は、そのままでは最低限の品質基準を満たしません。基準を満たすためには、人間による十分なレビューが必要です。
{{< /caution >}}
文法と意味の正確さを保証するために、公開する前に翻訳チームのメンバーが機械生成されたすべての翻訳を注意深くレビューしなければいけません。
### ソースファイル
翻訳は、最新のリリース{{< latest-version >}}の英語のファイルをベースにしなければなりません。
最新のリリースのソースファイルを見つけるには、次のように探してください。
1. Kubernetesのウェブサイトのリポジトリ https://github.com/kubernetes/website に移動する。
2. 最新バージョンの`release-1.X`ブランチを選択する。
最新バージョンは{{< latest-version >}}であるため、最新のリリースブランチは[`{{< release-branch >}}`](https://github.com/kubernetes/website/tree/{{< release-branch >}})です。
### i18n/内のサイト文字列
翻訳には、[`i18n/en.toml`](https://github.com/kubernetes/website/blob/master/i18n/en.toml)の内容を新しい言語用のファイル内に含める必要があります。ドイツ語を例に取ると、ファイル名は`i18n/de.toml`です。
新しい翻訳ファイルを`i18n/`に追加します。たとえば、ドイツ語(`de`)であれば次のようになります。
```shell
cp i18n/en.toml i18n/de.toml
```
そして、各文字列の値を翻訳します。
```TOML
[docs_label_i_am]
other = "ICH BIN..."
```
サイト文字列を翻訳することで、サイト全体で使われるテキストや機能をカスタマイズできます。たとえば、各ページのフッターにある著作権のテキストなどです。
### 言語固有のスタイルガイドと用語集
一部の言語チームには、言語固有のスタイルガイドや用語集があります。たとえば、[韓国語の翻訳ガイド](/ko/docs/contribute/localization_ko/)を見てください。
## ブランチの戦略
翻訳プロジェクトは協力が非常に重要な活動のため、チームごとに共有の開発ブランチで作業することを推奨します。
開発ブランチ上で共同作業するためには、以下の手順を行います。
1. [@kubernetes/website-maintainers](https://github.com/orgs/kubernetes/teams/website-maintainers)のチームメンバーが https://github.com/kubernetes/website のソースブランチから開発ブランチを作る。
[`kubernetes/org`](https://github.com/kubernetes/org)リポジトリに[翻訳チームを追加](#add-your-localization-team-in-github)したとき、チームの承認者は`@kubernetes/website-maintainers`チームに参加します。
次のようなブランチの命名規則に従うことを推奨します。
`dev-<ソースのバージョン>-<言語コード>.<チームのマイルストーン>`
たとえば、ドイツ語の翻訳チームの承認者は、Kubernetes v1.12のソースブランチをベースに、k/websiteリポジトリから直接開発ブランチ`dev-1.12-de.1`を作ります。
2. 各コントリビューターが、開発ブランチをベースにフィーチャーブランチを作る。
たとえば、ドイツ語のコントリビューターは、`username:local-branch-name`から`kubernetes:dev-1.12-de.1`に対して、変更を含むプルリクエストを開きます。
3. 承認者がフィーチャーブランチをレビューして、開発ブランチにマージする。
4. 定期的に新しいプルリクエストを開いて承認することで、承認者が開発ブランチをソースブランチにマージする。プルリクエストを承認する前にコミットをsquashするようにしてください。
翻訳が完了するまで、1-4のステップを必要なだけ繰り返します。たとえば、ドイツ語のブランチは、`dev-1.12-de.2`、`dev-1.12-de.3`と続きます。
チームは、翻訳したコンテンツを元となったリリースブランチにマージする必要があります。たとえば、{{< release-branch >}}から作られた開発ブランチは、必ず{{< release-branch >}}にマージしなければなりません。
承認者は、ソースブランチを最新の状態に保ち、マージのコンフリクトを解決することで、開発ブランチをメンテナンスしなければなりません。開発ブランチが長く開いたままであるほど、一般により多くのメンテナンスが必要になります。そのため、非常に長い期間に渡って開発ブランチを維持するよりは、定期的に開発ブランチをマージして、新しいブランチを作ることを考えてください。
各チームマイルストーンの最初には、1つ前の開発ブランチと現在の開発ブランチの間のアップストリームの変更を比較するissueを開くと役に立ちます。
新しい開発ブランチを開いたりプルリクエストをマージできるのは承認者だけですが、新しい開発ブランチには誰でもプルリクエストを開くことができます。特別な許可は必要ありません。
フォークやリポジトリから直接行う作業についての詳しい情報は、「[リポジトリをフォーク・クローンする](#fork-and-clone-the-repo)」を読んでください。
- 意訳と直訳で迷った場合は「直訳」で訳す
- 訳で難しい・わからないと感じたらSlackの#kubernetes-docs-jaでみんなに聞く
- できることを挙手制で、できないときは早めに報告
## アップストリームのコントリビューター
SIG Docsでは、英語のソースに対する[アップストリームへのコントリビュートや誤りの訂正](/docs/contribute/intermediate#localize-content)を歓迎しています。
## 既存の翻訳を助ける
コンテンツの追加や改善により既存の翻訳を助けることもできます。翻訳のための[Slackチャンネル](https://kubernetes.slack.com/messages/C1J0BPD2M/)に参加して、助けとなるPRを開くことを始めましょう。
## {{% heading "whatsnext" %}}
翻訳がワークフローと最小限のコンテンツの要件を満たしたら、SIG docsは次の作業を行います。
- ウェブサイト上で言語の選択を有効にする。
- [Kubernetesブログ](https://kubernetes.io/blog/)を含む[Cloud Native Computing Foundation](https://www.cncf.io/about/)(CNCF)のチャンネルで、翻訳が利用できるようになったことを公表する。
content/ja/docs/home/_index.md
+2 -2
View File
@@ -18,7 +18,7 @@ menu:
description: >
Kubernetesは、コンテナ化されたアプリケーションの展開、スケーリング、また管理を自動化するためのオープンソースコンテナプラットフォームです。このオープンソースプロジェクトは、Cloud Native Computing Foundationによってホストされています。
overview: >
Kubernetesは、コンテナ化されたアプリケーションの展開、スケーリング、また管理を自動化するためのオープンソースコンテナプラットフォームです。このオープンソースプロジェクトは、Cloud Native Computing Foundationによってホストされています（<a href="https://www.cncf.io/about">CNCF</a>）。
Kubernetesは、コンテナ化されたアプリケーションの展開、スケーリング、また管理を自動化するためのオープンソースコンテナプラットフォームです。このオープンソースプロジェクトは、Cloud Native Computing Foundationによってホストされています(<a href="https://www.cncf.io/about">CNCF</a>)。
cards:
- name: concepts
title: "基本を理解する"
@@ -52,7 +52,7 @@ cards:
button_path: /docs/reference
- name: contribute
title: "ドキュメントにコントリビュートする"
description: "プロジェクトに不慣れでも、長い間関わっていたとしても、誰でもコントリビュートすることが出来ます。"
description: "プロジェクトに不慣れでも、長い間関わっていたとしても、誰でもコントリビュートすることができます。"
button: "ドキュメントにコントリビュートする"
button_path: /docs/contribute
- name: download
content/ja/docs/reference/access-authn-authz/authentication.md
+711
View File
@@ -0,0 +1,711 @@
---
title: 認証
content_type: concept
weight: 10
---
<!-- overview -->
このページでは、認証の概要について説明します。
<!-- body -->
## Kubernetesにおけるユーザー
すべてのKubernetesクラスターには、2種類のユーザーがあります。Kubernetesによって管理されるサービスアカウントと、通常のユーザーです。
通常のユーザーは外部の独立したサービスが管理することを想定しています。秘密鍵を配布する管理者、KeystoneやGoogle Accountsのようなユーザーストア、さらにはユーザー名とパスワードのリストを持つファイルなどです。この点において、_Kubernetesは通常のユーザーアカウントを表すオブジェクトを持ちません。_ APIコールを介して、通常のユーザーをクラスターに追加することはできません。
対照的に、サービスアカウントはKubernetes APIによって管理されるユーザーです。サービスアカウントは特定の名前空間にバインドされており、APIサーバーによって自動的に作成されるか、APIコールによって手動で作成されます。サービスアカウントは、`Secrets`として保存された資格情報の集合に紐付けられています。これをPodにマウントすることで、クラスター内のプロセスがKubernetes APIと通信できるようにします。
APIリクエストは、通常のユーザーかサービスアカウントに紐付けられているか、[匿名リクエスト](#anonymous-requests)として扱われます。つまり、ワークステーションで`kubectl`を入力する人間のユーザーから、ノード上の`kubelets`やコントロールプレーンのメンバーまで、クラスター内外の全てのプロセスは、APIサーバーへのリクエストを行う際に認証を行うか匿名ユーザーとして扱われる必要があります。
## 認証戦略
Kubernetesは、クライアント証明書、Bearerトークン、認証プロキシー、HTTP Basic認証を使い、認証プラグインを通してAPIリクエストを認証します。APIサーバーにHTTPリクエストが送信されると、プラグインは以下の属性をリクエストに関連付けようとします。
* ユーザー名: エンドユーザーを識別する文字列です。一般的にな値は、`kube-admin`や`jane@example.com`です。
* UID: エンドユーザーを識別する文字列であり、ユーザー名よりも一貫性と一意性を持たせようとするものです。
* グループ: 各要素がユーザーの役割を示すような意味を持つ文字列の集合です。`system:masters`や`devops-team`といった値が一般的です。
* 追加フィールド: 認証者が有用と思われる追加情報を保持する文字列のリストに対する、文字列のマップです。
すべての値は認証システムに対して非透過であり、[認可機能](/docs/reference/access-authn-authz/authorization/)が解釈した場合にのみ意味を持ちます。
一度に複数の認証方法を有効にすることができます。通常は、以下のように少なくとも2つの方法を使用するべきです。
- サービスアカウント用のサービスアカウントトークン
- ユーザー認証のための、少なくとも1つの他の方法
複数の認証モジュールが有効化されている場合、リクエストの認証に成功した最初のモジュールが、評価が簡略化します。APIサーバーは、認証の実行順序を保証しません。
`system:authenticated`グループには、すべての認証済みユーザーのグループのリストが含まれます。
他の認証プロトコル(LDAP、SAML、Kerberos、X509スキームなど)との統合は、[認証プロキシー](#authenticating-proxy)や[認証Webhook](#webhook-token-authentication)を使用して実施できます。
### X509クライアント証明書
クライアント証明書認証は、APIサーバーに`--client-ca-file=SOMEFILE`オプションを渡すことで有効になります。参照されるファイルには、APIサーバーに提示されたクライアント証明書を検証するために使用する1つ以上の認証局が含まれている必要があります。クライアント証明書が提示され、検証された場合、サブジェクトのCommon Nameがリクエストのユーザー名として使用されます。Kubernetes1.4時点では、クライアント証明書は、証明書のOrganizationフィールドを使用して、ユーザーのグループメンバーシップを示すこともできます。あるユーザーに対して複数のグループメンバーシップを含めるには、証明書に複数のOrganizationフィールドを含めます。
例えば、証明書署名要求を生成するために、`openssl`コマンドラインツールを使用します。
``` bash
openssl req -new -key jbeda.pem -out jbeda-csr.pem -subj "/CN=jbeda/O=app1/O=app2"
```
これにより、"app1"と"app2"の2つのグループに属するユーザー名"jbeda"の証明書署名要求が作成されます。
クライアント証明書の生成方法については、[証明書の管理](/docs/concepts/cluster-administration/certificates/)を参照してください。
### 静的なトークンファイル
コマンドラインで`--token-auth-file=SOMEFILE`オプションを指定すると、APIサーバーはファイルからBearerトークンを読み込みます。現在のところ、トークンの有効期限は無く、APIサーバーを再起動しない限りトークンのリストを変更することはできません。
トークンファイルは、トークン、ユーザー名、ユーザーUIDの少なくとも3つの列を持つcsvファイルで、その後にオプションでグループ名が付きます。
{{< note >}}
複数のグループがある場合はダブルクォートで囲む必要があります。
```conf
token,user,uid,"group1,group2,group3"
```
{{< /note >}}
#### リクエストにBearerトークンを含める {#putting-a-bearer-token-in-a-request}
HTTPクライアントからBearerトークン認証を利用する場合、APIサーバーは`Bearer THETOKEN`という値を持つ`Authorization`ヘッダーを待ち受けます。Bearerトークンは、HTTPのエンコーディングとクォート機能を利用してHTTPヘッダーの値に入れることができる文字列でなければなりません。例えば、Bearerトークンが`31ada4fd-adec-460c-809a-9e56ceb75269`であれば、HTTPのヘッダを以下のようにします。
```http
Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269
```
### ブートストラップトークン
{{< feature-state for_k8s_version="v1.18" state="stable" >}}
新しいクラスタの効率的なブートストラップを可能にするために、Kubernetesには*ブートストラップトークン*と呼ばれる動的に管理されたBearerトークンタイプが含まれています。これらのトークンは、`kube-system`名前空間にSecretsとして格納され、動的に管理したり作成したりすることができます。コントローラーマネージャーには、TokenCleanerコントローラーが含まれており、ブートストラップトークンの有効期限が切れると削除します。
トークンの形式は`[a-z0-9]{6}.[a-z0-9]{16}`です。最初のコンポーネントはトークンIDであり、第2のコンポーネントはToken Secretです。以下のように、トークンをHTTPヘッダーに指定します。
```http
Authorization: Bearer 781292.db7bc3a58fc5f07e
```
APIサーバーの`--enable-bootstrap-token-auth`フラグで、Bootstrap Token Authenticatorを有効にする必要があります。TokenCleanerコントローラーを有効にするには、コントローラーマネージャーの`--controllers`フラグを使います。`--controllers=*,tokencleaner`のようにして行います。クラスターをブートストラップするために`kubeadm`を使用している場合は、`kubeadm`がこれを代行してくれます。
認証機能は`system:bootstrap:<Token ID>`という名前で認証します。これは`system:bootstrappers`グループに含まれます。名前とグループは意図的に制限されており、ユーザーがブートストラップ後にこれらのトークンを使わないようにしています。ユーザー名とグループは、クラスタのブートストラップをサポートする適切な認可ポリシーを作成するために使用され、`kubeadm`によって使用されます。
ブートストラップトークンの認証機能やコントローラーについての詳細な説明、`kubeadm`でこれらのトークンを管理する方法については、[ブートストラップトークン](/docs/reference/access-authn-authz/bootstrap-tokens/)を参照してください。
### 静的なパスワードファイル
APIサーバーに`--basic-auth-file=SOMEFILE`オプションを渡すことで、Basic認証を有効にすることができます。現在のところ、Basic認証の認証情報は有効期限が無く、APIサーバーを再起動しない限りパスワードを変更することはできません。よりセキュアなモードをさらに使いやすくするための改良が完了するまでの間、現時点では利便性のためにBasic認証がサポートされていることに注意してください。
Basic認証ファイルは、トークン、ユーザー名、ユーザーIDの少なくとも3つの列を持つcsvファイルです。
Kubernetesのバージョン1.6以降では、オプションとしてカンマ区切りのグループ名を含む4列目を指定することができます。複数のグループがある場合は、4列目の値をダブルクォート(")で囲む必要があります。以下の例を参照してください。
```conf
password,user,uid,"group1,group2,group3"
```
HTTPクライアントからBasic認証を利用する場合、APIサーバーは`Basic BASE64ENCODED(USER:PASSWORD)`の値を持つ`Authorization`ヘッダーを待ち受けます。
### サービスアカウントトークン
サービスアカウントは、自動的に有効化される認証機能で、署名されたBearerトークンを使ってリクエストを検証します。このプラグインは、オプションとして2つのフラグを取ります。
* `--service-account-key-file`: Bearerトークンに署名するためのPEMエンコードされた鍵を含むファイルです。指定しない場合は、APIサーバーのTLS秘密鍵が使われます。
* `--service-account-lookup`: 有効にすると、APIから削除されたトークンは取り消されます。
サービスアカウントは通常、APIサーバーによって自動的に作成され、`ServiceAccount`[Admission Controller](/docs/reference/access-authn-authz/admission-controllers/)を介してクラスター内のPodに関連付けられます。Bearerトークンは、Podのよく知られた場所にマウントされ、これによりクラスター内のプロセスがAPIサーバー通信できるようになります。アカウントは`PodSpec`の`serviceAccountName`フィールドを使って、明示的にPodに関連付けることができます。
{{< note >}}
自動で行われるため、通常`serviceAccountName`は省略します。
{{< /note >}}
```yaml
apiVersion: apps/v1 # このapiVersionは、Kubernetes1.9時点で適切です
kind: Deployment
metadata:
name: nginx-deployment
namespace: default
spec:
replicas: 3
template:
metadata:
# ...
spec:
serviceAccountName: bob-the-bot
containers:
- name: nginx
image: nginx:1.14.2
```
サービスアカウントのBearerトークンは、クラスター外で使用するために完全に有効であり、Kubernetes APIと通信したい長期的なジョブのアイデンティティを作成するために使用することができます。サービスアカウントを手動で作成するには、単に`kubectl create serviceaccount (NAME)`コマンドを使用します。これにより、現在の名前空間にサービスアカウントと関連するSecretが作成されます。
```bash
kubectl create serviceaccount jenkins
```
```none
serviceaccount "jenkins" created
```
以下のように、関連するSecretを確認できます。
```bash
kubectl get serviceaccounts jenkins -o yaml
```
```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
# ...
secrets:
- name: jenkins-token-1yvwg
```
作成されたSecretは、APIサーバーのパブリック認証局と署名されたJSON Web Token(JWT)を保持します。
```bash
kubectl get secret jenkins-token-1yvwg -o yaml
```
```yaml
apiVersion: v1
data:
ca.crt: (base64でエンコードされたAPIサーバーの認証局)
namespace: ZGVmYXVsdA==
token: (base64でエンコードされたBearerトークン)
kind: Secret
metadata:
# ...
type: kubernetes.io/service-account-token
```
{{< note >}}
Secretは常にbase64でエンコードされるため、これらの値もbase64でエンコードされています。
{{< /note >}}
署名されたJWTは、与えられたサービスアカウントとして認証するためのBearerトークンとして使用できます。トークンをリクエストに含める方法については、[リクエストにBearerトークンを含める](#putting-a-bearer-token-in-a-request)を参照してください。通常、これらのSecretはAPIサーバーへのクラスタ内アクセス用にPodにマウントされますが、クラスター外からも使用することができます。
サービスアカウントは、ユーザー名`system:serviceaccount:(NAMESPACE):(SERVICEACCOUNT)`で認証され、グループ`system:serviceaccounts`と`system:serviceaccounts:(NAMESPACE)`に割り当てられます。
警告: サービスアカウントトークンはSecretに保持されているため、Secretにアクセスできるユーザーは誰でもサービスアカウントとして認証することができます。サービスアカウントに権限を付与したり、Secretの読み取り機能を付与したりする際には注意が必要です。
### OpenID Connectトークン
[OpenID Connect](https://openid.net/connect/)は、Azure Active Directory、Salesforce、Googleなど、いくつかのOAuth2プロバイダーでサポートされているOAuth2の一種です。
このプロトコルのOAuth2の主な拡張機能は、[ID Token](https://openid.net/specs/openid-connect-core-1_0.html#IDToken)と呼ばれる、アクセストークンとアクセストークンと一緒に返される追加フィールドです。
このトークンは、ユーザーの電子メールなどのよく知られたフィールドを持つJSON Web Token(JWT)であり、サーバーによって署名されています。トークンをリクエストに含める方法については、[リクエストにBearerトークンを含める](#putting-a-bearer-token-in-a-request)を参照してください。
![Kubernetes OpenID Connect Flow](/images/docs/admin/k8s_oidc_login.svg)
1. IDプロバイダーにログインします
2. IDプロバイダーは、`access_token`、`id_token`、`refresh_token`を提供します
3. `kubectl`を使う場合は、`--token`フラグで`id_token`を使うか、`kubeconfig`に直接追加してください
4. `kubectl`は、`id_token`をAuthorizationと呼ばれるヘッダーでAPIサーバーに送ります
5. APIサーバーは、設定で指定された証明書と照合することで、JWT署名が有効であることを確認します
6. `id_token`の有効期限が切れていないことを確認します
7. ユーザーが認可されていることを確認します
8. 認可されると、APIサーバーは`kubectl`にレスポンスを返します
9. `kubectl`はユーザーにフィードバックを提供します
自分が誰であるかを確認するために必要なデータはすべて`id_token`の中にあるので、KubernetesはIDプロバイダーと通信する必要がありません。すべてのリクエストがステートレスであるモデルでは、これは非常に認証のためのスケーラブルなソリューションを提供します。一方で、以下のようにいくつか課題があります。
1. Kubernetesには、認証プロセスを起動するための"Webインターフェース"がありません。クレデンシャルを収集するためのブラウザやインターフェースがないため、まずIDプロバイダに認証を行う必要があります。
2. `id_token`は、取り消すことができません。これは証明書のようなもので、有効期限が短い(数分のみ)必要があるので、数分ごとに新しいトークンを取得しなければならないのは非常に面倒です。
3. Kubernetesダッシュボードへの認証において、`kubectl proxy`コマンドや`id_token`を注入するリバースプロキシーを使う以外に、簡単な方法はありません。
#### APIサーバーの設定
プラグインを有効にするには、APIサーバーで以下のフラグを設定します。
| パラメーター | 説明 | 例 | 必須か |
| --------- | ----------- | ------- | ------- |
| `--oidc-issuer-url` | APIサーバーが公開署名鍵を発見できるようにするプロバイダーのURLです。 `https://`スキームを使用するURLのみが受け入れられます。これは通常、"https://accounts.google.com"や"https://login.salesforce.com"のようにパスを持たないプロバイダのディスカバリーURLです。このURLは、`.well-known/openid-configuration`の下のレベルを指す必要があります。 | ディスカバリーURLが`https://accounts.google.com/.well-known/openid-configuration`である場合、値は`https://accounts.google.com`とします。 | はい |
| `--oidc-client-id` | すべてのトークンが発行されなければならないクライアントIDです。 | kubernetes | はい |
| `--oidc-username-claim` | ユーザー名として使用するJWTのクレームを指定します。デフォルトでは`sub`が使用されますが、これはエンドユーザーの一意の識別子であることが期待されます。管理者はプロバイダーに応じて`email`や`name`などの他のクレームを選択することができます。ただし、他のプラグインとの名前の衝突を防ぐために、`email`以外のクレームには、プレフィックスとして発行者のURLが付けられます。 | sub | いいえ |
| `--oidc-username-prefix` | 既存の名前(`system:`ユーザーなど)との衝突を防ぐために、ユーザー名の前にプレフィックスを付加します。例えば`oidc:`という値は、`oidc:jane.doe`のようなユーザー名を生成します。このフラグが指定されておらず、`--oidc-username-claim`が`email`以外の値である場合、プレフィックスのデフォルトは`(Issuer URL)#`で、`(Issuer URL)`は`--oidc-issuer-url`の値です。すべてのプレフィックスを無効にするためには、`-`という値を使用できます。 | `oidc:` | いいえ |
| `--oidc-groups-claim` | ユーザーのグループとして使用するJWTのクレームです。クレームがある場合は、文字列の配列である必要があります。 | groups | いいえ |
| `--oidc-groups-prefix` | 既存の名前(`system:`グループなど)との衝突を防ぐために、グループ名の前にプレフィックスを付加します。例えば`oidc:`という値は、`oidc:engineering`や`oidc:infra`のようなグループ名を生成します。 | `oidc:` | いいえ |
| `--oidc-required-claim` | IDトークンの中の必須クレームを記述するkey=valueのペアです。設定されている場合、クレームが一致する値でIDトークンに存在することが検証されます。このフラグを繰り返して複数のクレームを指定します。 | `claim=value` | いいえ |
| `--oidc-ca-file` | IDプロバイダーのWeb証明書に署名した認証局の証明書へのパスです。デフォルトはホストのルート認証局が指定されます。 | `/etc/kubernetes/ssl/kc-ca.pem` | いいえ |
重要なのは、APIサーバーはOAuth2クライアントではなく、ある単一の発行者を信頼するようにしか設定できないことです。これにより、サードパーティーに発行されたクレデンシャルを信頼せずに、Googleのようなパブリックプロバイダーを使用することができます。複数のOAuthクライアントを利用したい管理者は、`azp`クレームをサポートしているプロバイダや、あるクライアントが別のクライアントに代わってトークンを発行できるような仕組みを検討する必要があります。
KubernetesはOpenID Connect IDプロバイダーを提供していません。既存のパブリックなOpenID Connect IDプロバイダー(Googleや[その他](http://connect2id.com/products/nimbus-oauth-openid-connect-sdk/openid-connect-providers)など)を使用できます。もしくは、CoreOS [dex](https://github.com/coreos/dex)、[Keycloak](https://github.com/keycloak/keycloak)、CloudFoundry[UAA](https://github.com/cloudfoundry/uaa)、Tremolo Securityの[OpenUnison](https://github.com/tremolosecurity/openunison)など、独自のIDプロバイダーを実行することもできます。
IDプロバイダーがKubernetesと連携するためには、以下のことが必要です。
1. すべてではないが、[OpenID Connect Discovery](https://openid.net/specs/openid-connect-discovery-1_0.html）をサポートしていること
2. 廃れていない暗号を用いたTLSで実行されていること
3. 認証局が署名した証明書を持っていること(認証局が商用ではない場合や、自己署名の場合も可)
上述の要件#3、認証局署名付き証明書を必要とすることについて、注意事項があります。GoogleやMicrosoftなどのクラウドプロバイダーではなく、独自のIDプロバイダーをデプロイする場合は、たとえ自己署名されていても、`CA`フラグが`TRUE`に設定されている証明書によって署名されたIDプロバイダーのWebサーバー証明書を持っていなければなりません。これは、Go言語のTLSクライアント実装が、証明書検証に関する標準に対して非常に厳格であるためです。認証局をお持ちでない場合は、CoreOSチームの[このスクリプト](https://github.com/coreos/dex/blob/1ee5920c54f5926d6468d2607c728b71cfe98092/examples/k8s/gencert.sh)を使用して、シンプルな認証局と署名付きの証明書と鍵のペアを作成することができます。
または、[この類似のスクリプト](https://raw.githubusercontent.com/TremoloSecurity/openunison-qs-kubernetes/master/src/main/bash/makessl.sh)を使って、より寿命が長く、よりキーサイズの大きいSHA256証明書を生成できます。
特定のシステム用のセットアップ手順は、以下を参照してください。
- [UAA](https://docs.cloudfoundry.org/concepts/architecture/uaa.html)
- [Dex](https://github.com/dexidp/dex/blob/master/Documentation/kubernetes.md)
- [OpenUnison](https://www.tremolosecurity.com/orchestra-k8s/)
#### kubectlの使用
##### 選択肢1 - OIDC認証機能
最初の選択肢は、kubectlの`oidc`認証機能を利用することです。これはすべてのリクエストのBearerトークンとして`id_token`を設定し、有効期限が切れるとトークンを更新します。プロバイダーにログインした後、kubectlを使って`id_token`、`refresh_token`、`client_id`、`client_secret`を追加してプラグインを設定します。
リフレッシュトークンのレスポンスの一部として`id_token`を返さないプロバイダーは、このプラグインではサポートされていないので、以下の"選択肢2"を使用してください。
```bash
kubectl config set-credentials USER_NAME \
--auth-provider=oidc \
--auth-provider-arg=idp-issuer-url=( issuer url ) \
--auth-provider-arg=client-id=( your client id ) \
--auth-provider-arg=client-secret=( your client secret ) \
--auth-provider-arg=refresh-token=( your refresh token ) \
--auth-provider-arg=idp-certificate-authority=( path to your ca certificate ) \
--auth-provider-arg=id-token=( your id_token )
```
例として、IDプロバイダーに認証した後に以下のコマンドを実行します。
```bash
kubectl config set-credentials mmosley \
--auth-provider=oidc \
--auth-provider-arg=idp-issuer-url=https://oidcidp.tremolo.lan:8443/auth/idp/OidcIdP \
--auth-provider-arg=client-id=kubernetes \
--auth-provider-arg=client-secret=1db158f6-177d-4d9c-8a8b-d36869918ec5 \
--auth-provider-arg=refresh-token=q1bKLFOyUiosTfawzA93TzZIDzH2TNa2SMm0zEiPKTUwME6BkEo6Sql5yUWVBSWpKUGphaWpxSVAfekBOZbBhaEW+VlFUeVRGcluyVF5JT4+haZmPsluFoFu5XkpXk5BXqHega4GAXlF+ma+vmYpFcHe5eZR+slBFpZKtQA= \
--auth-provider-arg=idp-certificate-authority=/root/ca.pem \
--auth-provider-arg=id-token=eyJraWQiOiJDTj1vaWRjaWRwLnRyZW1vbG8ubGFuLCBPVT1EZW1vLCBPPVRybWVvbG8gU2VjdXJpdHksIEw9QXJsaW5ndG9uLCBTVD1WaXJnaW5pYSwgQz1VUy1DTj1rdWJlLWNhLTEyMDIxNDc5MjEwMzYwNzMyMTUyIiwiYWxnIjoiUlMyNTYifQ.eyJpc3MiOiJodHRwczovL29pZGNpZHAudHJlbW9sby5sYW46ODQ0My9hdXRoL2lkcC9PaWRjSWRQIiwiYXVkIjoia3ViZXJuZXRlcyIsImV4cCI6MTQ4MzU0OTUxMSwianRpIjoiMm96US15TXdFcHV4WDlHZUhQdy1hZyIsImlhdCI6MTQ4MzU0OTQ1MSwibmJmIjoxNDgzNTQ5MzMxLCJzdWIiOiI0YWViMzdiYS1iNjQ1LTQ4ZmQtYWIzMC0xYTAxZWU0MWUyMTgifQ.w6p4J_6qQ1HzTG9nrEOrubxIMb9K5hzcMPxc9IxPx2K4xO9l-oFiUw93daH3m5pluP6K7eOE6txBuRVfEcpJSwlelsOsW8gb8VJcnzMS9EnZpeA0tW_p-mnkFc3VcfyXuhe5R3G7aa5d8uHv70yJ9Y3-UhjiN9EhpMdfPAoEB9fYKKkJRzF7utTTIPGrSaSU6d2pcpfYKaxIwePzEkT4DfcQthoZdy9ucNvvLoi1DIC-UocFD8HLs8LYKEqSxQvOcvnThbObJ9af71EwmuE21fO5KzMW20KtAeget1gnldOosPtz1G5EwvaQ401-RPQzPGMVBld0_zMCAwZttJ4knw
```
これは以下のような構成になります。
```yaml
users:
- name: mmosley
user:
auth-provider:
config:
client-id: kubernetes
client-secret: 1db158f6-177d-4d9c-8a8b-d36869918ec5
id-token: eyJraWQiOiJDTj1vaWRjaWRwLnRyZW1vbG8ubGFuLCBPVT1EZW1vLCBPPVRybWVvbG8gU2VjdXJpdHksIEw9QXJsaW5ndG9uLCBTVD1WaXJnaW5pYSwgQz1VUy1DTj1rdWJlLWNhLTEyMDIxNDc5MjEwMzYwNzMyMTUyIiwiYWxnIjoiUlMyNTYifQ.eyJpc3MiOiJodHRwczovL29pZGNpZHAudHJlbW9sby5sYW46ODQ0My9hdXRoL2lkcC9PaWRjSWRQIiwiYXVkIjoia3ViZXJuZXRlcyIsImV4cCI6MTQ4MzU0OTUxMSwianRpIjoiMm96US15TXdFcHV4WDlHZUhQdy1hZyIsImlhdCI6MTQ4MzU0OTQ1MSwibmJmIjoxNDgzNTQ5MzMxLCJzdWIiOiI0YWViMzdiYS1iNjQ1LTQ4ZmQtYWIzMC0xYTAxZWU0MWUyMTgifQ.w6p4J_6qQ1HzTG9nrEOrubxIMb9K5hzcMPxc9IxPx2K4xO9l-oFiUw93daH3m5pluP6K7eOE6txBuRVfEcpJSwlelsOsW8gb8VJcnzMS9EnZpeA0tW_p-mnkFc3VcfyXuhe5R3G7aa5d8uHv70yJ9Y3-UhjiN9EhpMdfPAoEB9fYKKkJRzF7utTTIPGrSaSU6d2pcpfYKaxIwePzEkT4DfcQthoZdy9ucNvvLoi1DIC-UocFD8HLs8LYKEqSxQvOcvnThbObJ9af71EwmuE21fO5KzMW20KtAeget1gnldOosPtz1G5EwvaQ401-RPQzPGMVBld0_zMCAwZttJ4knw
idp-certificate-authority: /root/ca.pem
idp-issuer-url: https://oidcidp.tremolo.lan:8443/auth/idp/OidcIdP
refresh-token: q1bKLFOyUiosTfawzA93TzZIDzH2TNa2SMm0zEiPKTUwME6BkEo6Sql5yUWVBSWpKUGphaWpxSVAfekBOZbBhaEW+VlFUeVRGcluyVF5JT4+haZmPsluFoFu5XkpXk5BXq
name: oidc
```
`id_token`の有効期限が切れると、`kubectl`は`refresh_token`と`client_secret`を用いて`id_token`の更新しようとします。`refresh_token`と`id_token`の新しい値は、`.kube/config`に格納されます。
##### 選択肢2 - `--token`オプションの使用
`kubectl`コマンドでは、`--token`オプションを使ってトークンを渡すことができる。以下のように、このオプションに`id_token`をコピーして貼り付けるだけです。
```bash
kubectl --token=eyJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJodHRwczovL21sYi50cmVtb2xvLmxhbjo4MDQzL2F1dGgvaWRwL29pZGMiLCJhdWQiOiJrdWJlcm5ldGVzIiwiZXhwIjoxNDc0NTk2NjY5LCJqdGkiOiI2RDUzNXoxUEpFNjJOR3QxaWVyYm9RIiwiaWF0IjoxNDc0NTk2MzY5LCJuYmYiOjE0NzQ1OTYyNDksInN1YiI6Im13aW5kdSIsInVzZXJfcm9sZSI6WyJ1c2VycyIsIm5ldy1uYW1lc3BhY2Utdmlld2VyIl0sImVtYWlsIjoibXdpbmR1QG5vbW9yZWplZGkuY29tIn0.f2As579n9VNoaKzoF-dOQGmXkFKf1FMyNV0-va_B63jn-_n9LGSCca_6IVMP8pO-Zb4KvRqGyTP0r3HkHxYy5c81AnIh8ijarruczl-TK_yF5akjSTHFZD-0gRzlevBDiH8Q79NAr-ky0P4iIXS8lY9Vnjch5MF74Zx0c3alKJHJUnnpjIACByfF2SCaYzbWFMUNat-K1PaUk5-ujMBG7yYnr95xD-63n8CO8teGUAAEMx6zRjzfhnhbzX-ajwZLGwGUBT4WqjMs70-6a7_8gZmLZb2az1cZynkFRj2BaCkVT3A2RrjeEwZEtGXlMqKJ1_I2ulrOVsYx01_yD35-rw get nodes
```
### Webhookトークン認証 {#webhook-token-authentication}
Webhook認証は、Bearerトークンを検証するためのフックです。
* `--authentication-token-webhook-config-file`: リモートのWebhookサービスへのアクセス方法を記述した設定ファイルです
* `--authentication-token-webhook-cache-ttl`: 認証をキャッシュする時間を決定します。デフォルトは2分です
設定ファイルは、[kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)のファイル形式を使用します。
ファイル内で、`clusters`はリモートサービスを、`users`はAPIサーバーのWebhookを指します。例えば、以下のようになります。
```yaml
# Kubernetes APIのバージョン
apiVersion: v1
# APIオブジェクトの種類
kind: Config
# clustersは、リモートサービスを指します。
clusters:
- name: name-of-remote-authn-service
cluster:
certificate-authority: /path/to/ca.pem # リモートサービスを検証するためのCA
server: https://authn.example.com/authenticate # クエリするリモートサービスのURL。'https'を使用する必要があります。
# usersは、APIサーバーのWebhook設定を指します。
users:
- name: name-of-api-server
user:
client-certificate: /path/to/cert.pem # Webhookプラグインを使うための証明書
client-key: /path/to/key.pem # 証明書に合致する鍵
# kubeconfigファイルにはコンテキストが必要です。APIサーバー用のものを用意してください。
current-context: webhook
contexts:
- context:
cluster: name-of-remote-authn-service
user: name-of-api-sever
name: webhook
```
クライアントが[上記](#putting-a-bearer-token-in-a-request)のようにBearerトークンを使用してAPIサーバーとの認証を試みた場合、認証Webhookはトークンを含むJSONでシリアライズされた`authentication.k8s.io/v1beta1` `TokenReview`オブジェクトをリモートサービスにPOSTします。Kubernetesはそのようなヘッダーが不足しているリクエストを作成しようとはしません。
Webhook APIオブジェクトは、他のKubernetes APIオブジェクトと同じように、[Versioning Compatibility Rule](/docs/concepts/overview/kubernetes-api/)に従うことに注意してください。実装者は、ベータオブジェクトで保証される互換性が緩いことに注意し、正しいデシリアライゼーションが使用されるようにリクエストの"apiVersion"フィールドを確認する必要があります。さらにAPIサーバーは、API拡張グループ`authentication.k8s.io/v1beta1`を有効にしなければなりません(`--runtime config=authentication.k8s.io/v1beta1=true`)。
POSTボディは、以下の形式になります。
```json
{
"apiVersion": "authentication.k8s.io/v1beta1",
"kind": "TokenReview",
"spec": {
"token": "(Bearerトークン)"
}
}
```
リモートサービスはログインの成功を示すために、リクエストの`status`フィールドを埋めることが期待されます。レスポンスボディの`spec`フィールドは無視され、省略することができます。Bearerトークンの検証に成功すると、以下のようにBearerトークンが返されます。
```json
{
"apiVersion": "authentication.k8s.io/v1beta1",
"kind": "TokenReview",
"status": {
"authenticated": true,
"user": {
"username": "janedoe@example.com",
"uid": "42",
"groups": [
"developers",
"qa"
],
"extra": {
"extrafield1": [
"extravalue1",
"extravalue2"
]
}
}
}
}
```
リクエストに失敗した場合は、以下のように返されます。
```json
{
"apiVersion": "authentication.k8s.io/v1beta1",
"kind": "TokenReview",
"status": {
"authenticated": false
}
}
```
HTTPステータスコードは、追加のエラーコンテキストを提供するために使うことができます。
### 認証プロキシー {#authenticating-proxy}
APIサーバーは、`X-Remote-User`のようにリクエストヘッダの値からユーザーを識別するように設定することができます。
これは、リクエストヘッダの値を設定する認証プロキシーと組み合わせて使用するために設計です。
* `--requestheader-username-headers`: 必須であり、大文字小文字を区別しません。ユーザーのIDをチェックするためのヘッダー名を順番に指定します。値を含む最初のヘッダーが、ユーザー名として使われます。
* `--requestheader-group-headers`: バージョン1.6以降で任意であり、大文字小文字を区別しません。"X-Remote-Group"を推奨します。ユーザーのグループをチェックするためのヘッダー名を順番に指定します。指定されたヘッダーの全ての値が、グループ名として使われます。
* `--requestheader-extra-headers-prefix` バージョン1.6以降で任意であり、大文字小文字を区別しません。"X-Remote-Extra-"を推奨します。ユーザーに関する追加情報を判断するために検索するヘッダーのプレフィックスです。通常、設定された認可プラグインによって使用されます。指定されたプレフィックスのいずれかで始まるヘッダーは、プレフィックスが削除されます。ヘッダー名の残りの部分は小文字化され[パーセントデコーディング](https://tools.ietf.org/html/rfc3986#section-2.1)されて追加のキーとなり、ヘッダーの値が追加の値となります。
{{< note >}}
1.11.3(および1.10.7、1.9.11)よりも前のバージョンでは、追加のキーには[HTTPヘッダーラベルで使用可能な文字](https://tools.ietf.org/html/rfc7230#section-3.2.6)のみを含めることができました。
{{< /note >}}
例えば、このような設定を行います。
```
--requestheader-username-headers=X-Remote-User
--requestheader-group-headers=X-Remote-Group
--requestheader-extra-headers-prefix=X-Remote-Extra-
```
以下のようなリクエストを考えます。
```http
GET / HTTP/1.1
X-Remote-User: fido
X-Remote-Group: dogs
X-Remote-Group: dachshunds
X-Remote-Extra-Acme.com%2Fproject: some-project
X-Remote-Extra-Scopes: openid
X-Remote-Extra-Scopes: profile
```
このリクエストは、このユーザー情報を取得します。
```yaml
name: fido
groups:
- dogs
- dachshunds
extra:
acme.com/project:
- some-project
scopes:
- openid
- profile
```
ヘッダーのスプーフィングを防ぐため、認証プロキシーはリクエストヘッダーがチェックされる前に、指定された認証局に対する検証のために有効なクライアント証明書をAPIサーバーへ提示する必要があります。
* `--requestheader-client-ca-file`: 必須です。PEMエンコードされた証明書バンドルです。有効なクライアント証明書を提示し、リクエストヘッダーでユーザー名がチェックされる前に、指定されたファイル内の認証局に対して検証する必要があります。
* `--requestheader-allowed-names`: 任意です。Common Name(CN)の値のリストです。設定されている場合、リクエストヘッダーでユーザー名がチェックされる前に、指定されたリストのCNを持つ有効なクライアント証明書を提示する必要があります。空の場合は、任意のCNが許可されます。
## 匿名リクエスト {#anonymous-requests}
この機能を有効にすると、他の設定された認証方法で拒否されなかったリクエストは匿名リクエストとして扱われ、 `system:anonymous`というユーザー名と`system:unauthenticated`というグループが与えられます。
例えば、トークン認証が設定されており、匿名アクセスが有効になっているサーバー上で、無効なBearerトークンを提供するリクエストは`401 Unauthorized`エラーを受け取ります。Bearerトークンを提供しないリクエストは匿名リクエストとして扱われます。
バージョン1.5.1から1.5.xでは、匿名アクセスはデフォルトでは無効になっており、APIサーバーに `--anonymous-auth=true`オプションを渡すことで有効にすることができます。
バージョン1.6以降では、`AlwaysAllow`以外の認証モードが使用されている場合、匿名アクセスがデフォルトで有効であり、`--anonymous-auth=false`オプションをAPIサーバーに渡すことで無効にできます。
1.6以降、ABACおよびRBAC認可機能は、`system:anonymous`ユーザーまたは`system:unauthenticated`グループの明示的な認証を必要とするようになったため、`*`ユーザーまたは`*`グループへのアクセスを許可する従来のポリシールールには匿名ユーザーは含まれません。
## ユーザーの偽装
ユーザーは偽装ヘッダーを使って別のユーザーとして振る舞うことができます。これにより、リクエストが認証したユーザー情報を手動で上書きすることが可能です。例えば、管理者はこの機能を使って一時的に別のユーザーに偽装、リクエストが拒否されたかどうかを確認することで認可ポリシーをデバッグすることができます。
偽装リクエストは最初にリクエスト中のユーザーとして認証を行い、次に偽装ユーザー情報に切り替えます。
* ユーザーは、認証情報と偽装ヘッダーを使ってAPIコールを行います。
* APIサーバーはユーザーを認証します。
* APIサーバーは、認証されたユーザーが偽装した権限を持っていることを確認します。
* リクエストされたユーザー情報は、偽装した値に置き換えられます。
* リクエストが評価され、認可は偽装されたユーザー情報に基づいて実行されます。
偽装リクエストを実行する際には、以下のHTTPヘッダを使用することができます。
* `Impersonate-User`: ユーザー名を指定します。このユーザーとして振る舞います。
* `Impersonate-Group`: グループ名を指定します。このグループとして振る舞います。複数回指定して複数のグループを設定することができます。任意であり、"Impersonate-User"が必要です。
* `Impersonate-Extra-( extra name )`: 追加フィールドをユーザーに関連付けるために使用される動的なヘッダーです。任意であり、"Impersonate-User"が必要です。一貫して保存されるためには、`( extra name )`は小文字である必要があり、[HTTPヘッダーラベルで使用可能な文字](https://tools.ietf.org/html/rfc7230#section-3.2.6)以外の文字は、UTF-8であり、[パーセントエンコーディング](https://tools.ietf.org/html/rfc3986#section-2.1)されている必要があります.
{{< note >}}
1.11.3(および1.10.7、1.9.11)よりも前のバージョンでは、`( extra name )`には[HTTPヘッダーラベルで使用可能な文字](https://tools.ietf.org/html/rfc7230#section-3.2.6)のみを含めることができました。
{{< /note >}}
以下が、ヘッダーの例です。
```http
Impersonate-User: jane.doe@example.com
Impersonate-Group: developers
Impersonate-Group: admins
Impersonate-Extra-dn: cn=jane,ou=engineers,dc=example,dc=com
Impersonate-Extra-acme.com%2Fproject: some-project
Impersonate-Extra-scopes: view
Impersonate-Extra-scopes: development
```
`kubectl`を使う場合は、`--as`フラグに`Impersonate-User`ヘッダーを、`--as-group`フラグに`Impersonate-Group`ヘッダーを設定します。
```bash
kubectl drain mynode
```
```none
Error from server (Forbidden): User "clark" cannot get nodes at the cluster scope. (get nodes mynode)
```
`--as`フラグと`--as-group`フラグを設定します。
```bash
kubectl drain mynode --as=superman --as-group=system:masters
```
```none
node/mynode cordoned
node/mynode drained
```
ユーザー、グループ、または追加フィールドを偽装するために、偽装ユーザーは偽装される属性の種類("user"、"group"など)に対して、"偽装した"操作を行う能力を持っている必要があります。RBAC認可プラグインが有効なクラスターの場合、以下のClusterRoleは、ユーザーとグループの偽装ヘッダーを設定するために必要なルールを網羅しています。
```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: impersonator
rules:
- apiGroups: [""]
resources: ["users", "groups", "serviceaccounts"]
verbs: ["impersonate"]
```
追加フィールドは、"userextras"リソースのサブリソースとして評価されます。ユーザーが追加フィールド"scopes"に偽装ヘッダーを使用できるようにするには、ユーザーに以下のようなロールを付与する必要があります。
```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: scopes-impersonator
rules:
# "Impersonate-Extra-scopes"ヘッダーを設定できます。
- apiGroups: ["authentication.k8s.io"]
resources: ["userextras/scopes"]
verbs: ["impersonate"]
```
偽装ヘッダーの値は、リソースが取り得る`resourceNames`の集合を制限することで、管理することもできます。
```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: limited-impersonator
rules:
# "jane.doe@example.com"というユーザーを偽装できます。
- apiGroups: [""]
resources: ["users"]
verbs: ["impersonate"]
resourceNames: ["jane.doe@example.com"]
# "developers"と"admins"というグループを偽装できます。
- apiGroups: [""]
resources: ["groups"]
verbs: ["impersonate"]
resourceNames: ["developers","admins"]
# "view"と"development"を値に持つ"scopes"という追加フィールドを偽装できます。
- apiGroups: ["authentication.k8s.io"]
resources: ["userextras/scopes"]
verbs: ["impersonate"]
resourceNames: ["view", "development"]
```
## client-goクレデンシャルプラグイン
{{< feature-state for_k8s_version="v1.11" state="beta" >}}
`k8s.io/client-go`と、それを使用する`kubectl`や`kubelet`のようなツールは、外部コマンドを実行してユーザーの認証情報を受け取ることができます。
この機能は`k8s.io/client-go`がネイティブにサポートしていない認証プロトコル(LDAP、Kerberos、OAuth2、SAMLなど)とクライアントサイドで統合するためのものです。プラグインはプロトコル固有のロジックを実装し、使用する不透明なクレデンシャルを返します。ほとんどすべてのクレデンシャルプラグインのユースケースでは、クライアントプラグインが生成するクレデンシャルフォーマットを解釈するために、[Webhookトークン認証](#webhook-token-authentication)をサポートするサーバーサイドコンポーネントが必要です。
### 使用例
ある組織は、LDAPクレデンシャルをユーザー固有の署名済みトークンと交換する外部サービスを実行すると仮定します。このサービスは、トークンを検証するために[Webhookトークン認証](#webhook-token-authentication)リクエストに応答することもできます。ユーザーはワークステーションにクレデンシャルプラグインをインストールする必要があります。
以下のようにして、APIに対して認証を行います。
* ユーザーは`kubectl`コマンドを発行します。
* クレデンシャルプラグインは、LDAPクレデンシャルの入力をユーザーに要求し、クレデンシャルを外部サービスとトークンと交換します。
* クレデンシャルプラグインはトークンを`client-go`に返します。これはAPIサーバーに対するBearerトークンとして使用されます。
* APIサーバーは、[Webhookトークン認証](#webhook-token-authentication)を使用して、`TokenReview`を外部サービスに送信します。
* 外部サービスはトークンの署名を検証し、ユーザーのユーザー名とグループを返します。
### 設定
クレデンシャルプラグインの設定は、userフィールドの一部として[kubectlの設定ファイル](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)で行います。
```yaml
apiVersion: v1
kind: Config
users:
- name: my-user
user:
exec:
# 実行するコマンドです。必須です。
command: "example-client-go-exec-plugin"
# ExecCredentialsリソースをデコードする際に使用するAPIのバージョン。必須です。
#
# プラグインが返すAPIのバージョンは、ここに記載されているバージョンと一致しなければなりません
#
# 複数のバージョンをサポートするツール(client.authentication.k8s.io/v1alpha1など)と統合するには、
# 環境変数を設定するか、execプラグインが期待するバージョンを示す引数をツールに渡します。
apiVersion: "client.authentication.k8s.io/v1beta1"
# プラグインを実行する際に設定する環境変数です。任意です。
env:
- name: "FOO"
value: "bar"
# プラグインを実行する際に渡す引数です。任意です。
args:
- "arg1"
- "arg2"
clusters:
- name: my-cluster
cluster:
server: "https://172.17.4.100:6443"
certificate-authority: "/etc/kubernetes/ca.pem"
contexts:
- name: my-cluster
context:
cluster: my-cluster
user: my-user
current-context: my-cluster
```
相対的なコマンドパスは、設定ファイルのディレクトリーからの相対的なものとして解釈されます。KUBECONFIGが`/home/jane/kubeconfig`に設定されていて、execコマンドが`./bin/example-client-go-exec-plugin`の場合、バイナリー`/home/jane/bin/example-client-go-exec-plugin`が実行されます。
```yaml
- name: my-user
user:
exec:
# kubeconfigのディレクトリーへの相対パス
command: "./bin/example-client-go-exec-plugin"
apiVersion: "client.authentication.k8s.io/v1beta1"
```
### 入出力フォーマット
実行されたコマンドは`ExecCredential`オブジェクトを`stdout`に出力します。`k8s.io/client-go`は`status`で返された認証情報を用いて、Kubernetes APIに対して認証を行ういます。
対話的なセッションから実行する場合、`stdin`はプラグインに直接公開されます。プラグインは[TTYチェック](https://godoc.org/golang.org/x/crypto/ssh/terminal#IsTerminal)を使って、対話的にユーザーにプロンプトを出すことが適切かどうかを判断する必要があります。
Bearerトークンのクレデンシャルを使用するために、プラグインは`ExecCredential`のステータスにトークンを返します。
```json
{
"apiVersion": "client.authentication.k8s.io/v1beta1",
"kind": "ExecCredential",
"status": {
"token": "my-bearer-token"
}
}
```
あるいは、PEMエンコードされたクライアント証明書と鍵を返して、TLSクライアント認証を使用することもできます。
プラグインが後続の呼び出しで異なる証明書と鍵を返すと、`k8s.io/client-go`はサーバーとの既存の接続を閉じて、新しいTLSハンドシェイクを強制します
指定された場合、`clientKeyData`と`clientCertificateData`両方が存在しなければなりません。
`clientCertificateData`には、サーバーに送信するための中間証明書を含めることができます。
```json
{
"apiVersion": "client.authentication.k8s.io/v1beta1",
"kind": "ExecCredential",
"status": {
"clientCertificateData": "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----",
"clientKeyData": "-----BEGIN RSA PRIVATE KEY-----\n...\n-----END RSA PRIVATE KEY-----"
}
}
```
オプションで、レスポンスにはRFC3339のタイムスタンプとしてフォーマットされたクレデンシャルの有効期限を含めることができます。有効期限の有無には、以下のような影響あります。
- 有効期限が含まれている場合、BearerトークンとTLSクレデンシャルは有効期限に達するまで、またはサーバーがHTTPステータスコード401で応答したとき、またはプロセスが終了するまでキャッシュされます。
- 有効期限が省略された場合、BearerトークンとTLSクレデンシャルはサーバーがHTTPステータスコード401で応答したとき、またはプロセスが終了するまでキャッシュされます。
```json
{
"apiVersion": "client.authentication.k8s.io/v1beta1",
"kind": "ExecCredential",
"status": {
"token": "my-bearer-token",
"expirationTimestamp": "2018-03-05T17:30:20-08:00"
}
}
```
content/ja/docs/reference/glossary/container.md
+2 -2
View File
@@ -4,14 +4,14 @@ id: container
date: 2018-04-12
full_link: /docs/concepts/overview/what-is-kubernetes/#why-containers
short_description: >
軽量でポータブルなソフトウェアとそのすべての依存関係が含まれている実行可能なイメージ
軽量でポータブルなソフトウェアとそのすべての依存関係が含まれている実行可能なイメージです。
aka:
tags:
- fundamental
- workload
---
軽量でポータブルなソフトウェアとそのすべての依存関係が含まれている実行可能なイメージ
軽量でポータブルなソフトウェアとそのすべての依存関係が含まれている実行可能なイメージです。
<!--more-->
content/ja/docs/reference/glossary/deployment.md
+2 -2
View File
@@ -4,7 +4,7 @@ id: deployment
date: 2018-04-12
full_link: /ja/docs/concepts/workloads/controllers/deployment/
short_description: >
複製されたアプリケーションを管理するAPIオブジェクト。
複製されたアプリケーションを管理するAPIオブジェクトです。
aka:
tags:
@@ -12,7 +12,7 @@ tags:
- core-object
- workload
---
複製されたアプリケーションを管理するAPIオブジェクト。
複製されたアプリケーションを管理するAPIオブジェクトです。
<!--more-->
content/ja/docs/reference/glossary/index.md
+2 -2
View File
@@ -1,5 +1,5 @@
---
title: Standardized Glossary
title: 標準化用語集
layout: glossary
noedit: true
default_active_tag: fundamental
@@ -7,6 +7,6 @@ weight: 5
card:
name: reference
weight: 10
title: Glossary
title: 用語集
---
content/ja/docs/reference/glossary/name.md
+1 -1
View File
@@ -14,5 +14,5 @@ tags:
<!--more-->
同じ種類のオブジェクトは、同じ名前を同時に持つことは出来ません。しかし、オブジェクトを削除することで、旧オブジェクトと同じ名前で新しいオブジェクトを作成できます。
同じ種類のオブジェクトは、同じ名前を同時に持つことはできません。しかし、オブジェクトを削除することで、旧オブジェクトと同じ名前で新しいオブジェクトを作成できます。
content/ja/docs/reference/glossary/persistent-volume-claim.md
+3 -3
View File
@@ -6,13 +6,13 @@ full_link: /docs/concepts/storage/persistent-volumes/
short_description: >
コンテナ内でボリュームとしてマウントするためにPersistentVolume内で定義されたストレージリソースを要求します。
aka:
aka:
tags:
- core-object
- storage
---
{{< glossary_tooltip text="コンテナ" term_id="container" >}}内でボリュームとしてマウントするために{{< glossary_tooltip text="PersistentVolume" term_id="persistent-volume" >}}内で定義されたストレージリソースを要求します。
<!--more-->
<!--more-->
ストレージサイズ、ストレージへのアクセス制御（読み取り専用、読み取り/書き込み、排他的）、および再利用方法（保持、リサイクル、削除）を指定します。ストレージ自体の詳細はPersistentVolumeオブジェクトに記載されています。
ストレージサイズ、ストレージへのアクセス制御(読み取り専用、読み取り/書き込み、排他的)、および再利用方法（保持、リサイクル、削除）を指定します。ストレージ自体の詳細はPersistentVolumeオブジェクトに記載されています。
content/ja/docs/reference/glossary/service.md
+1 -1
View File
@@ -11,7 +11,7 @@ tags:
- fundamental
- core-object
---
{{< glossary_tooltip text="Pods" term_id="pod" >}}の集合で実行されているアプリケーションをネットワークサービスとして公開する抽象的な方法。
{{< glossary_tooltip text="Pod" term_id="pod" >}}の集合で実行されているアプリケーションをネットワークサービスとして公開する抽象的な方法です。
<!--more-->
content/ja/docs/reference/glossary/statefulset.md
+2 -2
View File
@@ -4,7 +4,7 @@ id: statefulset
date: 2018-04-12
full_link: /ja/docs/concepts/workloads/controllers/statefulset/
short_description: >
Manages the deployment and scaling of a set of Pods, *and provides guarantees about the ordering and uniqueness* of these Pods.
StatefulSetはDeploymentとPodのセットのスケーリングを管理し、それらのPodの *順序と一意性を保証* します。
aka:
tags:
@@ -14,7 +14,7 @@ tags:
- storage
---
StatefulSetはDeploymentと{{< glossary_tooltip text="Pod" term_id="pod" >}}のセットのスケーリングの管理をし、それらのPodの*順序とユニーク性を保証* します。
StatefulSetはDeploymentと{{< glossary_tooltip text="Pod" term_id="pod" >}}のセットのスケーリングを管理し、それらのPodの*順序と一意性を保証* します。
<!--more-->
content/ja/docs/reference/glossary/volume.md
+2 -2
View File
@@ -4,14 +4,14 @@ id: volume
date: 2018-04-12
full_link: /docs/concepts/storage/volumes/
short_description: >
Pod内のコンテナからアクセス可能なデータを含むディレクトリ。
Pod内のコンテナからアクセス可能なデータを含むディレクトリです。
aka:
tags:
- core-object
- fundamental
---
{{< glossary_tooltip text="Pod" term_id="pod" >}}内の{{< glossary_tooltip text="コンテナ" term_id="container" >}}からアクセス可能なデータを含むディレクトリ。
{{< glossary_tooltip text="Pod" term_id="pod" >}}内の{{< glossary_tooltip text="コンテナ" term_id="container" >}}からアクセス可能なデータを含むディレクトリです。
<!--more-->
content/ja/docs/reference/kubectl/cheatsheet.md
+1 -1
View File
@@ -323,7 +323,7 @@ kubectl cluster-info # Kubernet
kubectl cluster-info dump # 現在のクラスター状態を標準出力にダンプします
kubectl cluster-info dump --output-directory=/path/to/cluster-state # 現在のクラスター状態を/path/to/cluster-stateにダンプします
# special-userキーとNoScheduleエフェクトを持つTaintが既に存在する場合、その値は指定されたとおりに置き換えられます
# special-userキーとNoScheduleエフェクトを持つTaintがすでに存在する場合、その値は指定されたとおりに置き換えられます
kubectl taint nodes foo dedicated=special-user:NoSchedule
```
content/ja/docs/setup/best-practices/certificates.md
+2 -2
View File
@@ -72,7 +72,7 @@ CAの秘密鍵をクラスターにコピーしたくない場合、自身で全
| kube-apiserver-kubelet-client | kubernetes-ca | system:masters | client | |
| front-proxy-client | kubernetes-front-proxy-ca | | client | |
[1]: クラスターに接続するIPおよびDNS名（ [kubeadm][kubeadm]を使用する場合と同様、ロードバランサーのIPおよびDNS名、`kubernetes`、`kubernetes.default`、`kubernetes.default.svc`、`kubernetes.default.svc.cluster`、`kubernetes.default.svc.cluster.local`）
[1]: クラスターに接続するIPおよびDNS名( [kubeadm][kubeadm]を使用する場合と同様、ロードバランサーのIPおよびDNS名、`kubernetes`、`kubernetes.default`、`kubernetes.default.svc`、`kubernetes.default.svc.cluster`、`kubernetes.default.svc.cluster.local`)
`kind`は下記の[x509の鍵用途][usage]のタイプにマッピングされます:
@@ -82,7 +82,7 @@ CAの秘密鍵をクラスターにコピーしたくない場合、自身で全
| client | digital signature, key encipherment, client auth |
{{< note >}}
上記に挙げられたホスト名（SAN）は、クラスターを動作させるために推奨されるものです。
上記に挙げられたホスト名(SAN)は、クラスターを動作させるために推奨されるものです。
特別なセットアップが求められる場合、全てのサーバー証明書にSANを追加する事ができます。
{{< /note >}}
content/ja/docs/setup/learning-environment/minikube.md
+251 -183
View File
@@ -1,143 +1,257 @@
---
title: Minikubeを使用してローカル環境でKubernetesを動かす
weight: 30
content_type: concept
---
<!-- overview -->
Minikubeはローカル環境でKubernetesを簡単に実行するためのツールです。Kubernetesを試したり日々の開発への使用を検討するユーザー向けに、PC上のVM内でシングルノードのKubernetesクラスタを実行することができます。
<!-- body -->
## Minikubeの機能
* MinikubeのサポートするKubernetesの機能:
* DNS
* NodePorts
* ConfigMapsとSecrets
* ダッシュボード
* コンテナランタイム: Docker, [rkt](https://github.com/rkt/rkt), [CRI-O](https://cri-o.io/), [containerd](https://github.com/containerd/containerd)
* CNI (Container Network Interface) の有効化
* Ingress
MinikubeのサポートするKubernetesの機能:
* DNS
* NodePort
* ConfigMapとSecret
* ダッシュボード
* コンテナランタイム: Docker、[CRI-O](https://cri-o.io/)および[containerd](https://github.com/containerd/containerd)
* CNI (Container Network Interface) の有効化
* Ingress
## インストール
[Minikubeのインストール](/ja/docs/tasks/tools/install-minikube/) を参照
[Minikubeのインストール](/ja/docs/tasks/tools/install-minikube/)を参照してください。
## クイックスタート
これはMinikubeの使い方の簡単なデモです。
もしVMドライバを変更したい場合は、適切な `--vm-driver=xxx` フラグを `minikube start` に設定してください。Minikubeは以下のドライバをサポートしています。
これはMinikubeの起動、使用、削除をローカルで実施する簡単なデモです。下記の手順に従って、Minikubeを起動し試してください。
* virtualbox
1. Minikubeを起動し、クラスターを作成します:
```shell
minikube start
```
出力はこのようになります:
```
Starting local Kubernetes cluster...
Running pre-create checks...
Creating machine...
Starting local Kubernetes cluster...
```
特定のKubernetesのバージョン、VM、コンテナランタイム上でクラスターを起動するための詳細は、[クラスターの起動](#starting-a-cluster)を参照してください。
2. kubectlを使用してクラスターと対話できるようになります。詳細は[クラスターに触れてみよう](#interacting-with-your-cluster)を参照してください。
単純なHTTPサーバーである`echoserver`という既存のイメージを使用して、Kubernetes Deploymentを作りましょう。そして`--port`を使用して8080番ポートで公開しましょう。
```shell
kubectl create deployment hello-minikube --image=k8s.gcr.io/echoserver:1.10
```
出力はこのようになります:
```
deployment.apps/hello-minikube created
```
3. `hello-minikube`Deploymentに接続するために、Serviceとして公開します:
```shell
kubectl expose deployment hello-minikube --type=NodePort --port=8080
```
`--type=NodePort`オプションで、Serviceのタイプを指定します。
出力はこのようになります:
```
service/hello-minikube exposed
```
4. `hello-minikube`Podが起動開始されましたが、公開したService経由で接続する前にPodが起動完了になるまで待つ必要があります。
Podが稼働しているか確認します:
```shell
kubectl get pod
```
`STATUS`に`ContainerCreating`と表示されている場合、Podはまだ作成中です:
```
NAME READY STATUS RESTARTS AGE
hello-minikube-3383150820-vctvh 0/1 ContainerCreating 0 3s
```
`STATUS`に`Running`と表示されている場合、Podは稼働中です:
```
NAME READY STATUS RESTARTS AGE
hello-minikube-3383150820-vctvh 1/1 Running 0 13s
```
5. Serviceの詳細を確認するため、公開したServiceのURLを取得します:
```shell
minikube service hello-minikube --url
```
6. ローカル環境のクラスターについて詳細を確認するには、出力から得たURLをブラウザー上でコピーアンドペーストしてください。
出力はこのようになります:
```
Hostname: hello-minikube-7c77b68cff-8wdzq
Pod Information:
-no pod information available-
Server values:
server_version=nginx: 1.13.3 - lua: 10008
Request Information:
client_address=172.17.0.1
method=GET
real path=/
query=
request_version=1.1
request_scheme=http
request_uri=http://192.168.99.100:8080/
Request Headers:
accept=*/*
host=192.168.99.100:30674
user-agent=curl/7.47.0
Request Body:
-no body in request-
```
Serviceやクラスターをこれ以上稼働させない場合、削除する事ができます。
7. `hello-minikube`Serviceを削除します:
```shell
kubectl delete services hello-minikube
```
出力はこのようになります:
```
service "hello-minikube" deleted
```
8. `hello-minikube`Deploymentを削除します:
```shell
kubectl delete deployment hello-minikube
```
出力はこのようになります:
```
deployment.extensions "hello-minikube" deleted
```
9. ローカル環境のMinikubeクラスターを停止します:
```shell
minikube stop
```
出力はこのようになります:
```
Stopping local Kubernetes cluster...
Stopping "minikube"...
```
詳細は[クラスターの停止](#stopping-a-cluster)を参照ください。
10. ローカルのMinikubeクラスターを削除します:
```shell
minikube delete
```
出力はこのようになります:
```
Deleting "minikube" ...
The "minikube" cluster has been deleted.
```
詳細は[クラスターの削除](#deleting-a-cluster)を参照ください。
## クラスターの管理
### クラスターの起動 {#starting-a-cluster}
`minikube start`コマンドを使用してクラスターを起動することができます。
このコマンドはシングルノードのKubernetesクラスターを実行する仮想マシンを作成・設定します。
また、このクラスターと通信する[kubectl](/ja/docs/reference/kubectl/overview/)のインストールも設定します。
{{< note >}}
もしWebプロキシーを通している場合、そのプロキシー情報を`minikube start`コマンドに渡す必要があります:
```shell
https_proxy=<my proxy> minikube start --docker-env http_proxy=<my proxy> --docker-env https_proxy=<my proxy> --docker-env no_proxy=192.168.99.0/24
```
残念なことに、ただ環境変数を設定するだけではうまく動作しません。
Minikubeは"minikube"コンテキストも作成し、そのコンテキストをデフォルト設定としてkubectlに設定します。
あとでコンテキストを切り戻すには、このコマンドを実行してください: `kubectl config use-context minikube`
{{< /note >}}
#### Kubernetesバージョンの指定
`minikube start`コマンドに`--kubernetes-version`文字列を追加することで、
MinikubeにKubernetesの特定のバージョンを指定することができます。
例えば、{{< param "fullversion" >}}のバージョンを実行するには以下を実行します:
```
minikube start --kubernetes-version {{< param "fullversion" >}}
```
#### VMドライバーの指定
もしVMドライバーを変更したい場合は、`--vm-driver=<enter_driver_name>`フラグを`minikube start`に設定してください。例えば、コマンドは以下のようになります。
```shell
minikube start --vm-driver=<driver_name>
```
Minikubeは以下のドライバーをサポートしています:
{{< note >}}
サポートされているドライバーとプラグインのインストールの詳細については[DRIVERS](https://git.k8s.io/minikube/docs/drivers.md)を参照してください。
{{< /note >}}
* virtualbox
* vmwarefusion
* kvm2 ([driver installation](https://git.k8s.io/minikube/docs/drivers.md#kvm2-driver))
* kvm ([driver installation](https://git.k8s.io/minikube/docs/drivers.md#kvm-driver))
* hyperkit ([driver installation](https://git.k8s.io/minikube/docs/drivers.md#hyperkit-driver))
* xhyve ([driver installation](https://git.k8s.io/minikube/docs/drivers.md#xhyve-driver)) (非推奨)
* kvm2 ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/#kvm2-driver))
* hyperkit ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/#hyperkit-driver))
* hyperv ([driver installation](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver))
注意: 以下のIPは動的であり、変更される可能性があります。IPは `minikube ip` で取得することができます。
* none (VMではなくホスト上でKubernetesコンポーネントを起動する。このドライバを使用するにはDocker ([docker install](https://docs.docker.com/install/linux/docker-ce/ubuntu/)) とLinux環境を必要とします)
注意: 以下のIPは動的であり、変更される可能性があります。IPは`minikube ip`で取得することができます。
* vmware ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/vmware/)) (VMware unified driver)
* none (VMではなくホスト上でKubernetesコンポーネントを起動。このドライバーを使用するには{{< glossary_tooltip term_id="docker" >}}とLinux環境を必要とします)
```shell
minikube start
```
```
Starting local Kubernetes cluster...
Running pre-create checks...
Creating machine...
Starting local Kubernetes cluster...
```
```shell
kubectl create deployment hello-minikube --image=k8s.gcr.io/echoserver:1.10
```
```
deployment.apps/hello-minikube created
```
```shell
kubectl expose deployment hello-minikube --type=NodePort --port=8080
```
```
service/hello-minikube exposed
```
```
# We have now launched an echoserver pod but we have to wait until the pod is up before curling/accessing it
# via the exposed service.
# To check whether the pod is up and running we can use the following:
kubectl get pod
```
```
NAME READY STATUS RESTARTS AGE
hello-minikube-3383150820-vctvh 0/1 ContainerCreating 0 3s
```
```shell
# We can see that the pod is still being created from the ContainerCreating status
kubectl get pod
```
```
NAME READY STATUS RESTARTS AGE
hello-minikube-3383150820-vctvh 1/1 Running 0 13s
```
```shell
# We can see that the pod is now Running and we will now be able to curl it:
curl $(minikube service hello-minikube --url)
```
```
Hostname: hello-minikube-7c77b68cff-8wdzq
Pod Information:
-no pod information available-
Server values:
server_version=nginx: 1.13.3 - lua: 10008
Request Information:
client_address=172.17.0.1
method=GET
real path=/
query=
request_version=1.1
request_scheme=http
request_uri=http://192.168.99.100:8080/
Request Headers:
accept=*/*
host=192.168.99.100:30674
user-agent=curl/7.47.0
Request Body:
-no body in request-
```
```shell
kubectl delete services hello-minikube
```
```
service "hello-minikube" deleted
```
```shell
kubectl delete deployment hello-minikube
```
```
deployment.extensions "hello-minikube" deleted
```
```shell
minikube stop
```
```
Stopping local Kubernetes cluster...
Stopping "minikube"...
```
{{< caution >}}
`none`ドライバーを使用する場合、一部のKubernetesのコンポーネントは特権付きのコンテナとして稼働するため、Minikube環境外に副作用をもたらします。
この副作用から、`none`ドライバーは、個人の作業環境では推奨されません。
{{< /caution >}}
### コンテナランタイムの代替
下記のコンテナランタイム上でMinikubeを起動できます。
#### containerd
{{< tabs name="container_runtimes" >}}
{{% tab name="containerd" %}}
[containerd](https://github.com/containerd/containerd) をコンテナランタイムとして使用するには以下を実行してください:
@@ -160,10 +274,9 @@ minikube start \
--extra-config=kubelet.image-service-endpoint=unix:///run/containerd/containerd.sock \
--bootstrapper=kubeadm
```
#### CRI-O
[CRI-O](https://github.com/kubernetes-incubator/cri-o) をコンテナランタイムとして使用するには以下を実行してください:
{{% /tab %}}
{{% tab name="CRI-O" %}}
[CRI-O](https://cri-o.io/)をコンテナランタイムとして使用するには以下を実行してください:
```bash
minikube start \
@@ -184,47 +297,33 @@ minikube start \
--extra-config=kubelet.image-service-endpoint=/var/run/crio.sock \
--bootstrapper=kubeadm
```
#### rktコンテナエンジン
[rkt](https://github.com/rkt/rkt) をコンテナランタイムとして使用するには以下を実行してください:
```shell
minikube start \
--network-plugin=cni \
--enable-default-cni \
--container-runtime=rkt
```
これはrktとDockerの両方を含んだ代替のMinikubeのISOイメージを使用し、CNIネットワークを有効にします。
### ドライバープラグイン
サポートされているドライバとプラグインのインストールの詳細については [DRIVERS](https://git.k8s.io/minikube/docs/drivers.md) を参照してください。
{{% /tab %}}
{{< /tabs >}}
### Dockerデーモンの再利用によるローカルイメージの使用
Kubernetesの単一のVMを使用する場合、Minikube組み込みのDockerデーモンの再利用がおすすめです。ホストマシン上にDockerレジストリを構築してイメージをプッシュする必要がなく、ローカルでの実験を加速させるMinikubeと同じDockerデーモンの中に構築することができます。ただDockerイメージに'latest'以外のタグを付け、そのタグを使用してイメージをプルしてください。イメージのバージョンを指定しなければ、`Always` のプルイメージポリシーにより `:latest` と仮定され、もしデフォルトのDockerレジストリ(通常はDockerHub)にどのバージョンのDockerイメージもまだ存在しない場合には、`ErrImagePull` になる恐れがあります。
Kubernetesの単一のVMを使用する場合、Minikube組み込みのDockerデーモンの再利用がおすすめです。ホストマシン上にDockerレジストリを構築してイメージをプッシュする必要がなく、ローカルでの実験を加速させるMinikubeと同じDockerデーモンの中に構築することができます。
Mac/LinuxのホストでDockerデーモンを操作できるようにするには、shell内で `docker-env command` を使います:
{{< note >}}
Dockerイメージに'latest'以外のタグを付け、そのタグを使用してイメージをプルしてください。イメージのバージョンを指定しなければ`Always`のプルイメージポリシーにより`:latest`と仮定され、もしデフォルトのDockerレジストリ(通常はDockerHub)にどのバージョンのDockerイメージもまだ存在しない場合には、`ErrImagePull`になる恐れがあります。
{{< /note >}}
```shell
eval $(minikube docker-env)
```
Mac/LinuxのホストでDockerデーモンを操作できるようにするには、`minikube docker-env`を実行します。
これにより、MinikubeのVM内のDockerデーモンと通信しているホストのMac/LinuxマシンのコマンドラインでDockerを使用できるようになっているはずです。
これにより、MinikubeのVM内のDockerデーモンと通信しているホストのMac/LinuxマシンのコマンドラインでDockerを使用できるようになります:
```shell
docker ps
```
{{< note >}}
CentOS 7では、Dockerが以下のエラーを出力することがあります:
```shell
```
Could not read CA certificate "/etc/docker/ca.pem": open /etc/docker/ca.pem: no such file or directory
```
修正方法としては、/etc/sysconfig/docker を更新してMinikube環境の変更が確実に反映されるようにすることです:
修正方法としては、/etc/sysconfig/dockerを更新してMinikube環境の変更が確実に反映されるようにすることです:
```shell
< DOCKER_CERT_PATH=/etc/docker
@@ -233,37 +332,7 @@ Could not read CA certificate "/etc/docker/ca.pem": open /etc/docker/ca.pem: no
> DOCKER_CERT_PATH=/etc/docker
> fi
```
imagePullPolicy:Alwaysをオフにすることを忘れないでください: さもなければKubernetesはローカルに構築したイメージを使用しません。
## クラスターの管理
### クラスターの起動
`minikube start` コマンドはクラスターを起動することができます。
このコマンドはシングルノードのKubernetesクラスターを実行する仮想マシンを作成・設定します。
また、このクラスターと通信する [kubectl](/docs/user-guide/kubectl-overview/) のインストールも設定します。
もしWebプロキシーを通している場合、そのプロキシー情報を `minikube start` コマンドに渡す必要があります:
```shell
https_proxy=<my proxy> minikube start --docker-env http_proxy=<my proxy> --docker-env https_proxy=<my proxy> --docker-env no_proxy=192.168.99.0/24
```
残念なことに、ただ環境変数を設定するだけではうまく動作しません。
Minikubeは "minikube" コンテキストも作成し、そのコンテキストをデフォルト設定としてkubectlに設定します。
あとでコンテキストを切り戻すには、このコマンドを実行してください: `kubectl config use-context minikube`
#### Kubernetesバージョンの指定
`minikube start` コマンドに `--kubernetes-version` 文字列を追加することで、
MinikubeにKubernetesの特定のバージョンを指定することができます。
例えば、`v1.7.3` のバージョンを実行するには以下を実行します:
```
minikube start --kubernetes-version v1.7.3
```
{{< /note >}}
### Kubernetesの設定
@@ -293,16 +362,19 @@ Kubeletの `MaxPods` 設定を5に変更するには、このフラグを渡し
`apiserver` の `AuthorizationMode` を `RABC` に設定するには、このフラグを使います: `--extra-config=apiserver.authorization-mode=RBAC`.
### クラスターの停止
### クラスターの停止 {#stopping-a-cluster}
`minikube stop` コマンドを使ってクラスターを停止することができます。
このコマンドはMinikube仮想マシンをシャットダウンしますが、すべてのクラスターの状態とデータを保存します。
クラスターを再起動すると、以前の状態に復元されます。
### クラスターの削除
### クラスターの削除 {#deleting-a-cluster}
`minikube delete` コマンドを使ってクラスターを削除することができます。
このコマンドはMinikube仮想マシンをシャットダウンして削除します。データや状態は保存されません。
## クラスターに触れてみよう
### minikubeのアップグレード {#upgrading-minikube}
[minikubeのアップグレード](https://minikube.sigs.k8s.io/docs/start/macos/)を参照してください。
## クラスターに触れてみよう {#interacting-with-your-cluster}
### Kubectl
@@ -379,7 +451,7 @@ spec:
| VirtualBox | Linux | /home | /hosthome |
| VirtualBox | macOS | /Users | /Users |
| VirtualBox | Windows | C://Users | /c/Users |
| VMware Fusion | macOS | /Users | /Users |
| VMware Fusion | macOS | /Users | /mnt/hgfs/Users |
| Xhyve | macOS | /Users | /Users |
## プライベートコンテナレジストリ
@@ -417,10 +489,8 @@ export no_proxy=$no_proxy,$(minikube ip)
```
## 既知の問題
* クラウドプロバイダーを必要とする機能はMinikubeでは動作しません
* ロードバランサー
* 複数ノードを必要とする機能
* 高度なスケジューリングポリシー
複数ノードを必要とする機能はMinikubeでは動作しません。
## 設計
@@ -440,5 +510,3 @@ Minikubeの詳細については、[proposal](https://git.k8s.io/community/contr
## コミュニティ
コントリビューションや質問、コメントは歓迎・奨励されています! Minikubeの開発者は[Slack](https://kubernetes.slack.com)の#minikubeチャンネルにいます(Slackへの招待状は[こちら](http://slack.kubernetes.io/))。[kubernetes-dev Google Groupsメーリングリスト](https://groups.google.com/forum/#!forum/kubernetes-dev)もあります。メーリングリストに投稿する際は件名の最初に "minikube: " をつけてください。
content/ja/docs/setup/production-environment/container-runtimes.md
+1 -1
View File
@@ -25,7 +25,7 @@ Podのコンテナを実行するために、Kubernetesはコンテナランタ
### 適用性
{{< note >}}
このドキュメントはLinuxにCRIをインストールするユーザーの為に書かれています。
このドキュメントはLinuxにCRIをインストールするユーザーのために書かれています。
他のオペレーティングシステムの場合、プラットフォーム固有のドキュメントを見つけてください。
{{< /note >}}
content/ja/docs/setup/production-environment/on-premises-vm/dcos.md
+1 -1
View File
@@ -5,7 +5,7 @@ content_type: concept
<!-- overview -->
Mesosphereは[DC/OS](https://mesosphere.com/product/)上にKubernetesを構築する為の簡単な選択肢を提供します。それは
Mesosphereは[DC/OS](https://mesosphere.com/product/)上にKubernetesを構築するための簡単な選択肢を提供します。それは
* 純粋なアップストリームのKubernetes
* シングルクリッククラスター構築
content/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
+6 -6
View File
@@ -16,6 +16,7 @@ card:
* 次のいずれかが動作しているマシンが必要です
- Ubuntu 16.04+
- Debian 9+
@@ -69,7 +70,7 @@ Linuxでは、カーネルのiptablesサブシステムの最新の代替品と
もしあなたのシステムの`iptables`ツールがnftablesバックエンドを使用している場合、これらの問題を避けるために`iptables`ツールをレガシーモードに切り替える必要があります。これは、少なくともDebian 10(Buster)、Ubuntu 19.04、Fedora 29、およびこれらのディストリビューションの新しいリリースでのデフォルトです。RHEL 8はレガシーモードへの切り替えをサポートしていないため、現在のkubeadmパッケージと互換性がありません。
{{< tabs name="iptables_legacy" >}}
{{% tab name="Debian or Ubuntu" %}}
{{% tab name="DebianまたはUbuntu" %}}
```bash
# レガシーバイナリがインストールされていることを確認してください
sudo apt-get install -y iptables arptables ebtables
@@ -113,7 +114,7 @@ update-alternatives --set iptables /usr/sbin/iptables-legacy
etcdポートはコントロールプレーンノードに含まれていますが、独自のetcdクラスターを外部またはカスタムポートでホストすることもできます。
使用するPodネットワークプラグイン（以下を参照）のポートも開く必要があります。これは各Podネットワークプラグインによって異なるため、必要なポートについてはプラグインのドキュメントを参照してください。
使用するPodネットワークプラグイン(以下を参照)のポートも開く必要があります。これは各Podネットワークプラグインによって異なるため、必要なポートについてはプラグインのドキュメントを参照してください。
## ランタイムのインストール {#installing-runtime}
@@ -176,7 +177,7 @@ kubeadmは`kubelet`や`kubectl`をインストールまたは管理**しない**
* Kubeadm-specific [バージョン互換ポリシー](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#version-skew-policy)
{{< tabs name="k8s_install" >}}
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
{{% tab name="Ubuntu、Debian、またはHypriotOS" %}}
```bash
sudo apt-get update && sudo apt-get install -y apt-transport-https curl
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
@@ -188,7 +189,7 @@ sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl
```
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
{{% tab name="CentOS、RHEL、またはFedora" %}}
```bash
cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
@@ -270,7 +271,7 @@ KUBELET_EXTRA_ARGS=--cgroup-driver=<value>
このファイルは、kubeletの追加のユーザー定義引数を取得するために、`kubeadm init`および`kubeadm join`によって使用されます。
CRIのcgroupドライバーが`cgroupfs`でない場合に**のみ**それを行う必要があることに注意してください。なぜなら、これは既にkubeletのデフォルト値であるためです。
CRIのcgroupドライバーが`cgroupfs`でない場合に**のみ**それを行う必要があることに注意してください。なぜなら、これはすでにkubeletのデフォルト値であるためです。
kubeletをリスタートする方法:
@@ -290,4 +291,3 @@ kubeadmで問題が発生した場合は、[トラブルシューティング](/
* [kubeadmを使用したシングルコントロールプレーンクラスターの作成](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)
content/ja/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md
+48 -109
View File
@@ -8,21 +8,11 @@ weight: 80
{{< feature-state for_k8s_version="1.11" state="stable" >}}
The lifecycle of the kubeadm CLI tool is decoupled from the
[kubelet](/docs/reference/command-line-tools-reference/kubelet), which is a daemon that runs
on each node within the Kubernetes cluster. The kubeadm CLI tool is executed by the user when Kubernetes is
initialized or upgraded, whereas the kubelet is always running in the background.
kubeadm CLIツールのライフサイクルは、Kubernetesクラスター内の各ノード上で稼働するデーモンである[kubelet](/docs/reference/command-line-tools-reference/kubelet)から分離しています。kubeadm CLIツールはKubernetesを初期化またはアップグレードする際にユーザーによって実行されます。一方で、kubeletは常にバックグラウンドで稼働しています。
Since the kubelet is a daemon, it needs to be maintained by some kind of a init
system or service manager. When the kubelet is installed using DEBs or RPMs,
systemd is configured to manage the kubelet. You can use a different service
manager instead, but you need to configure it manually.
kubeletはデーモンのため、何らかのinitシステムやサービスマネージャーで管理する必要があります。DEBパッケージやRPMパッケージからkubeletをインストールすると、systemdはkubeletを管理するように設定されます。代わりに別のサービスマネージャーを使用することもできますが、手動で設定する必要があります。
Some kubelet configuration details need to be the same across all kubelets involved in the cluster, while
other configuration aspects need to be set on a per-kubelet basis, to accommodate the different
characteristics of a given machine, such as OS, storage, and networking. You can manage the configuration
of your kubelets manually, but [kubeadm now provides a `KubeletConfiguration` API type for managing your
kubelet configurations centrally](#configure-kubelets-using-kubeadm).
いくつかのkubeletの設定は、クラスターに含まれる全てのkubeletで同一である必要があります。一方で、特定のマシンの異なる特性(OS、ストレージ、ネットワークなど)に対応するために、kubeletごとに設定が必要なものもあります。手動で設定を管理することも可能ですが、kubeadmは[一元的な設定管理](#configure-kubelets-using-kubeadm)のための`KubeletConfiguration`APIを提供しています。
@@ -30,29 +20,19 @@ kubelet configurations centrally](#configure-kubelets-using-kubeadm).
## Kubeletの設定パターン
The following sections describe patterns to kubelet configuration that are simplified by
using kubeadm, rather than managing the kubelet configuration for each Node manually.
以下のセクションでは、kubeadmを使用したkubeletの設定パターンについて説明します。これは手動で各Nodeの設定を管理するよりも簡易に行うことができます。
### 各kubeletにクラスターレベルの設定を配布
### 各kubeletにクラスターレベルの設定を配布 {#propagating-cluster-level-configuration-to-each-kubelet}
You can provide the kubelet with default values to be used by `kubeadm init` and `kubeadm join`
commands. Interesting examples include using a different CRI runtime or setting the default subnet
used by services.
`kubeadm init`および`kubeadm join`コマンドを使用すると、kubeletにデフォルト値を設定することができます。興味深い例として、異なるCRIランタイムを使用したり、Serviceが使用するデフォルトのサブネットを設定したりすることができます。
If you want your services to use the subnet `10.96.0.0/12` as the default for services, you can pass
the `--service-cidr` parameter to kubeadm:
Serviceが使用するデフォルトのサブネットとして`10.96.0.0/12`を設定する必要がある場合は、`--service-cidr`パラメーターを渡します。
```bash
kubeadm init --service-cidr 10.96.0.0/12
```
Virtual IPs for services are now allocated from this subnet. You also need to set the DNS address used
by the kubelet, using the `--cluster-dns` flag. This setting needs to be the same for every kubelet
on every manager and Node in the cluster. The kubelet provides a versioned, structured API object
that can configure most parameters in the kubelet and push out this configuration to each running
kubelet in the cluster. This object is called **the kubelet's ComponentConfig**.
The ComponentConfig allows the user to specify flags such as the cluster DNS IP addresses expressed as
a list of values to a camelCased key, illustrated by the following example:
これによってServiceの仮想IPはこのサブネットから割り当てられるようになりました。また、`--cluster-dns`フラグを使用し、kubeletが用いるDNSアドレスを設定する必要もあります。この設定はクラスター内の全てのマネージャーとNode上で同一である必要があります。kubeletは、**kubeletのComponentConfig**と呼ばれる、バージョン管理と構造化されたAPIオブジェクトを提供します。これはkubelet内のほとんどのパラメーターを設定し、その設定をクラスター内で稼働中の各kubeletへ適用することを可能にします。以下の例のように、キャメルケースのキーに値のリストとしてクラスターDNS IPアドレスなどのフラグを指定することができます。
```yaml
apiVersion: kubelet.config.k8s.io/v1beta1
@@ -61,140 +41,99 @@ clusterDNS:
- 10.96.0.10
```
For more details on the ComponentConfig have a look at [this section](#configure-kubelets-using-kubeadm).
ComponentConfigの詳細については、[このセクション](#configure-kubelets-using-kubeadm)をご覧ください
### インスタンス固有の設定内容を適用
### インスタンス固有の設定内容を適用 {#providing-instance-specific-configuration-details}
Some hosts require specific kubelet configurations, due to differences in hardware, operating system,
networking, or other host-specific parameters. The following list provides a few examples.
いくつかのホストでは、ハードウェア、オペレーティングシステム、ネットワーク、その他ホスト固有のパラメータの違いのため、特定のkubeletの設定を必要とします。以下にいくつかの例を示します。
- The path to the DNS resolution file, as specified by the `--resolv-conf` kubelet
configuration flag, may differ among operating systems, or depending on whether you are using
`systemd-resolved`. If this path is wrong, DNS resolution will fail on the Node whose kubelet
is configured incorrectly.
- DNS解決ファイルへのパスは`--resolv-conf`フラグで指定することができますが、オペレーティングシステムや`systemd-resolved`を使用するかどうかによって異なる場合があります。このパスに誤りがある場合、そのNode上でのDNS解決は失敗します。
- クラウドプロバイダーを使用していない場合、Node APIオブジェクト`.metadata.name`はデフォルトでマシンのホスト名に設定されます。異なるNode名を指定する必要がある場合には、`--hostname-override`フラグによってこの挙動を書き換えることができます。
- 現在のところ、kubletはCRIランタイムが使用するcgroupドライバを自動で検知することができませんが、kubeletの稼働を保証するためには、`--cgroup-driver`の値はCRIランタイムが使用するcgroupドライバに一致していなければなりません。
- クラスターが使用するCRIランタイムによっては、異なるフラグを指定する必要があるかもしれません。例えば、Dockerを使用している場合には、`--network-plugin=cni`のようなフラグを指定する必要があります。外部のランタイムを使用している場合には、`--container-runtime=remote`と指定し、`--container-runtime-endpoint=<path>`のようにCRIエンドポイントを指定する必要があります。
- The Node API object `.metadata.name` is set to the machine's hostname by default,
unless you are using a cloud provider. You can use the `--hostname-override` flag to override the
default behavior if you need to specify a Node name different from the machine's hostname.
これらのフラグは、systemdなどのサービスマネージャー内のkubeletの設定によって指定することができます。
- Currently, the kubelet cannot automatically detects the cgroup driver used by the CRI runtime,
but the value of `--cgroup-driver` must match the cgroup driver used by the CRI runtime to ensure
the health of the kubelet.
## kubeadmを使用したkubeletの設定 {#configure-kubelets-using-kubeadm}
- Depending on the CRI runtime your cluster uses, you may need to specify different flags to the kubelet.
For instance, when using Docker, you need to specify flags such as `--network-plugin=cni`, but if you
are using an external runtime, you need to specify `--container-runtime=remote` and specify the CRI
endpoint using the `--container-runtime-path-endpoint=<path>`.
`kubeadm ... --config some-config-file.yaml`のように、カスタムの`KubeletConfiguration`APIオブジェクトを設定ファイルを介して渡すことで、kubeadmによって起動されるkubeletに設定を反映することができます。
You can specify these flags by configuring an individual kubelet's configuration in your service manager,
such as systemd.
`kubeadm config print init-defaults --component-configs KubeletConfiguration`を実行することによって、この構造体の全てのデフォルト値を確認することができます。
## kubeadmを使用したkubeletの設定
It is possible to configure the kubelet that kubeadm will start if a custom `KubeletConfiguration`
API object is passed with a configuration file like so `kubeadm ... --config some-config-file.yaml`.
By calling `kubeadm config print init-defaults --component-configs KubeletConfiguration` you can
see all the default values for this structure.
Also have a look at the [API reference for the
kubelet ComponentConfig](https://godoc.org/k8s.io/kubernetes/pkg/kubelet/apis/config#KubeletConfiguration)
for more information on the individual fields.
また、各フィールドの詳細については、[kubelet ComponentConfigに関するAPIリファレンス](https://godoc.org/k8s.io/kubernetes/pkg/kubelet/apis/config#KubeletConfiguration)を参照してください。
### `kubeadm init`実行時の流れ
When you call `kubeadm init`, the kubelet configuration is marshalled to disk
at `/var/lib/kubelet/config.yaml`, and also uploaded to a ConfigMap in the cluster. The ConfigMap
is named `kubelet-config-1.X`, where `.X` is the minor version of the Kubernetes version you are
initializing. A kubelet configuration file is also written to `/etc/kubernetes/kubelet.conf` with the
baseline cluster-wide configuration for all kubelets in the cluster. This configuration file
points to the client certificates that allow the kubelet to communicate with the API server. This
addresses the need to
[propagate cluster-level configuration to each kubelet](#propagating-cluster-level-configuration-to-each-kubelet).
`kubeadm init`を実行した場合、kubeletの設定は`/var/lib/kubelet/config.yaml`に格納され、クラスターのConfigMapにもアップロードされます。ConfigMapは`kubelet-config-1.X`という名前で、`.X`は初期化するKubernetesのマイナーバージョンを表します。またこの設定ファイルは、クラスタ内の全てのkubeletのために、クラスター全体設定の基準と共に`/etc/kubernetes/kubelet.conf`にも書き込まれます。この設定ファイルは、kubeletがAPIサーバと通信するためのクライアント証明書を指し示します。これは、[各kubeletにクラスターレベルの設定を配布](#propagating-cluster-level-configuration-to-each-kubelet)することの必要性を示しています。
To address the second pattern of
[providing instance-specific configuration details](#providing-instance-specific-configuration-details),
kubeadm writes an environment file to `/var/lib/kubelet/kubeadm-flags.env`, which contains a list of
flags to pass to the kubelet when it starts. The flags are presented in the file like this:
二つ目のパターンである、[インスタンス固有の設定内容を適用](#providing-instance-specific-configuration-details)するために、kubeadmは環境ファイルを`/var/lib/kubelet/kubeadm-flags.env`へ書き出します。このファイルは以下のように、kubelet起動時に渡されるフラグのリストを含んでいます。
```bash
KUBELET_KUBEADM_ARGS="--flag1=value1 --flag2=value2 ..."
```
In addition to the flags used when starting the kubelet, the file also contains dynamic
parameters such as the cgroup driver and whether to use a different CRI runtime socket
(`--cri-socket`).
kubelet起動時に渡されるフラグに加えて、このファイルはcgroupドライバーや異なるCRIランタイムソケットを使用するかどうか(`--cri-socket`)といった動的なパラメータも含みます。
After marshalling these two files to disk, kubeadm attempts to run the following two
commands, if you are using systemd:
これら二つのファイルがディスク上に格納されると、systemdを使用している場合、kubeadmは以下の二つのコマンドを実行します。
```bash
systemctl daemon-reload && systemctl restart kubelet
```
If the reload and restart are successful, the normal `kubeadm init` workflow continues.
リロードと再起動に成功すると、通常の`kubeadm init`のワークフローが続きます。
### `kubeadm join`実行時の流れ
When you run `kubeadm join`, kubeadm uses the Bootstrap Token credential to perform
a TLS bootstrap, which fetches the credential needed to download the
`kubelet-config-1.X` ConfigMap and writes it to `/var/lib/kubelet/config.yaml`. The dynamic
environment file is generated in exactly the same way as `kubeadm init`.
`kubeadm join`を実行した場合、kubeadmはBootstrap Token証明書を使用してTLS bootstrapを行い、ConfigMap`kubelet-config-1.X`をダウンロードするために必要なクレデンシャルを取得し、`/var/lib/kubelet/config.yaml`へ書き込みます。動的な環境ファイルは、`kubeadm init`の場合と全く同様の方法で生成されます。
Next, `kubeadm` runs the following two commands to load the new configuration into the kubelet:
次に、`kubeadm`は、kubeletに新たな設定を読み込むために、以下の二つのコマンドを実行します。
```bash
systemctl daemon-reload && systemctl restart kubelet
```
After the kubelet loads the new configuration, kubeadm writes the
`/etc/kubernetes/bootstrap-kubelet.conf` KubeConfig file, which contains a CA certificate and Bootstrap
Token. These are used by the kubelet to perform the TLS Bootstrap and obtain a unique
credential, which is stored in `/etc/kubernetes/kubelet.conf`. When this file is written, the kubelet
has finished performing the TLS Bootstrap.
kubeletが新たな設定を読み込むと、kubeadmは、KubeConfigファイル`/etc/kubernetes/bootstrap-kubelet.conf`を書き込みます。これは、CA証明書とBootstrap Tokenを含みます。これらはkubeletがTLS Bootstrapを行い`/etc/kubernetes/kubelet.conf`に格納されるユニークなクレデンシャルを取得するために使用されます。ファイルが書き込まれると、kubeletはTLS Bootstrapを終了します。
## kubelet用のsystemdファイル
## kubelet用のsystemdファイル {#the-kubelet-drop-in-file-for-systemd}
The configuration file installed by the kubeadm DEB or RPM package is written to
`/etc/systemd/system/kubelet.service.d/10-kubeadm.conf` and is used by systemd.
`kubeadm`には、systemdがどのようにkubeletを実行するかを指定した設定ファイルが同梱されています。
kubeadm CLIコマンドは決してこのsystemdファイルには触れないことに注意してください。
kubeadmの[DEBパッケージ](https://github.com/kubernetes/kubernetes/blob/master/build/debs/10-kubeadm.conf)または[RPMパッケージ](https://github.com/kubernetes/kubernetes/blob/master/build/rpms/10-kubeadm.conf)によってインストールされたこの設定ファイルは、`/etc/systemd/system/kubelet.service.d/10-kubeadm.conf`に書き込まれ、systemdで使用されます。基本的な`kubelet.service`([RPM用](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/rpm/kubelet/kubelet.service)または、 [DEB用](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service))を拡張します。
```none
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf
--kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
# This is a file that "kubeadm init" and "kubeadm join" generates at runtime, populating
# This is a file that "kubeadm init" and "kubeadm join" generate at runtime, populating
the KUBELET_KUBEADM_ARGS variable dynamically
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably,
#the user should use the .NodeRegistration.KubeletExtraArgs object in the configuration files instead.
# the user should use the .NodeRegistration.KubeletExtraArgs object in the configuration files instead.
# KUBELET_EXTRA_ARGS should be sourced from this file.
EnvironmentFile=-/etc/default/kubelet
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS
```
This file specifies the default locations for all of the files managed by kubeadm for the kubelet.
このファイルは、kubeadmがkubelet用に管理する全ファイルが置かれるデフォルトの場所を指定します。
- The KubeConfig file to use for the TLS Bootstrap is `/etc/kubernetes/bootstrap-kubelet.conf`,
but it is only used if `/etc/kubernetes/kubelet.conf` does not exist.
- The KubeConfig file with the unique kubelet identity is `/etc/kubernetes/kubelet.conf`.
- The file containing the kubelet's ComponentConfig is `/var/lib/kubelet/config.yaml`.
- The dynamic environment file that contains `KUBELET_KUBEADM_ARGS` is sourced from `/var/lib/kubelet/kubeadm-flags.env`.
- The file that can contain user-specified flag overrides with `KUBELET_EXTRA_ARGS` is sourced from
`/etc/default/kubelet` (for DEBs), or `/etc/sysconfig/kubelet` (for RPMs). `KUBELET_EXTRA_ARGS`
is last in the flag chain and has the highest priority in the event of conflicting settings.
- TLS Bootstrapに使用するKubeConfigファイルは`/etc/kubernetes/bootstrap-kubelet.conf`ですが、`/etc/kubernetes/kubelet.conf`が存在しない場合にのみ使用します。
- ユニークなkublet識別子を含むKubeConfigファイルは`/etc/kubernetes/kubelet.conf`です。
- kubeletのComponentConfigを含むファイルは`/var/lib/kubelet/config.yaml`です。
- `KUBELET_KUBEADM_ARGS`を含む動的な環境ファイルは`/var/lib/kubelet/kubeadm-flags.env`から取得します。
- `KUBELET_EXTRA_ARGS`によるユーザー定義のフラグの上書きを格納できるファイルは`/etc/default/kubelet`(DEBの場合)、または`/etc/sysconfig/kubelet`(RPMの場合)から取得します。`KUBELET_EXTRA_ARGS`はフラグの連なりの最後に位置し、優先度が最も高いです。
## Kubernetesバイナリとパッケージの内容
The DEB and RPM packages shipped with the Kubernetes releases are:
Kubernetesに同梱されるDEB、RPMのパッケージは以下の通りです。
| Package name | Description |
| パッケージ名 | 説明 |
|--------------|-------------|
| `kubeadm` | Installs the `/usr/bin/kubeadm` CLI tool and the [kubelet drop-in file](#the-kubelet-drop-in-file-for-systemd) for the kubelet. |
| `kubelet` | Installs the `/usr/bin/kubelet` binary. |
| `kubectl` | Installs the `/usr/bin/kubectl` binary. |
| `kubernetes-cni` | Installs the official CNI binaries into the `/opt/cni/bin` directory. |
| `cri-tools` | Installs the `/usr/bin/crictl` binary from the [cri-tools git repository](https://github.com/kubernetes-incubator/cri-tools). |
| `kubeadm` | `/usr/bin/kubeadm`CLIツールと、[kubelet用のsystemdファイル](#the-kubelet-drop-in-file-for-systemd)をインストールします。 |
| `kubelet` | kubeletバイナリを`/usr/bin`に、CNIバイナリを`/opt/cni/bin`にインストールします。 |
| `kubectl` | `/usr/bin/kubectl`バイナリをインストールします。 |
| `kubernetes-cni` | 公式のCNIバイナリを`/opt/cni/bin`ディレクトリにインストールします。 |
| `cri-tools` | `/usr/bin/crictl`バイナリを[cri-tools gitリポジトリ](https://github.com/kubernetes-incubator/cri-tools)からインストールします。 |
content/ja/docs/setup/production-environment/turnkey/alibaba-cloud.md
+1 -1
View File
@@ -6,7 +6,7 @@ title: Alibaba CloudでKubernetesを動かす
[Alibaba Cloud Container Service](https://www.alibabacloud.com/product/container-service)はAlibaba Cloud ECSインスタンスのクラスター上もしくはサーバーレスの形態でDockerアプリケーションを起動して管理します。著名なオープンソースのコンテナオーケストレーターであるDocker SwarmおよびKubernetesをサポートしています。
クラスターの構築と管理を簡素化する為に、[Alibaba Cloud Container Serviceの為のKubernetesサポート](https://www.alibabacloud.com/product/kubernetes)を使用します。[Kubernetes walk-through](https://www.alibabacloud.com/help/doc-detail/86737.htm)に従ってすぐに始めることができ、中国語の[Alibaba CloudにおけるKubernetesサポートの為のチュートリアル](https://yq.aliyun.com/teams/11/type_blog-cid_200-page_1)もあります。
クラスターの構築と管理を簡素化するために、[Alibaba Cloud Container ServiceのためのKubernetesサポート](https://www.alibabacloud.com/product/kubernetes)を使用します。[Kubernetes walk-through](https://www.alibabacloud.com/help/doc-detail/86737.htm)に従ってすぐに始めることができ、中国語の[Alibaba CloudにおけるKubernetesサポートのためのチュートリアル](https://yq.aliyun.com/teams/11/type_blog-cid_200-page_1)もあります。
カスタムバイナリもしくはオープンソースKubernetesを使用する場合は、以下の手順に従って下さい。
content/ja/docs/setup/release/_index.md
+1 -1
View File
@@ -1,4 +1,4 @@
---
title: "リリースノート及びバージョンスキュー"
title: "リリースノートおよびバージョンスキュー"
weight: 10
---
content/ja/docs/setup/release/version-skew-policy.md
+12 -12
View File
@@ -5,7 +5,7 @@ weight: 30
---
<!-- overview -->
このドキュメントでは、さまざまなKubernetesコンポーネント間でサポートされる最大のバージョンの差異（バージョンスキュー）について説明します。特定のクラスターデプロイツールは、バージョンの差異に追加の制限を加える場合があります。
このドキュメントでは、さまざまなKubernetesコンポーネント間でサポートされる最大のバージョンの差異(バージョンスキュー)について説明します。特定のクラスターデプロイツールは、バージョンの差異に追加の制限を加える場合があります。
<!-- body -->
@@ -52,7 +52,7 @@ HAクラスター内の`kube-apiserver`間にバージョンの差異がある
### kube-controller-manager、kube-scheduler、およびcloud-controller-manager
`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`は、通信する`kube-apiserver`インスタンスよりも新しいバージョンであってはなりません。`kube-apiserver`のマイナーバージョンと一致することが期待されますが、1つ古いマイナーバージョンでも可能です（ライブアップグレードを可能にするため）。
`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`は、通信する`kube-apiserver`インスタンスよりも新しいバージョンであってはなりません。`kube-apiserver`のマイナーバージョンと一致することが期待されますが、1つ古いマイナーバージョンでも可能です(ライブアップグレードを可能にするため)。
例:
@@ -60,17 +60,17 @@ HAクラスター内の`kube-apiserver`間にバージョンの差異がある
* `kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`は**1.13**および**1.12**がサポートされます
{{< note >}}
HAクラスター内の`kube-apiserver`間にバージョンの差異があり、これらのコンポーネントがクラスター内のいずれかの`kube-apiserver`と通信する場合（たとえばロードバランサーを経由して）、コンポーネントの有効なバージョンは少なくなります。
HAクラスター内の`kube-apiserver`間にバージョンの差異があり、これらのコンポーネントがクラスター内のいずれかの`kube-apiserver`と通信する場合(たとえばロードバランサーを経由して)、コンポーネントの有効なバージョンは少なくなります。
{{< /note >}}
例:
* `kube-apiserver`インスタンスが**1.13**および**1.12**であるとします
* いずれかの`kube-apiserver`インスタンスへ配信するロードバランサーと通信する`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`は**1.12**がサポートされます（**1.13**はバージョン**1.12**の`kube-apiserver`よりも新しくなるためサポートされません）
* いずれかの`kube-apiserver`インスタンスへ配信するロードバランサーと通信する`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`は**1.12**がサポートされます(**1.13**はバージョン**1.12**の`kube-apiserver`よりも新しくなるためサポートされません)
### kubectl
`kubectl`は`kube-apiserver`の1つ以内のバージョン（古い、または新しいもの）をサポートします。
`kubectl`は`kube-apiserver`の1つ以内のバージョン(古い、または新しいもの)をサポートします。
例:
@@ -84,7 +84,7 @@ HAクラスター内の`kube-apiserver`間にバージョンの差異がある
例:
* `kube-apiserver`インスタンスが**1.13**および**1.12**であるとします
* `kubectl`は**1.13**および**1.12**がサポートされます（ほかのバージョンでは、ある`kube-apiserver`コンポーネントからマイナーバージョンが2つ以上離れる可能性があります）
* `kubectl`は**1.13**および**1.12**がサポートされます(ほかのバージョンでは、ある`kube-apiserver`コンポーネントからマイナーバージョンが2つ以上離れる可能性があります)
## サポートされるコンポーネントのアップグレード順序
@@ -95,11 +95,11 @@ HAクラスター内の`kube-apiserver`間にバージョンの差異がある
前提条件:
* シングルインスタンスのクラスターにおいて、既存の`kube-apiserver`インスタンスは**1.n**とします
* HAクラスターにおいて、既存の`kube-apiserver`は**1.n**または**1.(n+1)** とします（最新と最古の間で、最大で1つのマイナーバージョンの差異となります）
* サーバーと通信する`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`はバージョン**1.n**とします（必ず既存のAPIサーバーのバージョンよりも新しいものでなく、かつ新しいAPIサーバーのバージョンの1つ以内のマイナーバージョンとなります）
* すべてのノードの`kubelet`インスタンスはバージョン**1.n**または**1.(n-1)** とします（必ず既存のAPIサーバーよりも新しいバージョンでなく、かつ新しいAPIサーバーのバージョンの2つ以内のマイナーバージョンとなります）
* HAクラスターにおいて、既存の`kube-apiserver`は**1.n**または**1.(n+1)** とします(最新と最古の間で、最大で1つのマイナーバージョンの差異となります)
* サーバーと通信する`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`はバージョン**1.n**とします(必ず既存のAPIサーバーのバージョンよりも新しいものでなく、かつ新しいAPIサーバーのバージョンの1つ以内のマイナーバージョンとなります)
* すべてのノードの`kubelet`インスタンスはバージョン**1.n**または**1.(n-1)** とします(必ず既存のAPIサーバーよりも新しいバージョンでなく、かつ新しいAPIサーバーのバージョンの2つ以内のマイナーバージョンとなります)
* 登録されたAdmission webhookは、新しい`kube-apiserver`インスタンスが送信するこれらのデータを扱うことができます:
* `ValidatingWebhookConfiguration`および`MutatingWebhookConfiguration`オブジェクトは、**1.(n+1)** で追加されたRESTリソースの新しいバージョンを含んで更新されます（または、v1.15から利用可能な[`matchPolicy: Equivalent`オプション](/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy)を使用してください）
* `ValidatingWebhookConfiguration`および`MutatingWebhookConfiguration`オブジェクトは、**1.(n+1)** で追加されたRESTリソースの新しいバージョンを含んで更新されます(または、v1.15から利用可能な[`matchPolicy: Equivalent`オプション](/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy)を使用してください)
* Webhookは送信されたRESTリソースの新しいバージョン、および**1.(n+1)** のバージョンで追加された新しいフィールドを扱うことができます
`kube-apiserver`を**1.(n+1)** にアップグレードしてください。
@@ -112,7 +112,7 @@ HAクラスター内の`kube-apiserver`間にバージョンの差異がある
前提条件:
* これらのコンポーネントと通信する`kube-apiserver`インスタンスが**1.(n+1)** であること（これらのコントロールプレーンコンポーネントが、クラスター内の`kube-apiserver`インスタンスと通信できるHAクラスターでは、これらのコンポーネントをアップグレードする前にすべての`kube-apiserver`インスタンスをアップグレードしなければなりません）
* これらのコンポーネントと通信する`kube-apiserver`インスタンスが**1.(n+1)** であること(これらのコントロールプレーンコンポーネントが、クラスター内の`kube-apiserver`インスタンスと通信できるHAクラスターでは、これらのコンポーネントをアップグレードする前にすべての`kube-apiserver`インスタンスをアップグレードしなければなりません)
`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`を**1.(n+1)** にアップグレードしてください。
@@ -122,7 +122,7 @@ HAクラスター内の`kube-apiserver`間にバージョンの差異がある
* `kubelet`と通信する`kube-apiserver`が**1.(n+1)** であること
必要に応じて、`kubelet`インスタンスを**1.(n+1)** にアップグレードしてください（**1.n**や**1.(n-1)** のままにすることもできます）。
必要に応じて、`kubelet`インスタンスを**1.(n+1)** にアップグレードしてください(**1.n**や**1.(n-1)** のままにすることもできます)。
{{< warning >}}
`kube-apiserver`と2つのマイナーバージョンの`kubelet`インスタンスを使用してクラスターを実行させることは推奨されません:
content/ja/docs/tasks/administer-cluster/coredns.md
+1 -1
View File
@@ -39,7 +39,7 @@ kubeadm upgrade apply v1.11.0 --feature-gates=CoreDNS=true
Kubernetesバージョン1.13以降では、`CoreDNS`フィーチャーゲートが削除され、CoreDNSがデフォルトで使用されます。アップグレードしたクラスターでkube-dnsを使用する場合は、[こちら](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon)のガイドに従ってください。
1.11以前のバージョンでは、Corefileはアップグレード中に作成されたものによって**上書き**されます。**カスタマイズしている場合は、既存のConfigMapを保存する必要があります。**新しいConfigMapが稼働したら、カスタマイズを再適用できます。
1.11以前のバージョンでは、Corefileはアップグレード中に作成されたものによって**上書き**されます。**カスタマイズしている場合は、既存のConfigMapを保存する必要があります。** 新しいConfigMapが稼働したら、カスタマイズを再適用できます。
Kubernetesバージョン1.11以降でCoreDNSを実行している場合、アップグレード中、既存のCorefileは保持されます。
content/ja/docs/tasks/administer-cluster/running-cloud-controller.md
+5 -5
View File
@@ -9,7 +9,7 @@ content_type: concept
Kubernetes v1.6では`cloud-controller-manager`という新しいバイナリが導入されました。`cloud-controller-manager`はクラウド固有の制御ループを組み込むデーモンです。これらのクラウド固有の制御ループはもともと`kube-controller-manager`にありました。クラウドプロバイダーはKubernetesプロジェクトとは異なるペースで開発およびリリースされるため、プロバイダー固有のコードを`cloud-controller-manager`バイナリに抽象化することでクラウドベンダーはKubernetesのコアのコードとは独立して開発が可能となりました。
`cloud-controller-manager`は、[cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go)を満たす任意のクラウドプロバイダーと接続できます。下位互換性のためにKubernetesのコアプロジェクトで提供される[cloud-controller-manager](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager)は`kube-controller-manager`と同じクラウドライブラリを使用します。Kubernetesのコアリポジトリで既にサポートされているクラウドプロバイダーは、Kubernetesリポジトリにあるcloud-controller-managerを使用してKubernetesのコアから移行することが期待されています。今後のKubernetesのリリースでは、すべてのクラウドコントローラーマネージャーはsigリードまたはクラウドベンダーが管理するKubernetesのコアプロジェクトの外で開発される予定です。
`cloud-controller-manager`は、[cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go)を満たす任意のクラウドプロバイダーと接続できます。下位互換性のためにKubernetesのコアプロジェクトで提供される[cloud-controller-manager](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager)は`kube-controller-manager`と同じクラウドライブラリを使用します。Kubernetesのコアリポジトリですでにサポートされているクラウドプロバイダーは、Kubernetesリポジトリにあるcloud-controller-managerを使用してKubernetesのコアから移行することが期待されています。今後のKubernetesのリリースでは、すべてのクラウドコントローラーマネージャーはsigリードまたはクラウドベンダーが管理するKubernetesのコアプロジェクトの外で開発される予定です。
@@ -24,7 +24,7 @@ Kubernetes v1.6では`cloud-controller-manager`という新しいバイナリが
* クラウドの認証/認可: クラウドではAPIへのアクセスを許可するためにトークンまたはIAMルールが必要になる場合があります
* kubernetesの認証/認可: cloud-controller-managerは、kubernetes apiserverと通信するためにRBACルールの設定を必要とする場合があります
* 高可用性: kube-controller-managerのように、リーダー選出を使用したクラウドコントローラーマネージャーの高可用性のセットアップが必要になる場合があります（デフォルトでオンになっています）。
* 高可用性: kube-controller-managerのように、リーダー選出を使用したクラウドコントローラーマネージャーの高可用性のセットアップが必要になる場合があります(デフォルトでオンになっています)。
### cloud-controller-managerを動かす
@@ -35,7 +35,7 @@ cloud-controller-managerを正常に実行するにはクラスター構成に
クラウドコントローラーマネージャーを使用するようにクラスターを設定するとクラスターの動作がいくつか変わることに注意してください。
* `--cloud-provider=external`を指定したkubeletは、初期化時に`NoSchedule`の`node.cloudprovider.kubernetes.io/uninitialized`汚染を追加します。これによりノードは作業をスケジュールする前に外部のコントローラーからの2回目の初期化が必要であるとマークされます。クラウドコントローラーマネージャーが使用できない場合クラスター内の新しいノードはスケジュールできないままになることに注意してください。スケジューラーはリージョンやタイプ（高CPU、GPU、高メモリ、スポットインスタンスなど）などのノードに関するクラウド固有の情報を必要とする場合があるためこの汚染は重要です。
* `--cloud-provider=external`を指定したkubeletは、初期化時に`NoSchedule`の`node.cloudprovider.kubernetes.io/uninitialized`汚染を追加します。これによりノードは作業をスケジュールする前に外部のコントローラーからの2回目の初期化が必要であるとマークされます。クラウドコントローラーマネージャーが使用できない場合クラスター内の新しいノードはスケジュールできないままになることに注意してください。スケジューラーはリージョンやタイプ(高CPU、GPU、高メモリ、スポットインスタンスなど)などのノードに関するクラウド固有の情報を必要とする場合があるためこの汚染は重要です。
* クラスター内のノードに関するクラウド情報はローカルメタデータを使用して取得されなくなりましたが、代わりにノード情報を取得するためのすべてのAPI呼び出しはクラウドコントローラーマネージャーを経由して行われるようになります。これはセキュリティを向上させるためにkubeletでクラウドAPIへのアクセスを制限できることを意味します。大規模なクラスターではクラスター内からクラウドのほとんどすべてのAPI呼び出しを行うため、クラウドコントローラーマネージャーがレートリミットに達するかどうかを検討する必要があります。
v1.8の時点でクラウドコントローラーマネージャーは以下を実装できます。
@@ -69,7 +69,7 @@ Kubernetesのコアリポジトリにないクラウドコントローラーマ
### ボリュームのサポート
ボリュームの統合にはkubeletとの調整も必要になるためクラウドコントローラーマネージャーは`kube-controller-manager`にあるボリュームコントローラーを実装しません。CSI（コンテナストレージインターフェイス）が進化してFlexボリュームプラグインの強力なサポートが追加されるにつれ、クラウドがボリュームと完全に統合できるようクラウドコントローラーマネージャーに必要なサポートが追加されます。Kubernetesリポジトリの外部にあるCSIボリュームプラグインの詳細については[こちら](https://github.com/kubernetes/features/issues/178)をご覧ください。
ボリュームの統合にはkubeletとの調整も必要になるためクラウドコントローラーマネージャーは`kube-controller-manager`にあるボリュームコントローラーを実装しません。CSI(コンテナストレージインターフェイス)が進化してFlexボリュームプラグインの強力なサポートが追加されるにつれ、クラウドがボリュームと完全に統合できるようクラウドコントローラーマネージャーに必要なサポートが追加されます。Kubernetesリポジトリの外部にあるCSIボリュームプラグインの詳細については[こちら](https://github.com/kubernetes/features/issues/178)をご覧ください。
### スケーラビリティ
@@ -79,7 +79,7 @@ Kubernetesのコアリポジトリにないクラウドコントローラーマ
クラウドコントローラーマネージャープロジェクトの目標はKubernetesのコアプロジェクトからクラウドに関する機能の開発を切り離すことです。残念ながら、Kubernetesプロジェクトの多くの面でクラウドプロバイダーの機能がKubernetesプロジェクトに緊密に結びついているという前提があります。そのため、この新しいアーキテクチャを採用するとクラウドプロバイダーの情報を要求する状況が発生する可能性がありますが、クラウドコントローラーマネージャーはクラウドプロバイダーへのリクエストが完了するまでその情報を返すことができない場合があります。
これの良い例は、KubeletのTLSブートストラップ機能です。現在、TLSブートストラップはKubeletがすべてのアドレスタイプ（プライベート、パブリックなど）をクラウドプロバイダー（またはローカルメタデータサービス）に要求する能力を持っていると仮定していますが、クラウドコントローラーマネージャーは最初に初期化されない限りノードのアドレスタイプを設定できないためapiserverと通信するためにはkubeletにTLS証明書が必要です。
これの良い例は、KubeletのTLSブートストラップ機能です。現在、TLSブートストラップはKubeletがすべてのアドレスタイプ(プライベート、パブリックなど)をクラウドプロバイダー(またはローカルメタデータサービス)に要求する能力を持っていると仮定していますが、クラウドコントローラーマネージャーは最初に初期化されない限りノードのアドレスタイプを設定できないためapiserverと通信するためにはkubeletにTLS証明書が必要です。
このイニシアチブが成熟するに連れ、今後のリリースでこれらの問題に対処するための変更が行われます。
content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md
+1 -1
View File
@@ -196,7 +196,7 @@ kubectl delete pod cpu-demo-2 --namespace=cpu-example
クラスターで動作するコンテナにCPU要求と制限を設定することで、クラスターのノードで利用可能なCPUリソースを効率的に使用することができます。PodのCPU要求を低く保つことで、Podがスケジュールされやすくなります。CPU要求よりも大きい制限を与えることで、次の2つを実現できます:
* Podは利用可能なCPUリソースを、突発的な活動（バースト）に使用することができます。
* Podは利用可能なCPUリソースを、突発的な活動(バースト)に使用することができます。
* バースト中のPodのCPUリソース量は、適切な量に制限されます。
content/ja/docs/tasks/configure-pod-container/assign-memory-resource.md
+2 -2
View File
@@ -97,7 +97,7 @@ resources:
kubectl top pod memory-demo --namespace=mem-example
```
この出力では、Podが約162,900,000バイト（約150MiB）のメモリーを使用していることを示しています。Podの100MiBの要求を超えていますが、200MiBの制限には収まっています。
この出力では、Podが約162,900,000バイト(約150MiB)のメモリーを使用していることを示しています。Podの100MiBの要求を超えていますが、200MiBの制限には収まっています。
```
NAME CPU(cores) MEMORY(bytes)
@@ -278,7 +278,7 @@ kubectl delete pod memory-demo-3 --namespace=mem-example
クラスターで動作するコンテナにメモリー要求と制限を設定することで、クラスターのノードで利用可能なメモリーリソースを効率的に使用することができます。Podのメモリー要求を低く保つことで、Podがスケジュールされやすくなります。メモリー要求よりも大きい制限を与えることで、次の2つを実現できます:
* Podは利用可能なメモリーを、突発的な活動（バースト）に使用することができます。
* Podは利用可能なメモリーを、突発的な活動(バースト)に使用することができます。
* バースト中のPodのメモリー使用量は、適切な量に制限されます。
## クリーンアップ
content/ja/docs/tasks/configure-pod-container/assign-pods-nodes.md
+93
View File
@@ -0,0 +1,93 @@
---
title: Podをノードに割り当てる
content_type: task
weight: 120
---
<!-- overview -->
このページでは、KubernetesのPodをKubernetesクラスター上の特定のノードに割り当てる方法を説明します。
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- steps -->
## ラベルをノードに追加する
1. クラスター内の{{< glossary_tooltip term_id="node" text="ノード" >}}のリストをラベル付きで表示します。
```shell
kubectl get nodes --show-labels
```
出力は次のようになります。
```shell
NAME STATUS ROLES AGE VERSION LABELS
worker0 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker0
worker1 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker1
worker2 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker2
```
1. ノードの1つを選択して、ラベルを追加します。
```shell
kubectl label nodes <your-node-name> disktype=ssd
```
ここで、`<your-node-name>`は選択したノードの名前です。
1. 選択したノードに`disktype=ssd`ラベルがあることを確認します。
```shell
kubectl get nodes --show-labels
```
出力は次のようになります。
```shell
NAME STATUS ROLES AGE VERSION LABELS
worker0 Ready <none> 1d v1.13.0 ...,disktype=ssd,kubernetes.io/hostname=worker0
worker1 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker1
worker2 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker2
```
上の出力を見ると、`worker0`に`disktype=ssd`というラベルがあることがわかります。
## 選択したノードにスケジューリングされるPodを作成する
以下のPodの構成ファイルには、nodeSelectorに`disktype: ssd`を持つPodが書かれています。これにより、Podは`disktype: ssd`というラベルを持っているノードにスケジューリングされるようになります。
{{< codenew file="pods/pod-nginx.yaml" >}}
1. 構成ファイルを使用して、選択したノードにスケジューリングされるPodを作成します。
```shell
kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml
```
1. Podが選択したノード上で実行されているをことを確認します。
```shell
kubectl get pods --output=wide
```
出力は次のようになります。
```shell
NAME READY STATUS RESTARTS AGE IP NODE
nginx 1/1 Running 0 13s 10.200.0.4 worker0
```
## 特定のノードにスケジューリングされるPodを作成する
`nodeName`という設定を使用して、Podを特定のノードにスケジューリングすることもできます。
{{< codenew file="pods/pod-nginx-specific-node.yaml" >}}
構成ファイルを使用して、`foo-node`にだけスケジューリングされるPodを作成します。
## {{% heading "whatsnext" %}}
* [ラベルとセレクター](/ja/docs/concepts/overview/working-with-objects/labels/)についてさらに学ぶ。
* [ノード](/ja/docs/concepts/architecture/nodes/)についてさらに学ぶ。
content/ja/docs/tasks/configure-pod-container/configure-projected-volume-storage.md
+1 -1
View File
@@ -5,7 +5,7 @@ weight: 70
---
<!-- overview -->
このページでは、[`projected`](/docs/concepts/storage/volumes/#projected)（投影）ボリュームを使用して、既存の複数のボリュームソースを同一ディレクトリ内にマウントする方法を説明します。
このページでは、[`projected`](/docs/concepts/storage/volumes/#projected)(投影)ボリュームを使用して、既存の複数のボリュームソースを同一ディレクトリ内にマウントする方法を説明します。
現在、`secret`、`configMap`、`downwardAPI`および`serviceAccountToken`ボリュームを投影できます。
{{< note >}}
content/ja/docs/tasks/configure-pod-container/configure-volume-storage.md
+1 -1
View File
@@ -87,7 +87,7 @@ weight: 50
root@redis:/data/redis# kill <pid>
```
ここで`<pid>`はRedisプロセスID（PID）です。
ここで`<pid>`はRedisプロセスID(PID)です。
1. 元の端末で、Redis Podへの変更を監視します。最終的には、このようなものが表示されます:
content/ja/docs/tasks/configure-pod-container/share-process-namespace.md
+1 -1
View File
@@ -97,7 +97,7 @@ Podは多くのリソースを共有するため、プロセスの名前空間
ただし、一部のコンテナイメージは他のコンテナから分離されることが期待されるため、これらの違いを理解することが重要です:
1. **コンテナプロセスは PID 1ではなくなります。**
一部のコンテナイメージは、PID 1なしで起動することを拒否し（たとえば、`systemd`を使用するコンテナ）、`kill -HUP 1`などのコマンドを実行してコンテナプロセスにシグナルを送信します。
一部のコンテナイメージは、PID 1なしで起動することを拒否し(たとえば、`systemd`を使用するコンテナ)、`kill -HUP 1`などのコマンドを実行してコンテナプロセスにシグナルを送信します。
共有プロセス名前空間を持つPodでは、`kill -HUP 1`はPodサンドボックスにシグナルを送ります。(上の例では`/pause`)
1. **プロセスはPod内の他のコンテナに表示されます。**
content/ja/docs/tasks/debug-application-cluster/debug-service.md
+48 -124
View File
@@ -4,9 +4,7 @@ title: Serviceのデバッグ
---
<!-- overview -->
新規にKubernetesをインストールした環境でかなり頻繁に発生する問題は、Serviceが適切に機能しないというものです。
Deployment（または他のワークロードコントローラー）を通じてPodを実行し、サービスを作成したにもかかわらず、アクセスしようとしても応答がありません。
何が問題になっているのかを理解するのに、このドキュメントがきっと役立つでしょう。
新規にKubernetesをインストールした環境でかなり頻繁に発生する問題は、Serviceが適切に機能しないというものです。Deployment(または他のワークロードコントローラー)を通じてPodを実行し、サービスを作成したにもかかわらず、アクセスしようとしても応答がありません。何が問題になっているのかを理解するのに、このドキュメントがきっと役立つでしょう。
@@ -16,8 +14,7 @@ Deployment（または他のワークロードコントローラー）を通じ
## Pod内でコマンドを実行する
ここでの多くのステップでは、クラスターで実行されているPodが見ているものを確認する必要があります。
これを行う最も簡単な方法は、インタラクティブなalpineのPodを実行することです。
ここでの多くのステップでは、クラスターで実行されているPodが見ているものを確認する必要があります。これを行う最も簡単な方法は、インタラクティブなalpineのPodを実行することです。
```none
kubectl run -it --rm --restart=Never alpine --image=alpine sh
@@ -27,7 +24,7 @@ kubectl run -it --rm --restart=Never alpine --image=alpine sh
コマンドプロンプトが表示されない場合は、Enterキーを押してみてください。
{{< /note >}}
使用したい実行中のPodが既にある場合は、以下のようにしてそのPod内でコマンドを実行できます。
使用したい実行中のPodがすでにある場合は、以下のようにしてそのPod内でコマンドを実行できます。
```shell
kubectl exec <POD-NAME> -c <CONTAINER-NAME> -- <COMMAND>
@@ -35,8 +32,7 @@ kubectl exec <POD-NAME> -c <CONTAINER-NAME> -- <COMMAND>
## セットアップ
このドキュメントのウォークスルーのために、いくつかのPodを実行しましょう。
おそらくあなた自身のServiceをデバッグしているため、あなた自身の詳細に置き換えることもできますし、これに沿って2番目のデータポイントを取得することもできます。
このドキュメントのウォークスルーのために、いくつかのPodを実行しましょう。おそらくあなた自身のServiceをデバッグしているため、あなた自身の詳細に置き換えることもできますし、これに沿って2番目のデータポイントを取得することもできます。
```shell
kubectl run hostnames --image=k8s.gcr.io/serve_hostname \
@@ -48,7 +44,7 @@ deployment.apps/hostnames created
`kubectl`コマンドは作成、変更されたリソースのタイプと名前を出力するため、この後のコマンドで使用することもできます。
{{< note >}}
これは、次のYAMLでDeploymentを開始した場合と同じです。
```yaml
@@ -72,7 +68,6 @@ spec:
```
"run"ラベルは`kubectl run`によって、Deploymentの名前に自動的にセットされます。
{{< /note >}}
Podが実行されていることを確認できます。
@@ -86,8 +81,7 @@ hostnames-632524106-ly40y 1/1 Running 0 2m
hostnames-632524106-tlaok 1/1 Running 0 2m
```
Podが機能していることも確認できます。
Pod IP アドレスリストを取得し、直接テストできます。
Podが機能していることも確認できます。Pod IP アドレスリストを取得し、直接テストできます。
```shell
kubectl get pods -l run=hostnames \
@@ -117,8 +111,7 @@ hostnames-bvc05
hostnames-yp2kp
```
この時点で期待通りの応答が得られない場合、Podが正常でないか、想定しているポートでリッスンしていない可能性があります。
なにが起きているかを確認するために`kubectl logs`が役立ちます、Podに直接に入りデバッグする場合は `kubectl exec`が必要になります。
この時点で期待通りの応答が得られない場合、Podが正常でないか、想定しているポートでリッスンしていない可能性があります。なにが起きているかを確認するために`kubectl logs`が役立ちます。Podに直接に入りデバッグする場合は`kubectl exec`が必要になります。
これまでにすべての計画が完了していると想定すると、Serviceが機能しない理由を調査することができます。
@@ -126,8 +119,7 @@ hostnames-yp2kp
賢明な読者は、Serviceをまだ実際に作成していないことにお気付きかと思いますが、これは意図的です。これは時々忘れられるステップであり、最初に確認すべきことです。
存在しないServiceにアクセスしようとするとどうなるでしょうか？
このServiceを名前で利用する別のPodがあると仮定すると、次のような結果が得られます。
存在しないServiceにアクセスしようとするとどうなるでしょうか？このServiceを名前で利用する別のPodがあると仮定すると、次のような結果が得られます。
```shell
wget -O- hostnames
@@ -147,8 +139,7 @@ No resources found.
Error from server (NotFound): services "hostnames" not found
```
Serviceを作成しましょう。
前と同様に、これはウォークスルー用です。ご自身のServiceの詳細を使用することもできます。
Serviceを作成しましょう。前と同様に、これはウォークスルー用です。ご自身のServiceの詳細を使用することもできます。
```shell
kubectl expose deployment hostnames --port=80 --target-port=9376
@@ -169,7 +160,6 @@ hostnames ClusterIP 10.0.1.175 <none> 80/TCP 5s
これで、Serviceが存在することがわかりました。
{{< note >}}
前と同様に、これは次のようなYAMLでServiceを開始した場合と同じです。
```yaml
@@ -187,14 +177,11 @@ spec:
targetPort: 9376
```
構成の全範囲をハイライトするため、ここで作成したServiceはPodとは異なるポート番号を使用します。
多くの実際のServiceでは、これらのポートは同じになる場合があります。
{{< /note >}}
構成の全範囲をハイライトするため、ここで作成したServiceはPodとは異なるポート番号を使用します。多くの実際のServiceでは、これらのポートは同じになる場合があります。
## サービスはDNS名によって機能しているか？
クライアントがサービスを使用する最も一般的な方法の1つは、DNS名を使用することです。
同じNamespaceのPodから次のコマンドを実行してください。
クライアントがサービスを使用する最も一般的な方法の1つは、DNS名を使用することです。同じNamespaceのPodから次のコマンドを実行してください。
```shell
nslookup hostnames
@@ -219,8 +206,7 @@ Name: hostnames.default
Address 1: 10.0.1.175 hostnames.default.svc.cluster.local
```
これが機能する場合、クロスネームスペース名を使用するようにアプリケーションを調整するか、同じNamespaceでアプリとServiceを実行する必要があります。
これでも失敗する場合は、完全修飾名を試してください。
これが機能する場合、クロスネームスペース名を使用するようにアプリケーションを調整するか、同じNamespaceでアプリとServiceを実行する必要があります。これでも失敗する場合は、完全修飾名を試してください。
```shell
nslookup hostnames.default.svc.cluster.local
@@ -232,10 +218,7 @@ Name: hostnames.default.svc.cluster.local
Address 1: 10.0.1.175 hostnames.default.svc.cluster.local
```
ここでのサフィックス"default.svc.cluster.local"に注意してください。
"default"は、操作しているNamespaceです。
"svc"は、これがServiceであることを示します。
"cluster.local"はクラスタードメインであり、あなたのクラスターでは異なる場合があります。
ここでのサフィックス"default.svc.cluster.local"に注意してください。"default"は、操作しているNamespaceです。"svc"は、これがServiceであることを示します。"cluster.local"はクラスタードメインであり、あなたのクラスターでは異なる場合があります。
クラスター内のノードからも試すこともできます。
@@ -254,8 +237,7 @@ Name: hostnames.default.svc.cluster.local
Address: 10.0.1.175
```
完全修飾名では検索できるのに、相対名ではできない場合、Podの`/etc/resolv.conf`ファイルが正しいことを確認する必要があります。
Pod内から実行します。
完全修飾名では検索できるのに、相対名ではできない場合、Podの`/etc/resolv.conf`ファイルが正しいことを確認する必要があります。Pod内から実行します。
```shell
cat /etc/resolv.conf
@@ -269,25 +251,15 @@ search default.svc.cluster.local svc.cluster.local cluster.local example.com
options ndots:5
```
nameserver行はクラスターのDNS Serviceを示さなければなりません。
これは、`--cluster-dns`フラグで`kubelet`に渡されます。
nameserver行はクラスターのDNS Serviceを示さなければなりません。これは、`--cluster-dns`フラグで`kubelet`に渡されます。
`search`行には、`Service`名を見つけるための適切なサフィックスを含める必要があります。
この場合、ローカルの`Namespace`で`Service`を見つけるためのサフィックス(`default.svc.cluster.local`)、すべての`Namespaces`で`Service`を見つけるためのサフィックス(`svc.cluster.local`)、およびクラスターのサフィックス(`cluster.local`)です。
インストール方法によっては、その後に追加のレコードがある場合があります(合計6つまで)。
クラスターのサフィックスは、`--cluster-domain`フラグを使用して`kubelet`に渡されます。
このドキュメントではそれが"cluster.local"であると仮定していますが、あなたのクラスターでは異なる場合があります。
その場合は、上記のすべてのコマンドでクラスターのサフィックスを変更する必要があります。
`search`行には、`Service`名を見つけるための適切なサフィックスを含める必要があります。この場合、ローカルの`Namespace`で`Service`を見つけるためのサフィックス(`default.svc.cluster.local`)、すべての`Namespaces`で`Service`を見つけるためのサフィックス(`svc.cluster.local`)、およびクラスターのサフィックス(`cluster.local`)です。インストール方法によっては、その後に追加のレコードがある場合があります(合計6つまで)。クラスターのサフィックスは、`--cluster-domain`フラグを使用して`kubelet`に渡されます。このドキュメントではそれが"cluster.local"であると仮定していますが、あなたのクラスターでは異なる場合があります。その場合は、上記のすべてのコマンドでクラスターのサフィックスを変更する必要があります。
`options`行では、DNSクライアントライブラリーが検索パスをまったく考慮しないように`ndots`を十分に高く設定する必要があります。
Kubernetesはデフォルトでこれを5に設定します。これは、生成されるすべてのDNS名をカバーするのに十分な大きさです。
`options`行では、DNSクライアントライブラリーが検索パスをまったく考慮しないように`ndots`を十分に高く設定する必要があります。Kubernetesはデフォルトでこれを5に設定します。これは、生成されるすべてのDNS名をカバーするのに十分な大きさです。
### DNS名で機能するServiceはありますか？ {#does-any-service-exist-in-dns}
### DNS名で機能するServiceはあるか？ {#does-any-service-exist-in-dns}
上記がまだ失敗する場合、DNSルックアップがServiceに対して機能していません。
一歩離れて、他の何が機能していないかを確認しましょう。
KubernetesマスターのServiceは常に機能するはずです。
Pod内から実行します。
上記がまだ失敗する場合、DNSルックアップがServiceに対して機能していません。一歩離れて、他の何が機能していないかを確認しましょう。KubernetesマスターのServiceは常に機能するはずです。Pod内から実行します。
```shell
nslookup kubernetes.default
@@ -300,12 +272,11 @@ Name: kubernetes.default
Address 1: 10.0.0.1 kubernetes.default.svc.cluster.local
```
これが失敗する場合は、このドキュメントの [kube-proxy](#is-the-kube-proxy-working)セクションを参照するか、このドキュメントの先頭に戻って最初からやり直してください。ただし、あなた自身のServiceをデバッグするのではなく 、DNSサービスをデバッグします。
これが失敗する場合は、このドキュメントの[kube-proxy](#is-the-kube-proxy-working)セクションを参照するか、このドキュメントの先頭に戻って最初からやり直してください。ただし、あなた自身のServiceをデバッグするのではなく、DNSサービスをデバッグします。
## ServiceはIPでは機能するか？
DNSサービスが正しく動作できると仮定すると、次にテストするのはIPによってServiceが動作しているかどうかです。
上述の`kubectl get`で確認できるIPに、クラスター内のPodからアクセスします。
DNSサービスが正しく動作できると仮定すると、次にテストするのはIPによってServiceが動作しているかどうかです。上述の`kubectl get`で確認できるIPに、クラスター内のPodからアクセスします。
```shell
for i in $(seq 1 3); do
@@ -321,13 +292,11 @@ hostnames-bvc05
hostnames-yp2kp
```
Serviceが機能している場合は、正しい応答が得られるはずです。
そうでない場合、おかしい可能性のあるものがいくつかあるため、続けましょう。
Serviceが機能している場合は、正しい応答が得られるはずです。そうでない場合、おかしい可能性のあるものがいくつかあるため、続けましょう。
## Serviceは正しく定義されているか？
馬鹿げているように聞こえるかもしれませんが、Serviceが正しく定義されPodのポートとマッチすることを二度、三度と確認すべきです。
Serviceを読み返して確認しましょう。
馬鹿げているように聞こえるかもしれませんが、Serviceが正しく定義されPodのポートとマッチすることを二度、三度と確認すべきです。Serviceを読み返して確認しましょう。
```shell
kubectl get service hostnames -o json
@@ -377,8 +346,7 @@ kubectl get service hostnames -o json
## ServiceにEndpointsがあるか？
ここまで来たということは、Serviceは正しく定義され、DNSによって名前解決できることが確認できているでしょう。
ここでは、実行したPodがServiceによって実際に選択されていることを確認しましょう。
ここまで来たということは、Serviceは正しく定義され、DNSによって名前解決できることが確認できているでしょう。ここでは、実行したPodがServiceによって実際に選択されていることを確認しましょう。
以前に、Podが実行されていることを確認しました。再確認しましょう。
@@ -395,8 +363,7 @@ hostnames-yp2kp 1/1 Running 0 1h
"AGE"列は、これらのPodが約1時間前のものであることを示しており、それらが正常に実行され、クラッシュしていないことを意味します。
"RESTARTS"列は、これらのポッドが頻繁にクラッシュしたり、再起動されていないことを示しています。 頻繁に再起動すると、断続的な接続性の問題が発生する可能性があります。
再起動回数が多い場合は、[ポッドをデバッグする](/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller/#podのデバッグ)を参照してください。
"RESTARTS"列は、これらのポッドが頻繁にクラッシュしたり、再起動されていないことを示しています。頻繁に再起動すると、断続的な接続性の問題が発生する可能性があります。再起動回数が多い場合は、[ポッドをデバッグする](/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller/#podのデバッグ)を参照してください。
Kubernetesシステム内には、すべてのServiceのセレクターを評価し、結果をEndpointsオブジェクトに保存するコントロールループがあります。
@@ -407,15 +374,11 @@ NAME ENDPOINTS
hostnames 10.244.0.5:9376,10.244.0.6:9376,10.244.0.7:9376
```
これにより、EndpointsコントローラーがServiceの正しいPodを見つけていることを確認できます。
`ENDPOINTS`列が`<none>`の場合、Serviceの`spec.selector`フィールドが実際にPodの`metadata.labels`値を選択していることを確認する必要があります。
よくある間違いは、タイプミスまたは他のエラー、たとえばServiceが`app=hostnames`を選択しているのにDeploymentが`run=hostnames`を指定していることです。
これにより、EndpointsコントローラーがServiceの正しいPodを見つけていることを確認できます。`ENDPOINTS`列が`<none>`の場合、Serviceの`spec.selector`フィールドが実際にPodの`metadata.labels`値を選択していることを確認する必要があります。よくある間違いは、タイプミスまたは他のエラー、たとえばServiceが`app=hostnames`を選択しているのにDeploymentが`run=hostnames`を指定していることです。
## Podは機能しているか？
この時点で、Serviceが存在し、Podを選択していることがわかります。
このウォークスルーの最初に、Pod自体を確認しました。
Podが実際に機能していることを確認しましょう。Serviceメカニズムをバイパスして、上記EndpointsにリストされているPodに直接アクセスすることができます。
この時点で、Serviceが存在し、Podを選択していることがわかります。このウォークスルーの最初に、Pod自体を確認しました。Podが実際に機能していることを確認しましょう。Serviceメカニズムをバイパスして、上記EndpointsにリストされているPodに直接アクセスすることができます。
{{< note >}}
これらのコマンドは、Serviceポート(80)ではなく、Podポート(9376)を使用します。
@@ -437,23 +400,17 @@ hostnames-bvc05
hostnames-yp2kp
```
Endpointsリスト内の各Podは、それぞれの自身のホスト名を返すはずです。
そうならない(または、あなた自身のPodの正しい振る舞いにならない)場合は、そこで何が起こっているのかを調査する必要があります。
Endpointsリスト内の各Podは、それぞれの自身のホスト名を返すはずです。そうならない(または、あなた自身のPodの正しい振る舞いにならない)場合は、そこで何が起こっているのかを調査する必要があります。
## kube-proxyは機能しているか？ {#is-the-kube-proxy-working}
ここに到達したのなら、Serviceは実行され、Endpointsがあり、Podが実際にサービスを提供しています。
この時点で、Serviceのプロキシーメカニズム全体が疑わしいです。
ひとつひとつ確認しましょう。
ここに到達したのなら、Serviceは実行され、Endpointsがあり、Podが実際にサービスを提供しています。この時点で、Serviceのプロキシーメカニズム全体が疑わしいです。ひとつひとつ確認しましょう。
Serviceのデフォルト実装、およびほとんどのクラスターで使用されるものは、kube-proxyです。
kube-proxyはそれぞれのノードで実行され、Serviceの抽象化を提供するための小さなメカニズムセットの1つを構成するプログラムです。
クラスターがkube-proxyを使用しない場合、以下のセクションは適用されず、使用しているServiceの実装を調査する必要があります。
Serviceのデフォルト実装、およびほとんどのクラスターで使用されるものは、kube-proxyです。kube-proxyはそれぞれのノードで実行され、Serviceの抽象化を提供するための小さなメカニズムセットの1つを構成するプログラムです。クラスターがkube-proxyを使用しない場合、以下のセクションは適用されず、使用しているServiceの実装を調査する必要があります。
### kube-proxyは実行されているか？
`kube-proxy`がノード上で実行されていることを確認しましょう。
ノードで実行されていれば、以下のような結果が得られるはずです。
`kube-proxy`がノード上で実行されていることを確認しましょう。ノードで実行されていれば、以下のような結果が得られるはずです。
```shell
ps auxw | grep kube-proxy
@@ -462,11 +419,7 @@ ps auxw | grep kube-proxy
root 4194 0.4 0.1 101864 17696 ? Sl Jul04 25:43 /usr/local/bin/kube-proxy --master=https://kubernetes-master --kubeconfig=/var/lib/kube-proxy/kubeconfig --v=2
```
次に、マスターとの接続など、明らかな失敗をしていないことを確認します。
これを行うには、ログを確認する必要があります。
ログへのアクセス方法は、ノードのOSに依存します。
一部のOSでは/var/log/kube-proxy.logのようなファイルですが、他のOSでは`journalctl`を使用してログにアクセスします。
次のように表示されます。
次に、マスターとの接続など、明らかな失敗をしていないことを確認します。これを行うには、ログを確認する必要があります。ログへのアクセス方法は、ノードのOSに依存します。一部のOSでは/var/log/kube-proxy.logのようなファイルですが、他のOSでは`journalctl`を使用してログにアクセスします。次のように表示されます。
```none
I1027 22:14:53.995134 5063 server.go:200] Running in resource-only container "/kube-proxy"
@@ -483,12 +436,9 @@ I1027 22:14:54.040223 5063 proxier.go:294] Adding new service "kube-system/ku
マスターに接続できないことに関するエラーメッセージが表示された場合、ノードの設定とインストール手順をダブルチェックする必要があります。
`kube-proxy`が正しく実行できない理由の可能性の1つは、必須の`conntrack`バイナリが見つからないことです。
これは、例えばKubernetesをスクラッチからインストールするなど、クラスターのインストール方法に依存して、一部のLinuxシステムで発生する場合があります。
これが該当する場合は、`conntrack`パッケージを手動でインストール(例: Ubuntuでは`sudo apt install conntrack`)する必要があり、その後に再試行する必要があります。
`kube-proxy`が正しく実行できない理由の可能性の1つは、必須の`conntrack`バイナリが見つからないことです。これは、例えばKubernetesをスクラッチからインストールするなど、クラスターのインストール方法に依存して、一部のLinuxシステムで発生する場合があります。これが該当する場合は、`conntrack`パッケージを手動でインストール(例: Ubuntuでは`sudo apt install conntrack`)する必要があり、その後に再試行する必要があります。
kube-proxyは、いくつかのモードのいずれかで実行できます。 上記のログの`Using iptables Proxier`という行は、kube-proxyが「iptables」モードで実行されていることを示しています。
最も一般的な他のモードは「ipvs」です。 古い「ユーザースペース」モードは、主にこれらに置き換えられました。
kube-proxyは、いくつかのモードのいずれかで実行できます。上記のログの`Using iptables Proxier`という行は、kube-proxyが「iptables」モードで実行されていることを示しています。最も一般的な他のモードは「ipvs」です。古い「ユーザースペース」モードは、主にこれらに置き換えられました。
#### Iptables mode
@@ -510,9 +460,7 @@ iptables-save | grep hostnames
-A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -j KUBE-SEP-57KPRZ3JQVENLNBR
```
各サービスのポートごとに、 `KUBE-SERVICES`に1つのルールと1つの` KUBE-SVC- <hash> `チェーンが必要です。
Podエンドポイントごとに、その `KUBE-SVC- <hash>`に少数のルールがあり、少数のルールが含まれる1つの `KUBE-SEP- <hash>`チェーンがあるはずです。
正確なルールは、正確な構成（NodePortとLoadBalancerを含む）に基づいて異なります。
各サービスのポートごとに、`KUBE-SERVICES`に1つのルールと1つの` KUBE-SVC- <hash> `チェーンが必要です。Podエンドポイントごとに、その`KUBE-SVC- <hash>`に少数のルールがあり、少数のルールが含まれる1つの`KUBE-SEP- <hash>`チェーンがあるはずです。正確なルールは、正確な構成(NodePortとLoadBalancerを含む)に基づいて異なります。
#### IPVS mode
@@ -532,12 +480,9 @@ TCP 10.0.1.175:80 rr
...
```
各Serviceの各ポートに加えて、NodePort、External IP、およびLoad Balancer IPに対して、kube-proxyは仮想サーバーを作成します。
Pod endpointごとに、対応する実サーバーが作成されます。
この例では, サービスhostnames(`10.0.1.175:80`) は3つのendpoints(`10.244.0.5:9376`,`10.244.0.6:9376`, `10.244.0.7:9376`)を持っています。
各Serviceの各ポートに加えて、NodePort、External IP、およびLoad Balancer IPに対して、kube-proxyは仮想サーバーを作成します。Pod endpointごとに、対応する実サーバーが作成されます。この例では、サービスhostnames(`10.0.1.175:80`)は3つのendpoints(`10.244.0.5:9376`、`10.244.0.6:9376`、`10.244.0.7:9376`)を持っています。
IPVSプロキシーは、各Serviceアドレス(Cluster IP、External IP、NodePort IP、Load Balancer IPなど)毎の仮想サーバーと、Serviceのエンドポイントが存在する場合に対応する実サーバーを作成します。
この例では、hostnames Service(`10.0.1.175:80`)は3つのエンドポイント(`10.244.0.5:9376`、`10.244.0.6:9376`、`10.244.0.7:9376`)を持ち、上と似た結果が得られるはずです。
IPVSプロキシーは、各Serviceアドレス(Cluster IP、External IP、NodePort IP、Load Balancer IPなど)毎の仮想サーバーと、Serviceのエンドポイントが存在する場合に対応する実サーバーを作成します。この例では、hostnames Service(`10.0.1.175:80`)は3つのエンドポイント(`10.244.0.5:9376`、`10.244.0.6:9376`、`10.244.0.7:9376`)を持ち、上と似た結果が得られるはずです。
#### Userspace mode
@@ -553,7 +498,7 @@ iptables-save | grep hostnames
-A KUBE-PORTALS-HOST -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames:default" -m tcp --dport 80 -j DNAT --to-destination 10.240.115.247:48577
```
サービスの各ポートには2つのルールが必要です（この例では1つだけ）-「KUBE-PORTALS-CONTAINER」と「KUBE-PORTALS-HOST」です。
サービスの各ポートには2つのルールが必要です(この例では1つだけ)-「KUBE-PORTALS-CONTAINER」と「KUBE-PORTALS-HOST」です。
「userspace」モードを使用する必要はほとんどないので、ここでこれ以上時間を費やすことはありません。
@@ -568,11 +513,9 @@ curl 10.0.1.175:80
hostnames-0uton
```
もしこれが失敗し、あなたがuserspaceプロキシーを使用している場合、プロキシーへの直接アクセスを試してみてください。
もしiptablesプロキシーを使用している場合、このセクションはスキップしてください。
もしこれが失敗し、あなたがuserspaceプロキシーを使用している場合、プロキシーへの直接アクセスを試してみてください。もしiptablesプロキシーを使用している場合、このセクションはスキップしてください。
上記の`iptables-save`の出力を振り返り、`kube-proxy`がServiceに使用しているポート番号を抽出します。
上記の例では"48577"です。このポートに接続してください。
上記の`iptables-save`の出力を振り返り、`kube-proxy`がServiceに使用しているポート番号を抽出します。上記の例では"48577"です。このポートに接続してください。
```shell
curl localhost:48577
@@ -589,18 +532,13 @@ Setting endpoints for default/hostnames:default to [10.244.0.5:9376 10.244.0.6:9
これらが表示されない場合は、`-v`フラグを4に設定して`kube-proxy`を再起動してから、再度ログを確認してください。
### エッジケース: PodがService IP経由で自身に到達できない。 {#a-pod-fails-to-reach-itself-via-the-service-ip}
### エッジケース: PodがService IP経由で自身に到達できない {#a-pod-fails-to-reach-itself-via-the-service-ip}
これはありそうに聞こえないかもしれませんが、実際には起こり、動作するはずです。
これはネットワークが"hairpin"トラフィック用に適切に設定されていない場合、通常は`kube-proxy`が`iptables`モードで実行され、Podがブリッジネットワークに接続されている場合に発生します。
`Kubelet`は`hairpin-mode`[フラグ](/docs/admin/kubelet/)を公開します。
これにより、Serviceのエンドポイントが自身のServiceのVIPにアクセスしようとした場合に、自身への負荷分散を可能にします。
`hairpin-mode`フラグは`hairpin-veth`または`promiscuous-bridge`に設定する必要があります。
これはありそうに聞こえないかもしれませんが、実際には起こり、動作するはずです。これはネットワークが"hairpin"トラフィック用に適切に設定されていない場合、通常は`kube-proxy`が`iptables`モードで実行され、Podがブリッジネットワークに接続されている場合に発生します。`Kubelet`は`hairpin-mode`[フラグ](/docs/admin/kubelet/)を公開します。これにより、Serviceのエンドポイントが自身のServiceのVIPにアクセスしようとした場合に、自身への負荷分散を可能にします。`hairpin-mode`フラグは`hairpin-veth`または`promiscuous-bridge`に設定する必要があります。
この問題をトラブルシューティングする一般的な手順は次のとおりです。
* `hairpin-mode`が`hairpin-veth`または`promiscuous-bridge`に設定されていることを確認します。
次のような表示がされるはずです。この例では、`hairpin-mode`は`promiscuous-bridge`に設定されています。
* `hairpin-mode`が`hairpin-veth`または`promiscuous-bridge`に設定されていることを確認します。次のような表示がされるはずです。この例では、`hairpin-mode`は`promiscuous-bridge`に設定されています。
```shell
ps auxw | grep kubelet
@@ -609,20 +547,13 @@ ps auxw | grep kubelet
root 3392 1.1 0.8 186804 65208 ? Sl 00:51 11:11 /usr/local/bin/kubelet --enable-debugging-handlers=true --config=/etc/kubernetes/manifests --allow-privileged=True --v=4 --cluster-dns=10.0.0.10 --cluster-domain=cluster.local --configure-cbr0=true --cgroup-root=/ --system-cgroups=/system --hairpin-mode=promiscuous-bridge --runtime-cgroups=/docker-daemon --kubelet-cgroups=/kubelet --babysit-daemons=true --max-pods=110 --serialize-image-pulls=false --outofdisk-transition-frequency=0
```
* 実際に使われている`hairpin-mode`を確認します。
これを行うには、kubeletログを確認する必要があります。
ログへのアクセス方法は、ノードのOSによって異なります。
一部のOSでは/var/log/kubelet.logなどのファイルですが、他のOSでは`journalctl`を使用してログにアクセスします。
互換性のために、実際に使われている`hairpin-mode`が`--hairpin-mode`フラグと一致しない場合があることに注意してください。
kubelet.logにキーワード`hairpin`を含むログ行があるかどうかを確認してください。
実際に使われている`hairpin-mode`を示す以下のようなログ行があるはずです。
* 実際に使われている`hairpin-mode`を確認します。これを行うには、kubeletログを確認する必要があります。ログへのアクセス方法は、ノードのOSによって異なります。一部のOSでは/var/log/kubelet.logなどのファイルですが、他のOSでは`journalctl`を使用してログにアクセスします。互換性のために、実際に使われている`hairpin-mode`が`--hairpin-mode`フラグと一致しない場合があることに注意してください。kubelet.logにキーワード`hairpin`を含むログ行があるかどうかを確認してください。実際に使われている`hairpin-mode`を示す以下のようなログ行があるはずです。
```none
I0629 00:51:43.648698 3252 kubelet.go:380] Hairpin mode set to "promiscuous-bridge"
```
* 実際に使われている`hairpin-mode`が`hairpin-veth`の場合、`Kubelet`にノードの`/sys`で操作する権限があることを確認します。
すべてが正常に機能している場合、次のようなものが表示されます。
* 実際に使われている`hairpin-mode`が`hairpin-veth`の場合、`Kubelet`にノードの`/sys`で操作する権限があることを確認します。すべてが正常に機能している場合、次のようなものが表示されます。
```shell
for intf in /sys/devices/virtual/net/cbr0/brif/*; do cat $intf/hairpin_mode; done
@@ -634,8 +565,7 @@ for intf in /sys/devices/virtual/net/cbr0/brif/*; do cat $intf/hairpin_mode; don
1
```
実際に使われている`hairpin-mode`が`promiscuous-bridge`の場合、`Kubelet`にノード上のLinuxブリッジを操作する権限があることを確認してください。
`cbr0`ブリッジが使用され適切に構成されている場合、以下が表示されます。
実際に使われている`hairpin-mode`が`promiscuous-bridge`の場合、`Kubelet`にノード上のLinuxブリッジを操作する権限があることを確認してください。`cbr0`ブリッジが使用され適切に構成されている場合、以下が表示されます。
```shell
ifconfig cbr0 |grep PROMISC
@@ -648,15 +578,9 @@ UP BROADCAST RUNNING PROMISC MULTICAST MTU:1460 Metric:1
## 助けを求める
ここまでたどり着いたということは、とてもおかしなことが起こっています。
Serviceは実行中で、Endpointsがあり、Podは実際にサービスを提供しています。
DNSは動作していて、`kube-proxy`も誤動作していないようです。
それでも、あなたのServiceは機能していません。
おそらく私たちにお知らせ頂いた方がよいでしょう。調査をお手伝いします！
ここまでたどり着いたということは、とてもおかしなことが起こっています。Serviceは実行中で、Endpointsがあり、Podは実際にサービスを提供しています。DNSは動作していて、`kube-proxy`も誤動作していないようです。それでも、あなたのServiceは機能していません。おそらく私たちにお知らせ頂いた方がよいでしょう。調査をお手伝いします！
[Slack](/docs/troubleshooting/#slack)または
[Forum](https://discuss.kubernetes.io)または
[GitHub](https://github.com/kubernetes/kubernetes)でお問い合わせください。
[Slack](/docs/troubleshooting/#slack)、[Forum](https://discuss.kubernetes.io)または[GitHub](https://github.com/kubernetes/kubernetes)でお問い合わせください。
content/ja/docs/tasks/manage-gpus/scheduling-gpus.md
+184
View File
@@ -0,0 +1,184 @@
---
content_type: concept
title: GPUのスケジューリング
description: クラスター内のノードのリソースとしてGPUを設定してスケジューリングします
---
<!-- overview -->
{{< feature-state state="beta" for_k8s_version="v1.10" >}}
Kubernetesには、複数ノードに搭載されたAMDおよびNVIDIAのGPU(graphical processing unit)を管理するための**実験的な**サポートが含まれています。
このページでは、異なるバージョンのKubernetesを横断してGPUを使用する方法と、現時点での制限について説明します。
<!-- body -->
## デバイスプラグインを使用する
Kubernetesでは、GPUなどの特別なハードウェアの機能にPodがアクセスできるようにするために、{{< glossary_tooltip text="デバイスプラグイン" term_id="device-plugin" >}}が実装されています。
管理者として、ノード上に対応するハードウェアベンダーのGPUドライバーをインストールして、以下のような対応するGPUベンダーのデバイスプラグインを実行する必要があります。
* [AMD](#deploying-amd-gpu-device-plugin)
* [NVIDIA](#deploying-nvidia-gpu-device-plugin)
上記の条件を満たしていれば、Kubernetesは`amd.com/gpu`または`nvidia.com/gpu`をスケジュール可能なリソースとして公開します。
これらのGPUをコンテナから使用するには、`cpu`や`memory`をリクエストするのと同じように`<vendor>.com/gpu`というリソースをリクエストするだけです。ただし、GPUを使用するときにはリソースのリクエストの指定方法にいくつか制限があります。
- GPUは`limits`セクションでのみ指定されることが想定されている。この制限は、次のことを意味します。
* Kubernetesはデフォルトでlimitの値をrequestの値として使用するため、GPUの`requests`を省略して`limits`を指定できる。
* GPUを`limits`と`requests`の両方で指定できるが、これら2つの値は等しくなければならない。
* GPUの`limits`を省略して`requests`だけを指定することはできない。
- コンテナ(およびPod)はGPUを共有しない。GPUのオーバーコミットは起こらない。
- 各コンテナは1つ以上のGPUをリクエストできる。1つのGPUの一部だけをリクエストすることはできない。
以下に例を示します。
```yaml
apiVersion: v1
kind: Pod
metadata:
name: cuda-vector-add
spec:
restartPolicy: OnFailure
containers:
- name: cuda-vector-add
# https://github.com/kubernetes/kubernetes/blob/v1.7.11/test/images/nvidia-cuda/Dockerfile
image: "k8s.gcr.io/cuda-vector-add:v0.1"
resources:
limits:
nvidia.com/gpu: 1 # 1 GPUをリクエストしています
```
### AMDのGPUデバイスプラグインをデプロイする {#deploying-amd-gpu-device-plugin}
[AMD公式のGPUデバイスプラグイン](https://github.com/RadeonOpenCompute/k8s-device-plugin)には以下の要件があります。
- Kubernetesのノードに、AMDのGPUのLinuxドライバーがあらかじめインストール済みでなければならない。
クラスターが起動して上記の要件が満たされれば、以下のコマンドを実行することでAMDのデバイスプラグインをデプロイできます。
```shell
kubectl create -f https://raw.githubusercontent.com/RadeonOpenCompute/k8s-device-plugin/v1.10/k8s-ds-amdgpu-dp.yaml
```
このサードパーティーのデバイスプラグインに関する問題は、[RadeonOpenCompute/k8s-device-plugin](https://github.com/RadeonOpenCompute/k8s-device-plugin)で報告できます。
### NVIDIAのGPUデバイスプラグインをデプロイする {#deploying-nvidia-gpu-device-plugin}
現在、NVIDIAのGPU向けのデバイスプラグインの実装は2種類あります。
#### NVIDIA公式のGPUデバイスプラグイン
[NVIDIA公式のGPUデバイスプラグイン](https://github.com/NVIDIA/k8s-device-plugin)には以下の要件があります。
- Kubernetesのノードに、NVIDIAのドライバーがあらかじめインストール済みでなければならない。
- Kubernetesのノードに、[nvidia-docker 2.0](https://github.com/NVIDIA/nvidia-docker)があらかじめインストール済みでなければならない。
- KubeletはコンテナランタイムにDockerを使用しなければならない。
- runcの代わりにDockerの[デフォルトランタイム](https://github.com/NVIDIA/k8s-device-plugin#preparing-your-gpu-nodes)として、`nvidia-container-runtime`を設定しなければならない。
- NVIDIAのドライバーのバージョンが次の条件を満たさなければならない ~= 384.81。
クラスターが起動して上記の要件が満たされれば、以下のコマンドを実行することでNVIDIAのデバイスプラグインがデプロイできます。
```shell
kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/1.0.0-beta4/nvidia-device-plugin.yml
```
このサードパーティーのデバイスプラグインに関する問題は、[NVIDIA/k8s-device-plugin](https://github.com/NVIDIA/k8s-device-plugin)で報告できます。
#### GCEで使用されるNVIDIAのGPUデバイスプラグイン
[GCEで使用されるNVIDIAのGPUデバイスプラグイン](https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/cmd/nvidia_gpu)は、nvidia-dockerを必要としないため、KubernetesのContainer Runtime Interface(CRI)と互換性のある任意のコンテナランタイムで動作するはずです。このデバイスプラグインは[Container-Optimized OS](https://cloud.google.com/container-optimized-os/)でテストされていて、1.9以降ではUbuntu向けの実験的なコードも含まれています。
以下のコマンドを実行すると、NVIDIAのドライバーとデバイスプラグインをインストールできます。
```shell
# NVIDIAドライバーをContainer-Optimized OSにインストールする
kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/stable/daemonset.yaml
# NVIDIAドライバーをUbuntuにインストールする(実験的)
kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/stable/nvidia-driver-installer/ubuntu/daemonset.yaml
# デバイスプラグインをインストールする
kubectl create -f https://raw.githubusercontent.com/kubernetes/kubernetes/release-1.14/cluster/addons/device-plugins/nvidia-gpu/daemonset.yaml
```
このサードパーティーのデバイスプラグインの使用やデプロイに関する問題は、[GoogleCloudPlatform/container-engine-accelerators](https://github.com/GoogleCloudPlatform/container-engine-accelerators)で報告できます。
Googleは、GKE上でNVIDIAのGPUを使用するための[手順](https://cloud.google.com/kubernetes-engine/docs/how-to/gpus)も公開しています。
## 異なる種類のGPUを搭載するクラスター
クラスター上の別のノードに異なる種類のGPUが搭載されている場合、[NodeラベルとNodeセレクター](/docs/tasks/configure-pod-container/assign-pods-nodes/)を使用することで、Podを適切なノードにスケジューリングできます。
以下に例を示します。
```shell
# アクセラレーターを搭載したノードにラベルを付けます。
kubectl label nodes <node-with-k80> accelerator=nvidia-tesla-k80
kubectl label nodes <node-with-p100> accelerator=nvidia-tesla-p100
```
## 自動的なNodeラベルの付加 {#node-labeller}
AMDのGPUデバイスを使用している場合、[Node Labeller](https://github.com/RadeonOpenCompute/k8s-device-plugin/tree/master/cmd/k8s-node-labeller)をデプロイできます。Node Labellerは{{< glossary_tooltip text="コントローラー" term_id="controller" >}}の1種で、GPUデバイスのプロパティを持つノードに自動的にラベルを付けてくれます。
現在は、このコントローラーは以下のプロパティに基づいてラベルを追加できます。
* デバイスID(-device-id)
* VRAMのサイズ(-vram)
* SIMDの数(-simd-count)
* Compute Unitの数(-cu-count)
* ファームウェアとフィーチャーのバージョン(-firmware)
* 2文字の頭字語で表されたGPUファミリー(-family)
* SI - Southern Islands
* CI - Sea Islands
* KV - Kaveri
* VI - Volcanic Islands
* CZ - Carrizo
* AI - Arctic Islands
* RV - Raven
```shell
kubectl describe node cluster-node-23
```
```
Name: cluster-node-23
Roles: <none>
Labels: beta.amd.com/gpu.cu-count.64=1
beta.amd.com/gpu.device-id.6860=1
beta.amd.com/gpu.family.AI=1
beta.amd.com/gpu.simd-count.256=1
beta.amd.com/gpu.vram.16G=1
beta.kubernetes.io/arch=amd64
beta.kubernetes.io/os=linux
kubernetes.io/hostname=cluster-node-23
Annotations: kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock
node.alpha.kubernetes.io/ttl: 0
…
```
Node Labellerを使用すると、GPUの種類をPodのspec内で指定できます。
```yaml
apiVersion: v1
kind: Pod
metadata:
name: cuda-vector-add
spec:
restartPolicy: OnFailure
containers:
- name: cuda-vector-add
# https://github.com/kubernetes/kubernetes/blob/v1.7.11/test/images/nvidia-cuda/Dockerfile
image: "k8s.gcr.io/cuda-vector-add:v0.1"
resources:
limits:
nvidia.com/gpu: 1
nodeSelector:
accelerator: nvidia-tesla-p100 # または nvidia-tesla-k80 など
```
これにより、指定した種類のGPUを搭載したノードにPodがスケジューリングされることを保証できます。
content/ja/docs/tasks/run-application/force-delete-stateful-set-pod.md
+3 -3
View File
@@ -21,7 +21,7 @@ weight: 70
StatefulSetの通常の操作では、StatefulSet Podを強制的に削除する必要は**まったく**ありません。StatefulSetコントローラーは、StatefulSetのメンバーの作成、スケール、削除を行います。それは序数0からN-1までの指定された数のPodが生きていて準備ができていることを保証しようとします。StatefulSetは、クラスター内で実行されている特定のIDを持つ最大1つのPodがいつでも存在することを保証します。これは、StatefulSetによって提供される*最大1つの*セマンティクスと呼ばれます。
手動による強制削除は、StatefulSetに固有の最大1つのセマンティクスに違反する可能性があるため、慎重に行う必要があります。StatefulSetを使用して、安定したネットワークIDと安定した記憶域を必要とする分散型およびクラスター型アプリケーションを実行できます。これらのアプリケーションは、固定IDを持つ固定数のメンバーのアンサンブルに依存する構成を持つことがよくあります。同じIDを持つ複数のメンバーを持つことは悲惨なことになり、データの損失につながる可能性があります（例：定足数ベースのシステムでのスプリットブレインシナリオ）。
手動による強制削除は、StatefulSetに固有の最大1つのセマンティクスに違反する可能性があるため、慎重に行う必要があります。StatefulSetを使用して、安定したネットワークIDと安定した記憶域を必要とする分散型およびクラスター型アプリケーションを実行できます。これらのアプリケーションは、固定IDを持つ固定数のメンバーのアンサンブルに依存する構成を持つことがよくあります。同じIDを持つ複数のメンバーを持つことは悲惨なことになり、データの損失につながる可能性があります(例：定足数ベースのシステムでのスプリットブレインシナリオ)。
## Podの削除
@@ -33,13 +33,13 @@ kubectl delete pods <pod>
上記がグレースフルターミネーションにつながるためには、`pod.Spec.TerminationGracePeriodSeconds`に0を指定しては**いけません**。`pod.Spec.TerminationGracePeriodSeconds`を0秒に設定することは安全ではなく、StatefulSet Podには強くお勧めできません。グレースフル削除は安全で、kubeletがapiserverから名前を削除する前に[Podが適切にシャットダウンする](/ja/docs/concepts/workloads/pods/pod/#termination-of-pods)ことを保証します。
Kubernetes（バージョン1.5以降）は、Nodeにアクセスできないという理由だけでPodを削除しません。到達不能なNodeで実行されているPodは、[タイムアウト](/docs/admin/node/#node-condition)の後に`Terminating`または`Unknown`状態になります。到達不能なNode上のPodをユーザーが適切に削除しようとすると、Podはこれらの状態に入ることもあります。そのような状態のPodをapiserverから削除することができる唯一の方法は以下の通りです:
Kubernetes(バージョン1.5以降)は、Nodeにアクセスできないという理由だけでPodを削除しません。到達不能なNodeで実行されているPodは、[タイムアウト](/docs/admin/node/#node-condition)の後に`Terminating`または`Unknown`状態になります。到達不能なNode上のPodをユーザーが適切に削除しようとすると、Podはこれらの状態に入ることもあります。そのような状態のPodをapiserverから削除することができる唯一の方法は以下の通りです:
* (ユーザーまたは[Node Controller](/docs/admin/node)によって)Nodeオブジェクトが削除されます。<br/>
* 応答していないNodeのkubeletが応答を開始し、Podを終了してapiserverからエントリーを削除します。<br/>
* ユーザーによりPodを強制削除します。
推奨されるベストプラクティスは、1番目または2番目のアプローチを使用することです。Nodeが死んでいることが確認された（例えば、ネットワークから恒久的に切断された、電源が切られたなど）場合、Nodeオブジェクトを削除します。Nodeがネットワークパーティションに苦しんでいる場合は、これを解決するか、解決するのを待ちます。パーティションが回復すると、kubeletはPodの削除を完了し、apiserverでその名前を解放します。
推奨されるベストプラクティスは、1番目または2番目のアプローチを使用することです。Nodeが死んでいることが確認された(例えば、ネットワークから恒久的に切断された、電源が切られたなど)場合、Nodeオブジェクトを削除します。Nodeがネットワークパーティションに苦しんでいる場合は、これを解決するか、解決するのを待ちます。パーティションが回復すると、kubeletはPodの削除を完了し、apiserverでその名前を解放します。
通常、PodがNode上で実行されなくなるか、管理者によってそのNodeが削除されると、システムは削除を完了します。あなたはPodを強制的に削除することでこれを無効にすることができます。
content/ja/docs/tasks/service-catalog/_index.md
Executable
+6
View File
@@ -0,0 +1,6 @@
---
title: "サービスカタログ"
description: サービスカタログ拡張APIをインストールする
weight: 150
---
content/ja/docs/tasks/service-catalog/install-service-catalog-using-sc.md
+68
View File
@@ -0,0 +1,68 @@
---
title: SCを使用したサービスカタログのインストール
content_type: task
---
<!-- overview -->
{{< glossary_definition term_id="service-catalog" length="all" prepend="サービスカタログは" >}}
GCPの[Service Catalog Installer](https://github.com/GoogleCloudPlatform/k8s-service-catalog#installation)ツールを使うと、Kubernetesクラスター上にサービスカタログを簡単にインストール・アンインストールして、Google Cloudのプロジェクトに紐付けることもできます。
サービスカタログ自体は、Google Cloudだけではなく、どのような種類のマネージドサービスでも動作します。
## {{% heading "prerequisites" %}}
* [サービスカタログ](/docs/concepts/service-catalog/)の基本概念を理解してください。
* [Go 1.6+](https://golang.org/dl/)をインストールして、`GOPATH`を設定してください。
* SSLに関するファイルを生成するために必要な[cfssl](https://github.com/cloudflare/cfssl)ツールをインストールしてください。
* サービスカタログを使用するには、Kubernetesクラスターのバージョンが1.7以降である必要があります。
* [kubectlのインストールおよびセットアップ](/ja/docs/tasks/tools/install-kubectl/)を参考に、v1.7以降のkubectlをインストールし、設定を行ってください。
* サービスカタログをインストールするためには、kubectlのユーザーが*cluster-admin*ロールにバインドされている必要があります。正しくバインドされていることを確認するには、次のコマンドを実行します。
kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=<user-name>
<!-- steps -->
## ローカル環境に`sc`をインストールする
インストーラーは、ローカルのコンピューター上で`sc`と呼ばれるCLIツールとして実行します。
`go get`を使用してインストールします。
```shell
go get github.com/GoogleCloudPlatform/k8s-service-catalog/installer/cmd/sc
```
これで、`sc`が`GOPATH/bin`ディレクトリー内にインストールされたはずです。
## Kubernetesクラスターにサービスカタログをインストールする
まず、すべての依存関係がインストールされていることを確認します。次のコマンドを実行してください。
```shell
sc check
```
チェックが成功したら、次のように表示されるはずです。
```
Dependency check passed. You are good to go.
```
次に、バックアップに使用したい`storageclass`を指定して、installコマンドを実行します。
```shell
sc install --etcd-backup-storageclass "standard"
```
## サービスカタログのアンインストール
Kubernetesクラスターからサービスカタログをアンインストールしたい場合は、`sc`ツールを使って次のコマンドを実行します。
```shell
sc uninstall
```
## {{% heading "whatsnext" %}}
* [サービスブローカーのサンプル](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers)を読む。
* [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog)プロジェクトを探索する。
content/ja/docs/tasks/tools/install-kubectl.md
+11 -11
View File
@@ -5,7 +5,7 @@ weight: 10
card:
name: tasks
weight: 20
title: Install kubectl
title: kubectlのインストール
---
<!-- overview -->
@@ -143,7 +143,7 @@ macOSで[Homebrew](https://brew.sh/)パッケージマネージャーを使用
1. インストールコマンドを実行してください:
```
brew install kubectl
brew install kubectl
```
または
@@ -186,7 +186,7 @@ macOSで[MacPorts](https://macports.org/)パッケージマネージャーを使
curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe
```
最新の安定版を入手する際は（たとえばスクリプトで使用する場合）、[https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt)を参照してください。
最新の安定版を入手する際は(たとえばスクリプトで使用する場合)、[https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt)を参照してください。
2. バイナリをPATHに追加します
3. `kubectl`のバージョンがダウンロードしたものと同じであることを確認してください:
@@ -202,7 +202,7 @@ macOSで[MacPorts](https://macports.org/)パッケージマネージャーを使
Windowsで[Powershell Gallery](https://www.powershellgallery.com/)パッケージマネージャーを使用していれば、Powershellでkubectlをインストールおよびアップデートすることもできます。
1. インストールコマンドを実行してください（必ず`DownloadLocation`を指定してください）:
1. インストールコマンドを実行してください(必ず`DownloadLocation`を指定してください):
```
Install-Script -Name install-kubectl -Scope CurrentUser -Force
@@ -301,7 +301,7 @@ URLのレスポンスが表示されている場合は、kubectlはクラスタ
The connection to the server <server-name:port> was refused - did you specify the right host or port?
```
たとえば、ラップトップ上（ローカル環境）でKubernetesクラスターを起動するような場合、Minikubeなどのツールを最初にインストールしてから、上記のコマンドを再実行する必要があります。
たとえば、ラップトップ上(ローカル環境)でKubernetesクラスターを起動するような場合、Minikubeなどのツールを最初にインストールしてから、上記のコマンドを再実行する必要があります。
kubectl cluster-infoがURLレスポンスを返したにもかかわらずクラスターにアクセスできない場合は、次のコマンドで設定が正しいことを確認してください:
@@ -315,7 +315,7 @@ kubectl cluster-info dump
kubectlはBashおよびZshの自動補完を提供しています。これにより、入力を大幅に削減することができます。
以下にBash（LinuxとmacOSの違いも含む）およびZshの自動補完の設定手順を示します。
以下にBash(LinuxとmacOSの違いも含む)およびZshの自動補完の設定手順を示します。
{{< tabs name="kubectl_autocompletion" >}}
@@ -325,11 +325,11 @@ kubectlはBashおよびZshの自動補完を提供しています。これによ
Bashにおけるkubectlの補完スクリプトは`kubectl completion bash`コマンドで生成できます。シェル内で補完スクリプトをsourceすることでkubectlの自動補完が有効になります。
ただし、補完スクリプトは[**bash-completion**](https://github.com/scop/bash-completion)に依存しているため、このソフトウェアを最初にインストールしておく必要があります（`type _init_completion`を実行することで、bash-completionがすでにインストールされていることを確認できます）。
ただし、補完スクリプトは[**bash-completion**](https://github.com/scop/bash-completion)に依存しているため、このソフトウェアを最初にインストールしておく必要があります(`type _init_completion`を実行することで、bash-completionがすでにインストールされていることを確認できます)。
### bash-completionをインストールする
bash-completionは多くのパッケージマネージャーから提供されています（[こちら](https://github.com/scop/bash-completion#installation)を参照してください）。`apt-get install bash-completion`または`yum install bash-completion`などでインストールできます。
bash-completionは多くのパッケージマネージャーから提供されています([こちら](https://github.com/scop/bash-completion#installation)を参照してください)。`apt-get install bash-completion`または`yum install bash-completion`などでインストールできます。
上記のコマンドでbash-completionの主要スクリプトである`/usr/share/bash-completion/bash_completion`が作成されます。パッケージマネージャーによっては、このファイルを`~/.bashrc`にて手動でsourceする必要があります。
@@ -382,7 +382,7 @@ Bashにおけるkubectlの補完スクリプトは`kubectl completion bash`コ
ただし、補完スクリプトは[**bash-completion**](https://github.com/scop/bash-completion)に依存しているため、事前にインストールする必要があります。
{{< warning>}}
bash-completionにはv1とv2のバージョンがあり、v1はBash 3.2（macOSのデフォルト）用で、v2はBash 4.1以降向けです。kubectlの補完スクリプトはbash-completionのv1とBash 3.2では正しく**動作しません**。**bash-completion v2**および**Bash 4.1**が必要になります。したがって、macOSで正常にkubectlの補完を使用するには、Bash 4.1以降をインストールする必要があります([*手順*](https://itnext.io/upgrading-bash-on-macos-7138bd1066ba))。以下の手順では、Bash4.1以降（Bashのバージョンが4.1またはそれより新しいことを指します）を使用することを前提とします。
bash-completionにはv1とv2のバージョンがあり、v1はBash 3.2(macOSのデフォルト)用で、v2はBash 4.1以降向けです。kubectlの補完スクリプトはbash-completionのv1とBash 3.2では正しく**動作しません**。**bash-completion v2**および**Bash 4.1**が必要になります。したがって、macOSで正常にkubectlの補完を使用するには、Bash 4.1以降をインストールする必要があります([*手順*](https://itnext.io/upgrading-bash-on-macos-7138bd1066ba))。以下の手順では、Bash4.1以降(Bashのバージョンが4.1またはそれより新しいことを指します)を使用することを前提とします。
{{< /warning >}}
### bashのアップグレード
@@ -410,7 +410,7 @@ Homebrewは通常、`/usr/local/bin/bash`にインストールします。
### bash-completionをインストールする
{{< note >}}
前述のとおり、この手順ではBash 4.1以降であることが前提のため、bash-completion v2をインストールすることになります（これとは逆に、Bash 3.2およびbash-completion v1の場合ではkubectlの補完は動作しません）。
前述のとおり、この手順ではBash 4.1以降であることが前提のため、bash-completion v2をインストールすることになります(これとは逆に、Bash 3.2およびbash-completion v1の場合ではkubectlの補完は動作しません)。
{{< /note >}}
`type _init_completion`を実行することで、bash-completionがすでにインストールされていることを確認できます。ない場合は、Homebrewを使用してインストールすることもできます:
@@ -452,7 +452,7 @@ export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d"
echo 'complete -F __start_kubectl k' >>~/.bashrc
```
- kubectlをHomwbrewでインストールした場合（[前述](#homebrewを使用してmacosへインストールする)のとおり）、kubectlの補完スクリプトはすでに`/usr/local/etc/bash_completion.d/kubectl`に格納されているでしょう。この場合、なにも操作する必要はありません。
- kubectlをHomwbrewでインストールした場合([前述](#homebrewを使用してmacosへインストールする)のとおり)、kubectlの補完スクリプトはすでに`/usr/local/etc/bash_completion.d/kubectl`に格納されているでしょう。この場合、なにも操作する必要はありません。
{{< note >}}
Homebrewでインストールしたbash-completion v2は`BASH_COMPLETION_COMPAT_DIR`ディレクトリ内のすべてのファイルをsourceするため、後者の2つの方法が機能します。
content/ja/docs/tasks/tools/install-minikube.md
+1 -1
View File
@@ -29,7 +29,7 @@ grep -E --color 'vmx|svm' /proc/cpuinfo
```
sysctl -a | grep -E --color 'machdep.cpu.features|VMX'
```
出力に`VMX`が表示されている場合（色付けされているはずです）、VT-x機能がマシンで有効になっています。
出力に`VMX`が表示されている場合(色付けされているはずです)、VT-x機能がマシンで有効になっています。
{{% /tab %}}
{{% tab name="Windows" %}}
content/ja/docs/tutorials/configuration/configure-redis-using-configmap.md
+1 -1
View File
@@ -89,7 +89,7 @@ pod/redis 1/1 Running 0 52s
`kubectl exec`を使ってPodに入り、`redis-cli`ツールを実行して設定が正しく適用されたことを確認してください:
```shell
kubectl exec -it redis redis-cli
kubectl exec -it redis -- redis-cli
127.0.0.1:6379> CONFIG GET maxmemory
1) "maxmemory"
2) "2097152"