Merge pull request #22772 from kubernetes/dev-1.17-ja.3
Third Japanese l10n work for release-1.17
This commit is contained in:
Kubernetes Prow Robot
+112
@@ -0,0 +1,112 @@
|
||||
---
|
||||
title: クラスターで実行されているすべてのコンテナイメージを一覧表示する
|
||||
content_type: task
|
||||
weight: 100
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
このページでは、kubectlを使用して、クラスターで実行されているPodのすべてのコンテナイメージを一覧表示する方法を説明します。
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
この演習では、kubectlを使用してクラスターで実行されているすべてのPodを取得し、出力をフォーマットしてそれぞれのコンテナの一覧を取得します。
|
||||
|
||||
## すべての名前空間のコンテナイメージを一覧表示する {#list-all-container-images-in-all-namespaces}
|
||||
|
||||
- `kubectl get pods --all-namespaces`を使用して、すべての名前空間のPodを取得します
|
||||
- `-o jsonpath={.. image}`を使用して、コンテナイメージ名のリストのみが含まれるように出力をフォーマットします。これは、返されたjsonの`image`フィールドを再帰的に解析します。
|
||||
- jsonpathの使い方については、[jsonpathリファレンス](/docs/user-guide/jsonpath/)を参照してください。
|
||||
- `tr`、`sort`、`uniq`などの標準ツールを使用して出力をフォーマットします。
|
||||
- `tr`を使用してスペースを改行に置換します。
|
||||
- `sort`を使用して結果を並べ替えます。
|
||||
- `uniq`を使用してイメージ数を集計します。
|
||||
|
||||
```sh
|
||||
kubectl get pods --all-namespaces -o jsonpath="{..image}" |\
|
||||
tr -s '[[:space:]]' '\n' |\
|
||||
sort |\
|
||||
uniq -c
|
||||
```
|
||||
|
||||
上記のコマンドは、返されるすべてのアイテムについて、`image`という名前のすべてのフィールドを再帰的に返します。
|
||||
|
||||
別の方法として、Pod内のimageフィールドへの絶対パスを使用することができます。これにより、フィールド名が繰り返されている場合でも正しいフィールドが取得されます。多くのフィールドは与えられたアイテム内で`name`と呼ばれます:
|
||||
|
||||
```sh
|
||||
kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}"
|
||||
```
|
||||
|
||||
jsonpathは次のように解釈されます:
|
||||
|
||||
- `.items[*]`: 各戻り値
|
||||
- `.spec`: 仕様の取得
|
||||
- `.containers[*]`: 各コンテナ
|
||||
- `.image`: イメージの取得
|
||||
|
||||
{{< note >}}
|
||||
例えば`kubectl get pod nginx`のように名前を指定して単一のPodを取得する場合、アイテムのリストではなく単一のPodが返されるので、パスの`.items[*]`部分は省略してください。
|
||||
{{< /note >}}
|
||||
|
||||
## Podごとにコンテナイメージを一覧表示する {#list-container-images-by-pod}
|
||||
|
||||
`range`を使用して要素を個別に繰り返し処理することにより、フォーマットをさらに制御できます。
|
||||
|
||||
```sh
|
||||
kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
|
||||
sort
|
||||
```
|
||||
|
||||
## Podのラベルを使用してコンテナイメージ一覧をフィルタリングする {#list-container-images-filtering-by-pod-namespace}
|
||||
|
||||
特定のラベルに一致するPodのみを対象とするには、-lフラグを使用します。以下は、`app=nginx`に一致するラベルを持つPodのみに一致します。
|
||||
|
||||
```sh
|
||||
kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx
|
||||
```
|
||||
|
||||
## Podの名前空間でコンテナイメージ一覧をフィルタリングする {#list-container-images-filtering-by-pod-namespace}
|
||||
|
||||
特定の名前空間のPodのみを対象とするには、namespaceフラグを使用します。以下は`kube-system`名前空間のPodのみに一致します。
|
||||
|
||||
```sh
|
||||
kubectl get pods --namespace kube-system -o jsonpath="{..image}"
|
||||
```
|
||||
|
||||
## jsonpathの代わりにgo-templateを使用してコンテナイメージを一覧表示する {#list-container-images-using-a-go-template-instead-of-jsonpath}
|
||||
|
||||
jsonpathの代わりに、kubectlは[go-templates](https://golang.org/pkg/text/template/)を使用した出力のフォーマットをサポートしています:
|
||||
|
||||
|
||||
```sh
|
||||
kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{range .spec.containers}}{{.image}} {{end}}{{end}}"
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
### 参照
|
||||
|
||||
* [jsonpath](/docs/user-guide/jsonpath/)参照ガイド
|
||||
* [Go template](https://golang.org/pkg/text/template/)参照ガイド
|
||||
|
||||
|
||||
|
||||
|
||||
+1
-1
@@ -23,7 +23,7 @@ weight: 60
|
||||
## {{% heading "objectives" %}}
|
||||
|
||||
|
||||
* 2つのHellow Worldアプリケーションを稼働させる。
|
||||
* 2つのHello Worldアプリケーションを稼働させる。
|
||||
* Nodeのポートを公開するServiceオブジェクトを作成する。
|
||||
* 稼働しているアプリケーションにアクセスするためにServiceオブジェクトを使用する。
|
||||
|
||||
|
||||
@@ -92,12 +92,12 @@ Kubeconfigの認証方法は、外部IDプロバイダーやx509証明書ベー
|
||||
|
||||
例:
|
||||
|
||||
```conf
|
||||
release=1.0
|
||||
tier=frontend
|
||||
environment=pod
|
||||
track=stable
|
||||
```
|
||||
```conf
|
||||
release=1.0
|
||||
tier=frontend
|
||||
environment=pod
|
||||
track=stable
|
||||
```
|
||||
|
||||
- **Namespace**: Kubernetesは、同じ物理クラスターを基盤とする複数の仮想クラスターをサポートしています。これらの仮想クラスタは[名前空間](/docs/tasks/administer-cluster/namespaces/) と呼ばれます。これにより、リソースを論理的に名前のついたグループに分割することができます。
|
||||
|
||||
|
||||
@@ -0,0 +1,79 @@
|
||||
---
|
||||
title: サービスディスカバリーにCoreDNSを使用する
|
||||
min-kubernetes-server-version: v1.9
|
||||
content_type: task
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
このページでは、CoreDNSのアップグレードプロセスと、kube-dnsの代わりにCoreDNSをインストールする方法を説明します。
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## CoreDNSについて {#about-coredns}
|
||||
|
||||
[CoreDNS](https://coredns.io)は、KubernetesクラスターDNSとして稼働させることができる柔軟で拡張可能なDNSサーバーです。Kubernetesと同様に、CoreDNSプロジェクトは{{< glossary_tooltip text="CNCF" term_id="cncf" >}}によってホストされています。
|
||||
|
||||
既存のデプロイでkube-dnsを置き換えるか、クラスターのデプロイとアップグレードを代行してくれるkubeadmのようなツールを使用することで、クラスターでkube-dnsの代わりにCoreDNSを使用することができます。
|
||||
|
||||
|
||||
## CoreDNSのインストール {#installing-coredns}
|
||||
|
||||
kube-dnsの手動デプロイや置き換えについては、[CoreDNS GitHub project](https://github.com/coredns/deployment/tree/master/kubernetes)のドキュメントを参照してください。
|
||||
|
||||
## CoreDNSへの移行 {#migrating-to-coredns}
|
||||
|
||||
### kubeadmを使用した既存のクラスターのアップグレード {#upgrading-an-existing-cluster-with-kubeadm}
|
||||
|
||||
Kubernetesバージョン1.10以降では、`kube-dns`を使用しているクラスターを`kubeadm`を使用してアップグレードするときに、CoreDNSに移行することもできます。この場合、`kubeadm`は、`kube-dns` ConfigMapをベースにしてCoreDNS設定("Corefile")を生成し、フェデレーション、スタブドメイン、および上流のネームサーバーの設定を保持します。
|
||||
|
||||
kube-dnsからCoreDNSに移行する場合は、アップグレード時に必ず`CoreDNS`フィーチャーゲートを`true`に設定してください。たとえば、`v1.11.0`のアップグレードは次のようになります:
|
||||
```
|
||||
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が稼働したら、カスタマイズを再適用できます。
|
||||
|
||||
Kubernetesバージョン1.11以降でCoreDNSを実行している場合、アップグレード中、既存のCorefileは保持されます。
|
||||
|
||||
|
||||
### kubeadmを使用してCoreDNSの代わりにkube-dnsをインストールする {#installing-kube-dns-instead-of-coredns-with-kubeadm}
|
||||
|
||||
{{< note >}}
|
||||
Kubernetes 1.11では、CoreDNSは一般利用可能(GA)にアップグレードされ、デフォルトでインストールされます。
|
||||
{{< /note >}}
|
||||
|
||||
1.13以前のバージョンにkube-dnsをインストールするには、`CoreDNS`フィーチャーゲートの値を`false`に設定します:
|
||||
|
||||
```
|
||||
kubeadm init --feature-gates=CoreDNS=false
|
||||
```
|
||||
|
||||
バージョン1.13以降の場合は、[こちら](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon)に記載されているガイドに従ってください。
|
||||
|
||||
## CoreDNSのアップグレード {#upgrading-coredns}
|
||||
|
||||
CoreDNSはv1.9以降のKubernetesで使用できます。Kubernetesに同梱されているCoreDNSのバージョンと、CoreDNSに加えられた変更は[こちら](https://github.com/coredns/deployment/blob/master/kubernetes/CoreDNS-k8s_version.md)で確認できます。
|
||||
|
||||
CoreDNSだけをアップグレードしたい場合や、独自のカスタムイメージを使用したい場合は、CoreDNSを手動でアップグレードすることができます。スムーズなアップグレードのために役立つ[ガイドラインとウォークスルー](https://github.com/coredns/deployment/blob/master/kubernetes/Upgrading_CoreDNS.md)が用意されています。
|
||||
|
||||
## CoreDNSのチューニング {#tuning-coredns}
|
||||
|
||||
リソース使用率が問題になる場合は、CoreDNSの設定を調整すると役立つ場合があります。詳細は、[CoreDNSのスケーリングに関するドキュメント](https://github.com/coredns/deployment/blob/master/kubernetes/Scaling_CoreDNS.md)を参照してください。
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
[CoreDNS](https://coredns.io)は、`Corefile`を変更することで、kube-dnsよりも多くのユースケースをサポートするように設定することができます。詳細は[CoreDNSサイト](https://coredns.io/2017/05/08/custom-dns-entries-for-kubernetes/)を参照してください。
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,169 @@
|
||||
---
|
||||
title: 拡張リソースをNodeにアドバタイズする
|
||||
content_type: task
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
このページでは、Nodeに対して拡張リソースを指定する方法を説明します。拡張リソースを利用すると、Kubernetesにとって未知のノードレベルのリソースをクラスター管理者がアドバタイズできるようになります。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Nodeの名前を取得する
|
||||
|
||||
```shell
|
||||
kubectl get nodes
|
||||
```
|
||||
|
||||
この練習で使いたいNodeを1つ選んでください。
|
||||
|
||||
## Nodeの1つで新しい拡張リソースをアドバタイズする
|
||||
|
||||
Node上の新しい拡張リソースをアドバタイズするには、HTTPのPATCHリクエストをKubernetes APIサーバーに送ります。たとえば、Nodeの1つに4つのドングルが接続されているとします。以下に、4つのドングルリソースをNodeにアドバタイズするPATCHリクエストの例を示します。
|
||||
|
||||
```shell
|
||||
PATCH /api/v1/nodes/<選択したNodeの名前>/status HTTP/1.1
|
||||
Accept: application/json
|
||||
Content-Type: application/json-patch+json
|
||||
Host: k8s-master:8080
|
||||
|
||||
[
|
||||
{
|
||||
"op": "add",
|
||||
"path": "/status/capacity/example.com~1dongle",
|
||||
"value": "4"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
Kubernetesは、ドングルとは何かも、ドングルが何に利用できるのかを知る必要もないことに注意してください。上のPATCHリクエストは、ただNodeが4つのドングルと呼ばれるものを持っているとKubernetesに教えているだけです。
|
||||
|
||||
Kubernetes APIサーバーに簡単にリクエストを送れるように、プロキシーを実行します。
|
||||
|
||||
```shell
|
||||
kubectl proxy
|
||||
```
|
||||
|
||||
もう1つのコマンドウィンドウを開き、HTTPのPATCHリクエストを送ります。`<選択したNodeの名前>`の部分は、選択したNodeの名前に置き換えてください。
|
||||
|
||||
```shell
|
||||
curl --header "Content-Type: application/json-patch+json" \
|
||||
--request PATCH \
|
||||
--data '[{"op": "add", "path": "/status/capacity/example.com~1dongle", "value": "4"}]' \
|
||||
http://localhost:8001/api/v1/nodes/<選択したNodeの名前>/status
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
上のリクエストにある`~1`は、PATCHのパスにおける`/`という文字をエンコーディングしたものです。JSON-Patch内のoperationのpathはJSON-Pointerとして解釈されます。詳細については、[IETF RFC 6901](https://tools.ietf.org/html/rfc6901)のsection 3を読んでください。
|
||||
{{< /note >}}
|
||||
|
||||
出力には、Nodeがキャパシティー4のdongleを持っていることが示されます。
|
||||
|
||||
```
|
||||
"capacity": {
|
||||
"cpu": "2",
|
||||
"memory": "2049008Ki",
|
||||
"example.com/dongle": "4",
|
||||
```
|
||||
|
||||
Nodeの説明を確認します。
|
||||
|
||||
```
|
||||
kubectl describe node <選択したNodeの名前>
|
||||
```
|
||||
|
||||
出力には、再びdongleリソースが表示されます。
|
||||
|
||||
```yaml
|
||||
Capacity:
|
||||
cpu: 2
|
||||
memory: 2049008Ki
|
||||
example.com/dongle: 4
|
||||
```
|
||||
|
||||
これで、アプリケーション開発者は特定の数のdongleをリクエストするPodを作成できるようになりました。詳しくは、[拡張リソースをコンテナに割り当てる](/docs/tasks/configure-pod-container/extended-resource/)を読んでください。
|
||||
|
||||
## 議論
|
||||
|
||||
拡張リソースは、メモリやCPUリソースと同様のものです。たとえば、Nodeが持っている特定の量のメモリやCPUがNode上で動作している他のすべてのコンポーネントと共有されるのと同様に、Nodeが搭載している特定の数のdongleが他のすべてのコンポーネントと共有されます。そして、アプリケーション開発者が特定の量のメモリとCPUをリクエストするPodを作成できるのと同様に、Nodeが搭載している特定の数のdongleをリクエストするPodが作成できます。
|
||||
|
||||
拡張リソースはKubernetesには詳細を意図的に公開しないため、Kubernetesは拡張リソースの実体をまったく知りません。Kubernetesが知っているのは、Nodeが特定の数の拡張リソースを持っているということだけです。拡張リソースは整数値でアドバタイズしなければなりません。たとえば、Nodeは4つのdongleをアドバタイズできますが、4.5のdongleというのはアドバタイズできません。
|
||||
|
||||
### Storageの例
|
||||
|
||||
Nodeに800GiBの特殊なディスクストレージがあるとします。この特殊なストレージの名前、たとえばexample.com/special-storageという名前の拡張リソースが作れます。そして、そのなかの一定のサイズ、たとえば100GiBのチャンクをアドバタイズできます。この場合、Nodeはexample.com/special-storageという種類のキャパシティ8のリソースを持っているとアドバタイズします。
|
||||
|
||||
```yaml
|
||||
Capacity:
|
||||
...
|
||||
example.com/special-storage: 8
|
||||
```
|
||||
|
||||
特殊なストレージに任意のサイズのリクエストを許可したい場合、特殊なストレージを1バイトのサイズのチャンクでアドバタイズできます。その場合、example.com/special-storageという種類の800Giのリソースとしてアドバタイズします。
|
||||
|
||||
```yaml
|
||||
Capacity:
|
||||
...
|
||||
example.com/special-storage: 800Gi
|
||||
```
|
||||
|
||||
すると、コンテナは好きなバイト数の特殊なストレージを最大800Giまでリクエストできるようになります。
|
||||
|
||||
## クリーンアップ
|
||||
|
||||
以下に、dongleのアドバタイズをNodeから削除するPATCHリクエストを示します。
|
||||
|
||||
```
|
||||
PATCH /api/v1/nodes/<選択したNodeの名前>/status HTTP/1.1
|
||||
Accept: application/json
|
||||
Content-Type: application/json-patch+json
|
||||
Host: k8s-master:8080
|
||||
|
||||
[
|
||||
{
|
||||
"op": "remove",
|
||||
"path": "/status/capacity/example.com~1dongle",
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
Kubernetes APIサーバーに簡単にリクエストを送れるように、プロキシーを実行します。
|
||||
|
||||
```shell
|
||||
kubectl proxy
|
||||
```
|
||||
|
||||
もう1つのコマンドウィンドウで、HTTPのPATCHリクエストを送ります。`<選択したNodeの名前>`の部分は、選択したNodeの名前に置き換えてください。
|
||||
|
||||
```shell
|
||||
curl --header "Content-Type: application/json-patch+json" \
|
||||
--request PATCH \
|
||||
--data '[{"op": "remove", "path": "/status/capacity/example.com~1dongle"}]' \
|
||||
http://localhost:8001/api/v1/nodes/<選択したNodeの名前>/status
|
||||
```
|
||||
|
||||
dongleのアドバタイズが削除されたことを検証します。
|
||||
|
||||
```
|
||||
kubectl describe node <選択したNodeの名前> | grep dongle
|
||||
```
|
||||
|
||||
(出力には何も表示されないはずです)
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
### アプリケーション開発者向け
|
||||
|
||||
* [拡張リソースをコンテナに割り当てる](/ja/docs/tasks/configure-pod-container/extended-resource/)
|
||||
|
||||
### クラスター管理者向け
|
||||
|
||||
* [Namespaceに対してメモリの最小値と最大値の制約を設定する](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
|
||||
* [Namespaceに対してCPUの最小値と最大値の制約を設定する](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
|
||||
|
||||
|
||||
|
||||
@@ -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証明書が必要です。
|
||||
|
||||
このイニシアチブが成熟するに連れ、今後のリリースでこれらの問題に対処するための変更が行われます。
|
||||
|
||||
|
||||
@@ -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リソース量は、適切な量に制限されます。
|
||||
|
||||
|
||||
|
||||
@@ -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のメモリー使用量は、適切な量に制限されます。
|
||||
|
||||
## クリーンアップ
|
||||
|
||||
@@ -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/)についてさらに学ぶ。
|
||||
@@ -5,7 +5,7 @@ weight: 70
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
このページでは、[`projected`](/docs/concepts/storage/volumes/#projected)（投影）ボリュームを使用して、既存の複数のボリュームソースを同一ディレクトリ内にマウントする方法を説明します。
|
||||
このページでは、[`projected`](/docs/concepts/storage/volumes/#projected)(投影)ボリュームを使用して、既存の複数のボリュームソースを同一ディレクトリ内にマウントする方法を説明します。
|
||||
現在、`secret`、`configMap`、`downwardAPI`および`serviceAccountToken`ボリュームを投影できます。
|
||||
|
||||
{{< note >}}
|
||||
|
||||
@@ -87,7 +87,7 @@ weight: 50
|
||||
root@redis:/data/redis# kill <pid>
|
||||
```
|
||||
|
||||
ここで`<pid>`はRedisプロセスID（PID）です。
|
||||
ここで`<pid>`はRedisプロセスID(PID)です。
|
||||
|
||||
1. 元の端末で、Redis Podへの変更を監視します。最終的には、このようなものが表示されます:
|
||||
|
||||
|
||||
@@ -0,0 +1,124 @@
|
||||
---
|
||||
title: 拡張リソースをコンテナに割り当てる
|
||||
content_type: task
|
||||
weight: 40
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state state="stable" >}}
|
||||
|
||||
このページでは、拡張リソースをコンテナに割り当てる方法について説明します。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
この練習を始める前に、[Nodeに拡張リソースをアドバタイズする](/ja/docs/tasks/administer-cluster/extended-resource-node/)の練習を行ってください。これにより、Nodeの1つがドングルリソースをアドバタイズするように設定されます。
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## 拡張リソースをPodに割り当てる
|
||||
|
||||
拡張リソースをリクエストするには、コンテナのマニフェストに`resources:requests`フィールドを含めます。拡張リソースは、`*.kubernetes.io/`以外の任意のドメインで完全修飾されます。有効な拡張リソース名は、`example.com/foo`という形式になります。ここで、`example.com`はあなたの組織のドメインで、`foo`は記述的なリソース名で置き換えます。
|
||||
|
||||
1つのコンテナからなるPodの構成ファイルを示します。
|
||||
|
||||
{{< codenew file="pods/resource/extended-resource-pod.yaml" >}}
|
||||
|
||||
構成ファイルでは、コンテナが3つのdongleをリクエストしていることがわかります。
|
||||
|
||||
次のコマンドでPodを作成します。
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/pods/resource/extended-resource-pod.yaml
|
||||
```
|
||||
|
||||
Podが起動したことを確認します。
|
||||
|
||||
```shell
|
||||
kubectl get pod extended-resource-demo
|
||||
```
|
||||
|
||||
Podの説明を表示します。
|
||||
|
||||
```shell
|
||||
kubectl describe pod extended-resource-demo
|
||||
```
|
||||
|
||||
dongleのリクエストが表示されます。
|
||||
|
||||
```yaml
|
||||
Limits:
|
||||
example.com/dongle: 3
|
||||
Requests:
|
||||
example.com/dongle: 3
|
||||
```
|
||||
|
||||
## 2つ目のPodの作成を試みる
|
||||
|
||||
以下に、1つのコンテナを持つPodの構成ファイルを示します。コンテナは2つのdongleをリクエストします。
|
||||
|
||||
{{< codenew file="pods/resource/extended-resource-pod-2.yaml" >}}
|
||||
|
||||
Kubernetesは、2つのdongleのリクエストを満たすことができません。1つ目のPodが、利用可能な4つのdongleのうち3つを使用してしまっているためです。
|
||||
|
||||
Podを作成してみます。
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/pods/resource/extended-resource-pod-2.yaml
|
||||
```
|
||||
|
||||
Podの説明を表示します。
|
||||
|
||||
```shell
|
||||
kubectl describe pod extended-resource-demo-2
|
||||
```
|
||||
|
||||
出力にはPodがスケジュールできないことが示されます。2つのdongleが利用できるNodeが存在しないためです。
|
||||
|
||||
```
|
||||
Conditions:
|
||||
Type Status
|
||||
PodScheduled False
|
||||
...
|
||||
Events:
|
||||
...
|
||||
... Warning FailedScheduling pod (extended-resource-demo-2) failed to fit in any node
|
||||
fit failure summary on nodes : Insufficient example.com/dongle (1)
|
||||
```
|
||||
|
||||
Podのステータスを表示します。
|
||||
|
||||
```shell
|
||||
kubectl get pod extended-resource-demo-2
|
||||
```
|
||||
|
||||
出力には、Podは作成されたものの、Nodeにスケジュールされなかったことが示されています。PodはPending状態になっています。
|
||||
|
||||
```yaml
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
extended-resource-demo-2 0/1 Pending 0 6m
|
||||
```
|
||||
|
||||
## クリーンアップ
|
||||
|
||||
この練習で作成したPodを削除します。
|
||||
|
||||
```shell
|
||||
kubectl delete pod extended-resource-demo
|
||||
kubectl delete pod extended-resource-demo-2
|
||||
```
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
### アプリケーション開発者向け
|
||||
|
||||
* [コンテナおよびPodへのメモリーリソースの割り当て](/ja/docs/tasks/configure-pod-container/assign-memory-resource/)
|
||||
* [コンテナおよびPodへのCPUリソースの割り当て](/ja/docs/tasks/configure-pod-container/assign-cpu-resource/)
|
||||
|
||||
### クラスター管理者向け
|
||||
|
||||
* [Nodeに拡張リソースをアドバタイズする](/ja/docs/tasks/administer-cluster/extended-resource-node/)
|
||||
|
||||
|
||||
@@ -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内の他のコンテナに表示されます。**
|
||||
|
||||
@@ -14,7 +14,7 @@ content_type: task
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
* [Initコンテナ](/ja/docs/concepts/abstractions/init-containers/)の基本を理解しておきましょう。
|
||||
* [Initコンテナ](/ja/docs/concepts/workloads/pods/init-containers/)の基本を理解しておきましょう。
|
||||
* [Initコンテナを設定](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/)しておきましょう。
|
||||
|
||||
|
||||
@@ -100,7 +100,7 @@ kubectl logs <pod-name> -c <init-container-2>
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
## Podのステータスを理解する
|
||||
## Podのステータスを理解する {#understanding-pod-status}
|
||||
|
||||
`Init：`で始まるPodステータスはInitコンテナの実行ステータスを要約します。以下の表は、Initコンテナのデバッグ中に表示される可能性のあるステータス値の例をいくつか示しています。
|
||||
|
||||
|
||||
@@ -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)でお問い合わせください。
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -47,7 +47,7 @@ kubectl exec -it shell-demo -- /bin/bash
|
||||
```
|
||||
{{< note >}}
|
||||
|
||||
ダブルダッシュの記号 "--" はコマンドに渡す引数とkubectlの引数を分離します。
|
||||
ダブルダッシュの記号 `--` はコマンドに渡す引数とkubectlの引数を分離します。
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
+149
@@ -0,0 +1,149 @@
|
||||
---
|
||||
title: 環境変数によりコンテナにPod情報を共有する
|
||||
content_type: task
|
||||
weight: 30
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
このページでは、Podが内部で実行しているコンテナに自身の情報を共有する方法を説明します。環境変数ではPodのフィールドとコンテナのフィールドを共有することができます。
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Downward API {#the-downward-api}
|
||||
|
||||
Podとコンテナのフィールドを実行中のコンテナに共有する方法は2つあります:
|
||||
|
||||
* 環境変数
|
||||
* [ボリュームファイル](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api)
|
||||
|
||||
これら2つの方法を合わせて、Podとコンテナフィールドを共有する方法を*Downward API*と呼びます。
|
||||
|
||||
|
||||
## Podフィールドを環境変数の値として使用する {#use-pod-fields-as-values-for-environment-variables}
|
||||
|
||||
この演習では、1つのコンテナを持つPodを作成します。Podの設定ファイルは次のとおりです:
|
||||
|
||||
{{< codenew file="pods/inject/dapi-envars-pod.yaml" >}}
|
||||
|
||||
設定ファイルには、5つの環境変数があります。`env`フィールドは[EnvVars](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core)の配列です。配列の最初の要素では、環境変数`MY_NODE_NAME`の値をPodの`spec.nodeName`フィールドから取得することを指定します。同様に、他の環境変数もPodのフィールドから名前を取得します。
|
||||
|
||||
{{< note >}}
|
||||
この例のフィールドはPodのフィールドです。これらはPod内のコンテナのフィールドではありません。
|
||||
{{< /note >}}
|
||||
|
||||
Podを作成します:
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/pods/inject/dapi-envars-pod.yaml
|
||||
```
|
||||
|
||||
Podのコンテナが実行されていることを確認します:
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
コンテナのログを表示します:
|
||||
|
||||
```shell
|
||||
kubectl logs dapi-envars-fieldref
|
||||
```
|
||||
|
||||
出力には、選択した環境変数の値が表示されます:
|
||||
|
||||
```
|
||||
minikube
|
||||
dapi-envars-fieldref
|
||||
default
|
||||
172.17.0.4
|
||||
default
|
||||
```
|
||||
|
||||
これらの値がログにある理由を確認するには、設定ファイルの`command`および`args`フィールドを確認してください。コンテナが起動すると、5つの環境変数の値が標準出力に書き込まれます。これを10秒ごとに繰り返します。
|
||||
|
||||
次に、Podで実行しているコンテナへのシェルを取得します:
|
||||
|
||||
```shell
|
||||
kubectl exec -it dapi-envars-fieldref -- sh
|
||||
```
|
||||
|
||||
シェルで環境変数を表示します:
|
||||
|
||||
```shell
|
||||
/# printenv
|
||||
```
|
||||
|
||||
出力は、特定の環境変数にPodフィールドの値が割り当てられていることを示しています:
|
||||
|
||||
```
|
||||
MY_POD_SERVICE_ACCOUNT=default
|
||||
...
|
||||
MY_POD_NAMESPACE=default
|
||||
MY_POD_IP=172.17.0.4
|
||||
...
|
||||
MY_NODE_NAME=minikube
|
||||
...
|
||||
MY_POD_NAME=dapi-envars-fieldref
|
||||
```
|
||||
|
||||
## コンテナフィールドを環境変数の値として使用する {#use-container-fields-as-values-for-environment-variables}
|
||||
|
||||
前の演習では、環境変数の値としてPodフィールドを使用しました。次の演習では、環境変数の値としてコンテナフィールドを使用します。これは、1つのコンテナを持つPodの設定ファイルです:
|
||||
|
||||
{{< codenew file="pods/inject/dapi-envars-container.yaml" >}}
|
||||
|
||||
設定ファイルには、4つの環境変数があります。`env`フィールドは[EnvVars](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core)の配列です。配列の最初の要素では、環境変数`MY_CPU_REQUEST`の値を`test-container`という名前のコンテナの`requests.cpu`フィールドから取得することを指定します。同様に、他の環境変数もコンテナのフィールドから値を取得します。
|
||||
|
||||
Podを作成します:
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/pods/inject/dapi-envars-container.yaml
|
||||
```
|
||||
|
||||
Podのコンテナが実行されていることを確認します:
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
コンテナのログを表示します:
|
||||
|
||||
```shell
|
||||
kubectl logs dapi-envars-resourcefieldref
|
||||
```
|
||||
|
||||
出力には、選択した環境変数の値が表示されます:
|
||||
|
||||
```
|
||||
1
|
||||
1
|
||||
33554432
|
||||
67108864
|
||||
```
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [コンテナの環境変数の定義](/ja/docs/tasks/inject-data-application/define-environment-variable-container/)
|
||||
* [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
|
||||
* [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
|
||||
* [EnvVar](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core)
|
||||
* [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core)
|
||||
* [ObjectFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#objectfieldselector-v1-core)
|
||||
* [ResourceFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcefieldselector-v1-core)
|
||||
|
||||
|
||||
@@ -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がスケジューリングされることを保証できます。
|
||||
@@ -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を強制的に削除することでこれを無効にすることができます。
|
||||
|
||||
|
||||
+6
@@ -0,0 +1,6 @@
|
||||
---
|
||||
title: "サービスカタログ"
|
||||
description: サービスカタログ拡張APIをインストールする
|
||||
weight: 150
|
||||
---
|
||||
|
||||
@@ -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)プロジェクトを探索する。
|
||||
@@ -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つの方法が機能します。
|
||||
|
||||
@@ -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" %}}
|
||||
|
||||
Reference in New Issue
Block a user