commit first work from 1.19 milestone
This commit is contained in:
inductor
+4
-4
@@ -31,9 +31,9 @@ card:
|
||||
|
||||
## クラスター、ユーザー、コンテキストを設定する
|
||||
|
||||
例として、開発用のクラスターが一つ、実験用のクラスターが一つ、計二つのクラスターが存在する場合を考えます。`development`と呼ばれる開発用のクラスター内では、フロントエンドの開発者は`frontend`というnamespace内で、ストレージの開発者は`storage`というnamespace内で作業をします。`scratch`と呼ばれる実験用のクラスター内では、開発者はデフォルトのnamespaceで作業をするか、状況に応じて追加のnamespaceを作成します。開発用のクラスターは証明書を通しての認証を必要とします。実験用のクラスターはユーザーネームとパスワードを通しての認証を必要とします。
|
||||
例として、開発用のクラスターが一つ、実験用のクラスターが一つ、計二つのクラスターが存在する場合を考えます。`development`と呼ばれる開発用のクラスター内では、フロントエンドの開発者は`frontend`というnamespace内で、ストレージの開発者は`storage`というnamespace内で作業をします。`scratch`と呼ばれる実験用のクラスター内では、開発者はデフォルトのnamespaceで作業をするか、状況に応じて追加のnamespaceを作成します。開発用のクラスターは証明書を通しての認証を必要とします。実験用のクラスターはユーザーネームとパスワードを通しての認証を必要とします。
|
||||
|
||||
`config-exercise`というディレクトリを作成してください。`config-exercise`ディレクトリ内に、以下を含む`config-demo`というファイルを作成してください:
|
||||
`config-exercise`というディレクトリを作成してください。`config-exercise`ディレクトリ内に、以下を含む`config-demo`というファイルを作成してください:
|
||||
|
||||
```shell
|
||||
apiVersion: v1
|
||||
@@ -61,7 +61,7 @@ contexts:
|
||||
|
||||
設定ファイルには、クラスター、ユーザー、コンテキストの情報が含まれています。上記の`config-demo`設定ファイルには、二つのクラスター、二人のユーザー、三つのコンテキストの情報が含まれています。
|
||||
|
||||
`config-exercise`ディレクトリに移動してください。クラスター情報を設定ファイルに追加するために、以下のコマンドを実行してください:
|
||||
`config-exercise`ディレクトリに移動してください。クラスター情報を設定ファイルに追加するために、以下のコマンドを実行してください:
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo set-cluster development --server=https://1.2.3.4 --certificate-authority=fake-ca-file
|
||||
@@ -89,7 +89,7 @@ kubectl config --kubeconfig=config-demo set-context dev-storage --cluster=develo
|
||||
kubectl config --kubeconfig=config-demo set-context exp-scratch --cluster=scratch --namespace=default --user=experimenter
|
||||
```
|
||||
|
||||
追加した情報を確認するために、`config-demo`ファイルを開いてください。`config-demo`ファイルを開く代わりに、`config view`のコマンドを使うこともできます。
|
||||
追加した情報を確認するために、`config-demo`ファイルを開いてください。`config-demo`ファイルを開く代わりに、`config view`のコマンドを使うこともできます。
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo view
|
||||
|
||||
@@ -134,28 +134,12 @@ weight: 100
|
||||
|
||||
1. 以下の内容で`example-ingress.yaml`を作成します。
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.k8s.io/v1beta1
|
||||
kind: Ingress
|
||||
metadata:
|
||||
name: example-ingress
|
||||
annotations:
|
||||
nginx.ingress.kubernetes.io/rewrite-target: /$1
|
||||
spec:
|
||||
rules:
|
||||
- host: hello-world.info
|
||||
http:
|
||||
paths:
|
||||
- path: /
|
||||
backend:
|
||||
serviceName: web
|
||||
servicePort: 8080
|
||||
```
|
||||
{{< codenew file="service/networking/example-ingress.yaml" >}}
|
||||
|
||||
1. 次のコマンドを実行して、Ingressリソースを作成します。
|
||||
|
||||
```shell
|
||||
kubectl apply -f example-ingress.yaml
|
||||
kubectl apply -f https://kubernetes.io/examples/service/networking/example-ingress.yaml
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
@@ -175,8 +159,8 @@ weight: 100
|
||||
{{< /note >}}
|
||||
|
||||
```shell
|
||||
NAME HOSTS ADDRESS PORTS AGE
|
||||
example-ingress hello-world.info 172.17.0.15 80 38s
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
example-ingress <none> hello-world.info 172.17.0.15 80 38s
|
||||
```
|
||||
|
||||
1. 次の行を`/etc/hosts`ファイルの最後に書きます。
|
||||
@@ -241,9 +225,12 @@ weight: 100
|
||||
|
||||
```yaml
|
||||
- path: /v2
|
||||
pathType: Prefix
|
||||
backend:
|
||||
serviceName: web2
|
||||
servicePort: 8080
|
||||
service:
|
||||
name: web2
|
||||
port:
|
||||
number: 8080
|
||||
```
|
||||
|
||||
1. 次のコマンドで変更を適用します。
|
||||
@@ -300,6 +287,3 @@ weight: 100
|
||||
* [Ingress](/ja/docs/concepts/services-networking/ingress/)についてさらに学ぶ。
|
||||
* [Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers/)についてさらに学ぶ。
|
||||
* [Service](/ja/docs/concepts/services-networking/service/)についてさらに学ぶ。
|
||||
|
||||
|
||||
|
||||
|
||||
+258
@@ -0,0 +1,258 @@
|
||||
---
|
||||
title: Namespaceに対する最小および最大メモリー制約の構成
|
||||
|
||||
content_type: task
|
||||
weight: 30
|
||||
---
|
||||
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
このページでは、Namespaceで実行されるコンテナが使用するメモリーの最小値と最大値を設定する方法を説明します。
|
||||
[LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core) で最小値と最大値のメモリー値を指定します。
|
||||
PodがLimitRangeによって課される制約を満たさない場合、そのNamespaceではPodを作成できません。
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
クラスター内の各ノードには、少なくとも1GiBのメモリーが必要です。
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Namespaceの作成
|
||||
|
||||
この演習で作成したリソースがクラスターの他の部分から分離されるように、Namespaceを作成します。
|
||||
|
||||
|
||||
```shell
|
||||
kubectl create namespace constraints-mem-example
|
||||
```
|
||||
|
||||
## LimitRangeとPodを作成
|
||||
|
||||
LimitRangeの設定ファイルです。
|
||||
|
||||
{{< codenew file="admin/resource/memory-constraints.yaml" >}}
|
||||
|
||||
LimitRangeを作成します。
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints.yaml --namespace=constraints-mem-example
|
||||
```
|
||||
|
||||
LimitRangeの詳細情報を表示します。
|
||||
|
||||
|
||||
```shell
|
||||
kubectl get limitrange mem-min-max-demo-lr --namespace=constraints-mem-example --output=yaml
|
||||
```
|
||||
|
||||
出力されるのは、予想通りメモリー制約の最小値と最大値を示しています。
|
||||
しかし、LimitRangeの設定ファイルでデフォルト値を指定していないにもかかわらず、
|
||||
自動的に作成されていることに気づきます。
|
||||
|
||||
|
||||
```
|
||||
limits:
|
||||
- default:
|
||||
memory: 1Gi
|
||||
defaultRequest:
|
||||
memory: 1Gi
|
||||
max:
|
||||
memory: 1Gi
|
||||
min:
|
||||
memory: 500Mi
|
||||
type: Container
|
||||
```
|
||||
|
||||
|
||||
constraints-mem-exampleNamespaceにコンテナが作成されるたびに、
|
||||
Kubernetesは以下の手順を実行するようになっています。
|
||||
|
||||
* コンテナが独自のメモリー要求と制限を指定しない場合は、デフォルトのメモリー要求と制限をコンテナに割り当てます。
|
||||
|
||||
* コンテナに500MiB以上のメモリー要求があることを確認します。
|
||||
|
||||
* コンテナのメモリー制限が1GiB以下であることを確認します。
|
||||
|
||||
以下は、1つのコンテナを持つPodの設定ファイルです。設定ファイルのコンテナ(containers)では、600MiBのメモリー要求と800MiBのメモリー制限が指定されています。これらはLimitRangeによって課される最小と最大のメモリー制約を満たしています。
|
||||
|
||||
|
||||
{{< codenew file="admin/resource/memory-constraints-pod.yaml" >}}
|
||||
|
||||
Podの作成
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod.yaml --namespace=constraints-mem-example
|
||||
```
|
||||
|
||||
Podのコンテナが実行されていることを確認します。
|
||||
|
||||
```shell
|
||||
kubectl get pod constraints-mem-demo --namespace=constraints-mem-example
|
||||
```
|
||||
|
||||
Podの詳細情報を見ます
|
||||
|
||||
```shell
|
||||
kubectl get pod constraints-mem-demo --output=yaml --namespace=constraints-mem-example
|
||||
```
|
||||
|
||||
出力は、コンテナが600MiBのメモリ要求と800MiBのメモリー制限になっていることを示しています。これらはLimitRangeによって課される制約を満たしています。
|
||||
|
||||
|
||||
```yaml
|
||||
resources:
|
||||
limits:
|
||||
memory: 800Mi
|
||||
requests:
|
||||
memory: 600Mi
|
||||
```
|
||||
|
||||
Podを消します。
|
||||
|
||||
```shell
|
||||
kubectl delete pod constraints-mem-demo --namespace=constraints-mem-example
|
||||
```
|
||||
|
||||
## 最大メモリ制約を超えるPodの作成の試み
|
||||
|
||||
これは、1つのコンテナを持つPodの設定ファイルです。コンテナは800MiBのメモリー要求と1.5GiBのメモリー制限を指定しています。
|
||||
|
||||
|
||||
{{< codenew file="admin/resource/memory-constraints-pod-2.yaml" >}}
|
||||
|
||||
Podを作成してみます。
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-2.yaml --namespace=constraints-mem-example
|
||||
```
|
||||
|
||||
出力は、コンテナが大きすぎるメモリー制限を指定しているため、Podが作成されないことを示しています。
|
||||
|
||||
|
||||
```
|
||||
Error from server (Forbidden): error when creating "examples/admin/resource/memory-constraints-pod-2.yaml":
|
||||
pods "constraints-mem-demo-2" is forbidden: maximum memory usage per Container is 1Gi, but limit is 1536Mi.
|
||||
```
|
||||
|
||||
## 最低限のメモリ要求を満たさないPodの作成の試み
|
||||
|
||||
|
||||
これは、1つのコンテナを持つPodの設定ファイルです。コンテナは100MiBのメモリー要求と800MiBのメモリー制限を指定しています。
|
||||
|
||||
|
||||
{{< codenew file="admin/resource/memory-constraints-pod-3.yaml" >}}
|
||||
|
||||
Podを作成してみます。
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-3.yaml --namespace=constraints-mem-example
|
||||
```
|
||||
|
||||
出力は、コンテナが小さすぎるメモリー要求を指定しているため、Podが作成されないことを示しています。
|
||||
|
||||
```
|
||||
Error from server (Forbidden): error when creating "examples/admin/resource/memory-constraints-pod-3.yaml":
|
||||
pods "constraints-mem-demo-3" is forbidden: minimum memory usage per Container is 500Mi, but request is 100Mi.
|
||||
```
|
||||
|
||||
## メモリ要求や制限を指定しないPodの作成
|
||||
|
||||
|
||||
これは、1つのコンテナを持つPodの設定ファイルです。コンテナはメモリー要求を指定しておらず、メモリー制限も指定していません。
|
||||
|
||||
{{< codenew file="admin/resource/memory-constraints-pod-4.yaml" >}}
|
||||
|
||||
Podを作成します。
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-4.yaml --namespace=constraints-mem-example
|
||||
```
|
||||
|
||||
Podの詳細情報を見ます
|
||||
|
||||
```
|
||||
kubectl get pod constraints-mem-demo-4 --namespace=constraints-mem-example --output=yaml
|
||||
```
|
||||
|
||||
出力を見ると、Podのコンテナのメモリ要求は1GiB、メモリー制限は1GiBであることがわかります。
|
||||
コンテナはどのようにしてこれらの値を取得したのでしょうか？
|
||||
|
||||
|
||||
```
|
||||
resources:
|
||||
limits:
|
||||
memory: 1Gi
|
||||
requests:
|
||||
memory: 1Gi
|
||||
```
|
||||
|
||||
コンテナが独自のメモリー要求と制限を指定していなかったため、LimitRangeから与えられのです。
|
||||
コンテナが独自のメモリー要求と制限を指定していなかったため、LimitRangeから[デフォルトのメモリー要求と制限](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)が与えられたのです。
|
||||
|
||||
この時点で、コンテナは起動しているかもしれませんし、起動していないかもしれません。このタスクの前提条件は、ノードが少なくとも1GiBのメモリーを持っていることであることを思い出してください。それぞれのノードが1GiBのメモリーしか持っていない場合、どのノードにも1GiBのメモリー要求に対応するのに十分な割り当て可能なメモリーがありません。たまたま2GiBのメモリーを持つノードを使用しているのであれば、おそらく1GiBのメモリーリクエストに対応するのに十分なスペースを持っていることになります。
|
||||
|
||||
|
||||
Podを削除します。
|
||||
|
||||
```
|
||||
kubectl delete pod constraints-mem-demo-4 --namespace=constraints-mem-example
|
||||
```
|
||||
|
||||
## 最小および最大メモリー制約の強制
|
||||
|
||||
LimitRangeによってNamespaceに課される最大および最小のメモリー制約は、Podが作成または更新されたときにのみ適用されます。LimitRangeを変更しても、以前に作成されたPodには影響しません。
|
||||
|
||||
|
||||
## 最小・最大メモリー制約の動機
|
||||
|
||||
|
||||
クラスター管理者としては、Podが使用できるメモリー量に制限を課したいと思うかもしれません。
|
||||
|
||||
|
||||
例:
|
||||
|
||||
* クラスター内の各ノードは2GBのメモリーを持っています。クラスタ内のどのノードもその要求をサポートできないため、2GB以上のメモリーを要求するPodは受け入れたくありません。
|
||||
|
||||
|
||||
* クラスターは運用部門と開発部門で共有されています。 本番用のワークロードでは最大8GBのメモリーを消費しますが、開発用のワークロードでは512MBに制限したいとします。本番用と開発用に別々のNamespaceを作成し、それぞれのNamespaceにメモリー制限を適用します。
|
||||
|
||||
## クリーンアップ
|
||||
|
||||
Namespaceを削除します。
|
||||
|
||||
```shell
|
||||
kubectl delete namespace constraints-mem-example
|
||||
```
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
### クラスター管理者向け
|
||||
|
||||
* [名前空間に対するデフォルトのメモリー要求と制限の構成](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
|
||||
|
||||
* [名前空間に対するデフォルトのCPU要求と制限の構成](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)
|
||||
|
||||
* [名前空間に対する最小および最大CPU制約の構成](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
|
||||
|
||||
* [名前空間に対するメモリーとCPUのクォータの構成](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
|
||||
|
||||
* [名前空間に対するPodクォータの設定](/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)
|
||||
|
||||
* [APIオブジェクトのクォータの設定](/docs/tasks/administer-cluster/quota-api-object/)
|
||||
|
||||
### アプリケーション開発者向け
|
||||
|
||||
* [コンテナとPodへのメモリーリソースの割り当て](/docs/tasks/configure-pod-container/assign-memory-resource/)
|
||||
|
||||
* [コンテナとPodへのCPUリソースの割り当て](/docs/tasks/configure-pod-container/assign-cpu-resource/)
|
||||
|
||||
* [PodのQoS(サービス品質)を設定](/docs/tasks/configure-pod-container/quality-service-pod/)
|
||||
+6
@@ -0,0 +1,6 @@
|
||||
---
|
||||
title: "Secretの管理"
|
||||
weight: 28
|
||||
description: Secretを使用した機密設定データの管理
|
||||
---
|
||||
|
||||
@@ -0,0 +1,183 @@
|
||||
---
|
||||
title: 設定ファイルを使用してSecretを管理する
|
||||
content_type: task
|
||||
weight: 20
|
||||
description: リソース設定ファイルを使用してSecretを作成する
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## 設定ファイルを作成する
|
||||
|
||||
あらかじめYAMLまたはJSON形式でSecretのマニフェストを作成したうえで、オブジェクトを作成することができます。
|
||||
[Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)リソースには、`data`と`stringData`の2つのマップが含まれています。
|
||||
`data`フィールドは任意のデータを格納するのに使用され、base64でエンコードされます。
|
||||
`stringData`フィールドは利便性のために用意されており、Secretデータをエンコードされていない文字列として提供することができます。
|
||||
`data`と`stringData`のキーは、英数字、`-`、`_`、`.`で構成されている必要があります。
|
||||
|
||||
たとえば、`data`フィールドを使用して2つの文字列をSecretに格納するには、次のように文字列をbase64に変換します:
|
||||
|
||||
```shell
|
||||
echo -n 'admin' | base64
|
||||
```
|
||||
|
||||
出力は次のようになります:
|
||||
|
||||
```
|
||||
YWRtaW4=
|
||||
```
|
||||
|
||||
```shell
|
||||
echo -n '1f2d1e2e67df' | base64
|
||||
```
|
||||
|
||||
出力は次のようになります:
|
||||
|
||||
```
|
||||
MWYyZDFlMmU2N2Rm
|
||||
```
|
||||
|
||||
以下のようなSecret設定ファイルを記述します:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: mysecret
|
||||
type: Opaque
|
||||
data:
|
||||
username: YWRtaW4=
|
||||
password: MWYyZDFlMmU2N2Rm
|
||||
```
|
||||
|
||||
なお、Secretオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。
|
||||
|
||||
{{< note >}}
|
||||
SecretデータのシリアライズされたJSONおよびYAMLの値は、base64文字列としてエンコードされます。
|
||||
文字列中の改行は不正で、含まれていてはなりません。
|
||||
Darwin/macOSで`base64`ユーティリティーを使用する場合、長い行を分割するために`-b`オプションを使用するのは避けるべきです。
|
||||
逆に、Linux ユーザーは、`base64` コマンドにオプション`-w 0`を追加するか、`-w`オプションが利用できない場合には、パイプライン`base64 | tr -d '\n'`を追加する*必要があります*。
|
||||
{{< /note >}}
|
||||
|
||||
特定のシナリオでは、代わりに`stringData`フィールドを使用できます。
|
||||
このフィールドでは、base64エンコードされていない文字列を直接Secretに入れることができ、Secretの作成時や更新時には、その文字列がエンコードされます。
|
||||
|
||||
たとえば、設定ファイルを保存するためにSecretを使用しているアプリケーションをデプロイする際に、デプロイプロセス中に設定ファイルの一部を入力したい場合などが考えられます。
|
||||
|
||||
たとえば、次のような設定ファイルを使用しているアプリケーションの場合:
|
||||
|
||||
```yaml
|
||||
apiUrl: "https://my.api.com/api/v1"
|
||||
username: "<user>"
|
||||
password: "<password>"
|
||||
```
|
||||
|
||||
次のような定義でSecretに格納できます:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: mysecret
|
||||
type: Opaque
|
||||
stringData:
|
||||
config.yaml: |
|
||||
apiUrl: "https://my.api.com/api/v1"
|
||||
username: <user>
|
||||
password: <password>
|
||||
```
|
||||
|
||||
## Secretを作成する
|
||||
|
||||
[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply)でSecretを作成します:
|
||||
|
||||
```shell
|
||||
kubectl apply -f ./secret.yaml
|
||||
```
|
||||
|
||||
出力は次のようになります:
|
||||
|
||||
```
|
||||
secret/mysecret created
|
||||
```
|
||||
|
||||
## Secretを確認する
|
||||
|
||||
`stringData`フィールドは、書き込み専用の便利なフィールドです。Secretを取得する際には決して出力されません。たとえば、次のようなコマンドを実行した場合:
|
||||
|
||||
```shell
|
||||
kubectl get secret mysecret -o yaml
|
||||
```
|
||||
|
||||
出力は次のようになります:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
creationTimestamp: 2018-11-15T20:40:59Z
|
||||
name: mysecret
|
||||
namespace: default
|
||||
resourceVersion: "7225"
|
||||
uid: c280ad2e-e916-11e8-98f2-025000000001
|
||||
type: Opaque
|
||||
data:
|
||||
config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19
|
||||
```
|
||||
|
||||
`kubectl get`と`kubectl describe`コマンドはデフォルトではSecretの内容を表示しません。
|
||||
これは、Secretが不用意に他人にさらされたり、ターミナルログに保存されたりしないようにするためです。
|
||||
エンコードされたデータの実際の内容を確認するには、[Secretのデコード](/ja/docs/tasks/configmap-secret/managing-secret-using-kubectl/#decoding-secret)を参照してください。
|
||||
|
||||
`username`などのフィールドが`data`と`stringData`の両方に指定されている場合は、`stringData`の値が使われます。
|
||||
たとえば、以下のようなSecretの定義の場合:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: mysecret
|
||||
type: Opaque
|
||||
data:
|
||||
username: YWRtaW4=
|
||||
stringData:
|
||||
username: administrator
|
||||
```
|
||||
|
||||
結果は以下の通りです:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
creationTimestamp: 2018-11-15T20:46:46Z
|
||||
name: mysecret
|
||||
namespace: default
|
||||
resourceVersion: "7579"
|
||||
uid: 91460ecb-e917-11e8-98f2-025000000001
|
||||
type: Opaque
|
||||
data:
|
||||
username: YWRtaW5pc3RyYXRvcg==
|
||||
```
|
||||
|
||||
`YWRtaW5pc3RyYXRvcg==`をデコードすると`administrator`となります。
|
||||
|
||||
## クリーンアップ
|
||||
|
||||
作成したSecretを削除するには次のコマンドを実行します:
|
||||
|
||||
```shell
|
||||
kubectl delete secret mysecret
|
||||
```
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
- [Secretのコンセプト](/ja/docs/concepts/configuration/secret/)を読む
|
||||
- [kubectlを使用してSecretを管理する](/ja/docs/tasks/configmap-secret/managing-secret-using-kubectl/)方法を知る
|
||||
- [kustomizeを使用してSecretを管理する](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)方法を知る
|
||||
@@ -0,0 +1,146 @@
|
||||
---
|
||||
title: kubectlを使用してSecretを管理する
|
||||
content_type: task
|
||||
weight: 10
|
||||
description: kubectlコマンドラインを使用してSecretを作成する
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Secretを作成する
|
||||
|
||||
`Secret`はデータベースにアクセスするためにPodが必要とするユーザー資格情報を含めることができます。
|
||||
たとえば、データベース接続文字列はユーザー名とパスワードで構成されます。
|
||||
ユーザー名はローカルマシンの`./username.txt`に、パスワードは`./password.txt`に保存します。
|
||||
|
||||
```shell
|
||||
echo -n 'admin' > ./username.txt
|
||||
echo -n '1f2d1e2e67df' > ./password.txt
|
||||
```
|
||||
|
||||
上記の2つのコマンドの`-n`フラグは、生成されたファイルにテキスト末尾の余分な改行文字が含まれないようにします。
|
||||
`kubectl`がファイルを読み取り、内容をbase64文字列にエンコードすると、余分な改行文字もエンコードされるため、これは重要です。
|
||||
|
||||
`kubectl create secret`コマンドはこれらのファイルをSecretにパッケージ化し、APIサーバー上にオブジェクトを作成します。
|
||||
|
||||
```shell
|
||||
kubectl create secret generic db-user-pass \
|
||||
--from-file=./username.txt \
|
||||
--from-file=./password.txt
|
||||
```
|
||||
|
||||
出力は次のようになります:
|
||||
|
||||
```
|
||||
secret/db-user-pass created
|
||||
```
|
||||
|
||||
ファイル名がデフォルトのキー名になります。オプションで`--from-file=[key=]source`を使用してキー名を設定できます。たとえば:
|
||||
|
||||
```shell
|
||||
kubectl create secret generic db-user-pass \
|
||||
--from-file=username=./username.txt \
|
||||
--from-file=password=./password.txt
|
||||
```
|
||||
|
||||
`--from-file`に指定したファイルに含まれるパスワードの特殊文字をエスケープする必要はありません。
|
||||
|
||||
また、`--from-literal=<key>=<value>`タグを使用してSecretデータを提供することもできます。
|
||||
このタグは、複数のキーと値のペアを提供するために複数回指定することができます。
|
||||
`$`、`\`、`*`、`=`、`!`などの特殊文字は[シェル](https://en.wikipedia.org/wiki/Shell_(computing))によって解釈されるため、エスケープを必要とすることに注意してください。
|
||||
ほとんどのシェルでは、パスワードをエスケープする最も簡単な方法は、シングルクォート(`'`)で囲むことです。
|
||||
たとえば、実際のパスワードが`S!B\*d$zDsb=`の場合、次のようにコマンドを実行します:
|
||||
|
||||
```shell
|
||||
kubectl create secret generic dev-db-secret \
|
||||
--from-literal=username=devuser \
|
||||
--from-literal=password='S!B\*d$zDsb='
|
||||
```
|
||||
|
||||
## Secretを検証する
|
||||
|
||||
Secretが作成されたことを確認できます:
|
||||
|
||||
```shell
|
||||
kubectl get secrets
|
||||
```
|
||||
|
||||
出力は次のようになります:
|
||||
|
||||
```
|
||||
NAME TYPE DATA AGE
|
||||
db-user-pass Opaque 2 51s
|
||||
```
|
||||
|
||||
`Secret`の説明を参照できます:
|
||||
|
||||
```shell
|
||||
kubectl describe secrets/db-user-pass
|
||||
```
|
||||
|
||||
出力は次のようになります:
|
||||
|
||||
```
|
||||
Name: db-user-pass
|
||||
Namespace: default
|
||||
Labels: <none>
|
||||
Annotations: <none>
|
||||
|
||||
Type: Opaque
|
||||
|
||||
Data
|
||||
====
|
||||
password: 12 bytes
|
||||
username: 5 bytes
|
||||
```
|
||||
|
||||
`kubectl get`と`kubectl describe`コマンドはデフォルトでは`Secret`の内容を表示しません。
|
||||
これは、`Secret`が不用意に他人にさらされたり、ターミナルログに保存されたりしないようにするためです。
|
||||
|
||||
## Secretをデコードする {#decoding-secret}
|
||||
|
||||
先ほど作成したSecretの内容を見るには、以下のコマンドを実行します:
|
||||
|
||||
```shell
|
||||
kubectl get secret db-user-pass -o jsonpath='{.data}'
|
||||
```
|
||||
|
||||
出力は次のようになります:
|
||||
|
||||
```json
|
||||
{"password":"MWYyZDFlMmU2N2Rm","username":"YWRtaW4="}
|
||||
```
|
||||
|
||||
`password`のデータをデコードします:
|
||||
|
||||
```shell
|
||||
echo 'MWYyZDFlMmU2N2Rm' | base64 --decode
|
||||
```
|
||||
|
||||
出力は次のようになります:
|
||||
|
||||
```
|
||||
1f2d1e2e67df
|
||||
```
|
||||
|
||||
## クリーンアップ
|
||||
|
||||
作成したSecretを削除するには次のコマンドを実行します:
|
||||
|
||||
```shell
|
||||
kubectl delete secret db-user-pass
|
||||
```
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
- [Secretのコンセプト](/ja/docs/concepts/configuration/secret/)を読む
|
||||
- [設定ファイルを使用してSecretを管理する](/ja/docs/tasks/configmap-secret/managing-secret-using-config-file/)方法を知る
|
||||
- [kustomizeを使用してSecretを管理する](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)方法を知る
|
||||
@@ -365,7 +365,7 @@ kubectl get service hostnames -o json
|
||||
kubectl get pods -l app=hostnames
|
||||
```
|
||||
```none
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
hostnames-632524106-bbpiw 1/1 Running 0 1h
|
||||
hostnames-632524106-ly40y 1/1 Running 0 1h
|
||||
hostnames-632524106-tlaok 1/1 Running 0 1h
|
||||
|
||||
@@ -0,0 +1,6 @@
|
||||
---
|
||||
title: "Jobの実行"
|
||||
description: 並列処理を使用してJobを実行します。
|
||||
weight: 50
|
||||
---
|
||||
|
||||
@@ -0,0 +1,175 @@
|
||||
---
|
||||
title: CronJobを使用して自動化タスクを実行する
|
||||
min-kubernetes-server-version: v1.21
|
||||
content_type: task
|
||||
weight: 10
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
CronJobは、Kubernetes v1.21で一般利用(GA)に昇格しました。古いバージョンのKubernetesを使用している場合、正確な情報を参照できるように、使用しているバージョンのKubernetesのドキュメントを参照してください。古いKubernetesのバージョンでは、`batch/v1` CronJob APIはサポートされていません。
|
||||
|
||||
{{< glossary_tooltip text="CronJob" term_id="cronjob" >}}を使用すると、{{< glossary_tooltip text="Job" term_id="job" >}}を時間ベースのスケジュールで実行できるようになります。この自動化されたJobは、LinuxまたはUNIXシステム上の[Cron](https://ja.wikipedia.org/wiki/Cron)のように実行されます。
|
||||
|
||||
CronJobは、バックアップやメールの送信など、定期的なタスクや繰り返しのタスクを作成する時に便利です。CronJobはそれぞれのタスクを、たとえばアクティビティが少ない期間など、特定の時間にスケジューリングすることもできます。
|
||||
|
||||
CronJobには制限と特性があります。たとえば、特定の状況下では、1つのCronJobが複数のJobを作成する可能性があるため、Jobは冪等性を持つようにしなければいけません。
|
||||
|
||||
制限に関する詳しい情報については、[CronJob](/ja/docs/concepts/workloads/controllers/cron-jobs/)を参照してください。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
* {{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## CronJobを作成する
|
||||
|
||||
CronJobには設定ファイルが必要です。次の例のCronJobの`.spec`は、現在の時刻とhelloというメッセージを1分ごとに表示します。
|
||||
|
||||
{{< codenew file="application/job/cronjob.yaml" >}}
|
||||
|
||||
次のコマンドで例のCronJobを実行します。
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/examples/application/job/cronjob.yaml
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
cronjob.batch/hello created
|
||||
```
|
||||
|
||||
CronJobを作成したら、次のコマンドで状態を取得します。
|
||||
|
||||
```shell
|
||||
kubectl get cronjob hello
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
|
||||
hello */1 * * * * False 0 <none> 10s
|
||||
```
|
||||
|
||||
コマンドの結果からわかるように、CronJobはまだスケジュールされておらず、まだ何のJobも実行していません。約1分以内にJobが作成されるのを見てみましょう。
|
||||
|
||||
```shell
|
||||
kubectl get jobs --watch
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
NAME COMPLETIONS DURATION AGE
|
||||
hello-4111706356 0/1 0s
|
||||
hello-4111706356 0/1 0s 0s
|
||||
hello-4111706356 1/1 5s 5s
|
||||
```
|
||||
|
||||
"hello"CronJobによってスケジュールされたJobが1つ実行中になっていることがわかります。Jobを見るのをやめて、再度CronJobを表示して、Jobがスケジュールされたことを確認してみます。
|
||||
|
||||
```shell
|
||||
kubectl get cronjob hello
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
|
||||
hello */1 * * * * False 0 50s 75s
|
||||
```
|
||||
|
||||
CronJob`hello`が、`LAST SCHEDULE`で指定された時間にJobを正しくスケジュールしたことが確認できるはずです。現在、activeなJobの数は0です。つまり、Jobは完了または失敗したことがわかります。
|
||||
|
||||
それでは、最後にスケジュールされたJobの作成と、Podの1つの標準出力を表示してみましょう。
|
||||
|
||||
{{< note >}}
|
||||
Jobの名前とPodの名前は異なります。
|
||||
{{< /note >}}
|
||||
|
||||
```shell
|
||||
# "hello-4111706356" の部分は、あなたのシステム上のJobの名前に置き換えてください。
|
||||
pods=$(kubectl get pods --selector=job-name=hello-4111706356 --output=jsonpath={.items[*].metadata.name})
|
||||
```
|
||||
|
||||
Podのログを表示します。
|
||||
|
||||
```shell
|
||||
kubectl logs $pods
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
Fri Feb 22 11:02:09 UTC 2019
|
||||
Hello from the Kubernetes cluster
|
||||
```
|
||||
|
||||
## CronJobの削除
|
||||
|
||||
CronJobが必要なくなったときは、`kubectl delete cronjob <cronjob name>`で削除します。
|
||||
|
||||
```shell
|
||||
kubectl delete cronjob hello
|
||||
```
|
||||
|
||||
CronJobを削除すると、すべてのJobと、そのJobが作成したPodが削除され、追加のJobの作成が停止されます。Jobの削除について詳しく知りたい場合は、[ガベージコレクション](/ja/docs/concepts/workloads/controllers/garbage-collection/)を読んでください。
|
||||
|
||||
## CronJobのspecを書く {#writing-a-cron-job-spec}
|
||||
|
||||
すべてのKubernetesの設定と同じように、CronJobにも`apiVersion`、`kind`、`metadata`のフィールドが必要です。設定ファイルの扱い方についての一般的な情報については、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)と[kubectlを使用してリソースを管理する](/ja/docs/concepts/overview/working-with-objects/object-management/)を読んでください。
|
||||
|
||||
CronJobの設定には、[`.spec`セクション](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)も必要です。
|
||||
|
||||
{{< note >}}
|
||||
CronJobの特に`spec`へのすべての修正は、それ以降の実行にのみ適用されます。
|
||||
{{< /note >}}
|
||||
|
||||
### Schedule
|
||||
|
||||
`.spec.schedule`は、`.spec`には必須のフィールドです。`0 * * * *`や`@hourly`などの[Cron](https://ja.wikipedia.org/wiki/Cron)形式の文字列を取り、Jobの作成と実行のスケジュール時間を指定します。
|
||||
|
||||
フォーマットにはVixie cronのステップ値(step value)も指定できます。[FreeBSDのマニュアル](https://www.freebsd.org/cgi/man.cgi?crontab%285%29)では次のように説明されています。
|
||||
|
||||
> ステップ値は範囲指定と組み合わせて使用できます。範囲の後ろに`/<number>`を付けると、範囲全体で指定したnumberの値ごとにスキップすることを意味します。たとえば、`0-23/2`をhoursフィールドに指定すると、2時間毎にコマンド実行を指定することになります(V7標準では代わりに`0,2,4,6,8,10,12,14,16,18,20,22`と指定する必要があります)。ステップはアスタリスクの後ろにつけることもできます。そのため、「2時間毎に実行」したい場合は、単純に`*/2`と指定できます。
|
||||
|
||||
{{< note >}}
|
||||
スケジュール内の疑問符`?`はアスタリスク`*`と同じ意味を持ちます。つまり、与えられたフィールドには任意の値が使えるという意味になります。
|
||||
{{< /note >}}
|
||||
|
||||
### Job Template
|
||||
|
||||
`.spec.jobTemplate`はJobのテンプレートであり、必須です。[Job](/docs/concepts/workloads/controllers/job/)と完全に同一のスキーマを持ちますが、フィールドがネストされている点と、`apiVersion`と`kind`が存在しない点だけが異なります。Jobの`.spec`を書くための情報については、[JobのSpecを書く](/docs/concepts/workloads/controllers/job/#writing-a-job-spec)を参照してください。
|
||||
|
||||
### Starting Deadline
|
||||
|
||||
`.spec.startingDeadlineSeconds`フィールドはオプションです。何かの理由でスケジュールに間に合わなかった場合に適用される、Jobの開始のデッドライン(締め切り)を秒数で指定します。デッドラインを過ぎると、CronJobはJobを開始しません。この場合にデッドラインに間に合わなかったJobは、失敗したJobとしてカウントされます。もしこのフィールドが指定されなかった場合、Jobはデッドラインを持ちません。
|
||||
|
||||
`.spec.startingDeadlineSeconds`フィールドがnull以外に設定された場合、CronJobコントローラーはJobの作成が期待される時間と現在時刻との間の時間を計測します。もしその差が制限よりも大きかった場合、その実行はスキップされます。
|
||||
|
||||
たとえば、この値が`200`に設定された場合、実際のスケジュールの最大200秒後までに作成されるJobだけが許可されます。
|
||||
|
||||
### Concurrency Policy
|
||||
|
||||
`.spec.concurrencyPolicy`フィールドもオプションです。このフィールドは、このCronJobで作成されたJobの並列実行をどのように扱うかを指定します。specには以下のconcurrency policyのいずれかを指定します。
|
||||
|
||||
* `Allow` (デフォルト): CronJobがJobを並列に実行することを許可します。
|
||||
* `Forbid`: CronJobの並列実行を禁止します。もし新しいJobの実行時に過去のJobがまだ完了していなかった場合、CronJobは新しいJobの実行をスキップします。
|
||||
* `Replace`: もし新しいJobの実行の時間になっても過去のJobの実行が完了していなかった場合、CronJobは現在の実行中のJobを新しいJobで置換します。
|
||||
|
||||
concurrency policyは、同じCronJobが作成したJobにのみ適用されます。もし複数のCronJobがある場合、それぞれのJobの並列実行は常に許可されます。
|
||||
|
||||
### Suspend
|
||||
|
||||
`.spec.suspend`フィールドもオプションです。このフィールドを`true`に設定すると、すべての後続の実行がサスペンド(一時停止)されます。この設定はすでに実行開始したJobには適用されません。デフォルトはfalseです。
|
||||
|
||||
{{< caution >}}
|
||||
スケジュールされた時間中にサスペンドされた実行は、見逃されたJob(missed job)としてカウントされます。[starting deadline](#starting-deadline)が設定されていない既存のCronJob`.spec.suspend`が`true`から`false`に変更されると、見逃されたJobは即座にスケジュールされます。
|
||||
{{< /caution >}}
|
||||
|
||||
### Job History Limit
|
||||
|
||||
`.spec.successfulJobsHistoryLimit`と`.spec.failedJobsHistoryLimit`フィールドはオプションです。これらのフィールドには、完了したJobと失敗したJobをいくつ保持するかを指定します。デフォルトでは、それぞれ3と1に設定されます。リミットを`0`に設定すると、対応する種類のJobを実行完了後に何も保持しなくなります。
|
||||
@@ -33,7 +33,7 @@ kubectl delete pods <pod>
|
||||
|
||||
上記がグレースフルターミネーションにつながるためには、`pod.Spec.TerminationGracePeriodSeconds`に0を指定しては**いけません**。`pod.Spec.TerminationGracePeriodSeconds`を0秒に設定することは安全ではなく、StatefulSet Podには強くお勧めできません。グレースフル削除は安全で、kubeletがapiserverから名前を削除する前にPodが[適切にシャットダウンする](/ja/docs/concepts/workloads/pods/pod-lifecycle/#termination-of-pods)ことを保証します。
|
||||
|
||||
Kubernetes(バージョン1.5以降)は、Nodeにアクセスできないという理由だけでPodを削除しません。到達不能なNodeで実行されているPodは、[タイムアウト](/docs/concepts/architecture/nodes/#node-condition)の後に`Terminating`または`Unknown`状態になります。到達不能なNode上のPodをユーザーが適切に削除しようとすると、Podはこれらの状態に入ることもあります。そのような状態のPodをapiserverから削除することができる唯一の方法は以下の通りです:
|
||||
Kubernetes(バージョン1.5以降)は、Nodeにアクセスできないという理由だけでPodを削除しません。到達不能なNodeで実行されているPodは、[タイムアウト](/ja/docs/concepts/architecture/nodes/#condition)の後に`Terminating`または`Unknown`状態になります。到達不能なNode上のPodをユーザーが適切に削除しようとすると、Podはこれらの状態に入ることもあります。そのような状態のPodをapiserverから削除することができる唯一の方法は以下の通りです:
|
||||
|
||||
* (ユーザーまたは[Node Controller](/ja/docs/concepts/architecture/nodes/)によって)Nodeオブジェクトが削除されます。
|
||||
* 応答していないNodeのkubeletが応答を開始し、Podを終了してapiserverからエントリーを削除します。
|
||||
@@ -76,4 +76,3 @@ StatefulSet Podの強制削除は、常に慎重に、関連するリスクを
|
||||
|
||||
[StatefulSetのデバッグ](/docs/tasks/debug-application-cluster/debug-stateful-set/)の詳細
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,403 @@
|
||||
---
|
||||
title: Horizontal Pod Autoscalerウォークスルー
|
||||
content_type: task
|
||||
weight: 100
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
Horizontal Pod Autoscalerは、Deployment、ReplicaSetまたはStatefulSetといったレプリケーションコントローラ内のPodの数を、観測されたCPU使用率（もしくはベータサポートの、アプリケーションによって提供されるその他のメトリクス）に基づいて自動的にスケールさせます。
|
||||
|
||||
このドキュメントはphp-apacheサーバーに対しHorizontal Pod Autoscalerを有効化するという例に沿ってウォークスルーで説明していきます。Horizontal Pod Autoscalerの動作についてのより詳細な情報を知りたい場合は、[Horizontal Pod Autoscalerユーザーガイド](/docs/tasks/run-application/horizontal-pod-autoscale/)をご覧ください。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
この例ではバージョン1.2以上の動作するKubernetesクラスターおよびkubectlが必要です。
|
||||
[Metrics API](https://github.com/kubernetes/metrics)を介してメトリクスを提供するために、[Metrics server](https://github.com/kubernetes-sigs/metrics-server)によるモニタリングがクラスター内にデプロイされている必要があります。
|
||||
Horizontal Pod Autoscalerはメトリクスを収集するためにこのAPIを利用します。metrics-serverをデプロイする方法を知りたい場合は[metrics-server ドキュメント](https://github.com/kubernetes-sigs/metrics-server#deployment)をご覧ください。
|
||||
|
||||
Horizontal Pod Autoscalerで複数のリソースメトリクスを利用するためには、バージョン1.6以上のKubernetesクラスターおよびkubectlが必要です。カスタムメトリクスを使えるようにするためには、あなたのクラスターがカスタムメトリクスAPIを提供するAPIサーバーと通信できる必要があります。
|
||||
最後に、Kubernetesオブジェクトと関係のないメトリクスを使うにはバージョン1.10以上のKubernetesクラスターおよびkubectlが必要で、さらにあなたのクラスターが外部メトリクスAPIを提供するAPIサーバーと通信できる必要があります。
|
||||
詳細については[Horizontal Pod Autoscaler user guide](/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics)をご覧ください。
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## php-apacheの起動と公開
|
||||
|
||||
Horizontal Pod Autoscalerのデモンストレーションのために、php-apacheイメージをもとにしたカスタムのDockerイメージを使います。
|
||||
このDockerfileは下記のようになっています。
|
||||
|
||||
```dockerfile
|
||||
FROM php:5-apache
|
||||
COPY index.php /var/www/html/index.php
|
||||
RUN chmod a+rx index.php
|
||||
```
|
||||
|
||||
これはCPU負荷の高い演算を行うindex.phpを定義しています。
|
||||
|
||||
```php
|
||||
<?php
|
||||
$x = 0.0001;
|
||||
for ($i = 0; $i <= 1000000; $i++) {
|
||||
$x += sqrt($x);
|
||||
}
|
||||
echo "OK!";
|
||||
?>
|
||||
```
|
||||
|
||||
まず最初に、イメージを動かすDeploymentを起動し、Serviceとして公開しましょう。
|
||||
下記の設定を使います。
|
||||
|
||||
{{< codenew file="application/php-apache.yaml" >}}
|
||||
|
||||
以下のコマンドを実行してください。
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/php-apache.yaml
|
||||
```
|
||||
|
||||
```
|
||||
deployment.apps/php-apache created
|
||||
service/php-apache created
|
||||
```
|
||||
|
||||
## Horizontal Pod Autoscalerを作成する
|
||||
|
||||
サーバーが起動したら、[kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands#autoscale)を使ってautoscalerを作成しましょう。以下のコマンドで、最初のステップで作成したphp-apache deploymentによって制御されるPodレプリカ数を1から10の間に維持するHorizontal Pod Autoscalerを作成します。
|
||||
簡単に言うと、HPAは（Deploymentを通じて）レプリカ数を増減させ、すべてのPodにおける平均CPU使用率を50%（それぞれのPodは`kubectl run`で200 milli-coresを要求しているため、平均CPU使用率100 milli-coresを意味します）に保とうとします。
|
||||
このアルゴリズムについての詳細は[こちら](/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details)をご覧ください。
|
||||
|
||||
```shell
|
||||
kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
|
||||
```
|
||||
|
||||
```
|
||||
horizontalpodautoscaler.autoscaling/php-apache autoscaled
|
||||
```
|
||||
|
||||
以下を実行して現在のAutoscalerの状況を確認できます。
|
||||
|
||||
```shell
|
||||
kubectl get hpa
|
||||
```
|
||||
|
||||
```
|
||||
NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE
|
||||
php-apache Deployment/php-apache/scale 0% / 50% 1 10 1 18s
|
||||
```
|
||||
|
||||
現在はサーバーにリクエストを送っていないため、CPU使用率が0%になっていることに注意してください（`TARGET`カラムは対応するDeploymentによって制御される全てのPodの平均値を示しています。）。
|
||||
|
||||
## 負荷の増加
|
||||
|
||||
Autoscalerがどのように負荷の増加に反応するか見てみましょう。
|
||||
コンテナを作成し、クエリの無限ループをphp-apacheサーバーに送ってみます（これは別のターミナルで実行してください）。
|
||||
|
||||
```shell
|
||||
kubectl run -i --tty load-generator --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"
|
||||
```
|
||||
|
||||
数分以内に、下記を実行することでCPU負荷が高まっていることを確認できます。
|
||||
|
||||
```shell
|
||||
kubectl get hpa
|
||||
```
|
||||
|
||||
```
|
||||
NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE
|
||||
php-apache Deployment/php-apache/scale 305% / 50% 1 10 1 3m
|
||||
```
|
||||
|
||||
ここでは、CPU使用率はrequestの305%にまで高まっています。
|
||||
結果として、Deploymentはレプリカ数7にリサイズされました。
|
||||
|
||||
```shell
|
||||
kubectl get deployment php-apache
|
||||
```
|
||||
|
||||
```
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
php-apache 7/7 7 7 19m
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
レプリカ数が安定するまでは数分かかることがあります。負荷量は何らかの方法で制御されているわけではないので、最終的なレプリカ数はこの例とは異なる場合があります。
|
||||
{{< /note >}}
|
||||
|
||||
## 負荷の停止
|
||||
|
||||
ユーザー負荷を止めてこの例を終わらせましょう。
|
||||
|
||||
私たちが`busybox`イメージを使って作成したコンテナ内のターミナルで、`<Ctrl> + C`を入力して負荷生成を終了させます。
|
||||
|
||||
そして結果の状態を確認します（数分後）。
|
||||
|
||||
```shell
|
||||
kubectl get hpa
|
||||
```
|
||||
|
||||
```
|
||||
NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE
|
||||
php-apache Deployment/php-apache/scale 0% / 50% 1 10 1 11m
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl get deployment php-apache
|
||||
```
|
||||
|
||||
```
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
php-apache 1/1 1 1 27m
|
||||
```
|
||||
|
||||
ここでCPU使用率は0に下がり、HPAによってオートスケールされたレプリカ数は1に戻ります。
|
||||
|
||||
{{< note >}}
|
||||
レプリカのオートスケールには数分かかることがあります。
|
||||
{{< /note >}}
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
## 複数のメトリクスやカスタムメトリクスを基にオートスケーリングする
|
||||
|
||||
`autoscaling/v2beta2` APIバージョンと使うと、`php-apache` Deploymentをオートスケーリングする際に使う追加のメトリクスを導入することが出来ます。
|
||||
|
||||
まず、`autoscaling/v2beta2`内のHorizontalPodAutoscalerのYAMLファイルを入手します。
|
||||
|
||||
```shell
|
||||
kubectl get hpa.v2beta2.autoscaling -o yaml > /tmp/hpa-v2.yaml
|
||||
```
|
||||
|
||||
`/tmp/hpa-v2.yaml`ファイルをエディタで開くと、以下のようなYAMLファイルが見えるはずです。
|
||||
|
||||
```yaml
|
||||
apiVersion: autoscaling/v2beta2
|
||||
kind: HorizontalPodAutoscaler
|
||||
metadata:
|
||||
name: php-apache
|
||||
spec:
|
||||
scaleTargetRef:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
name: php-apache
|
||||
minReplicas: 1
|
||||
maxReplicas: 10
|
||||
metrics:
|
||||
- type: Resource
|
||||
resource:
|
||||
name: cpu
|
||||
target:
|
||||
type: Utilization
|
||||
averageUtilization: 50
|
||||
status:
|
||||
observedGeneration: 1
|
||||
lastScaleTime: <some-time>
|
||||
currentReplicas: 1
|
||||
desiredReplicas: 1
|
||||
currentMetrics:
|
||||
- type: Resource
|
||||
resource:
|
||||
name: cpu
|
||||
current:
|
||||
averageUtilization: 0
|
||||
averageValue: 0
|
||||
```
|
||||
|
||||
`targetCPUUtilizationPercentage`フィールドは`metrics`と呼ばれる配列に置換されています。
|
||||
CPU使用率メトリクスは、Podコンテナで定められたリソースの割合として表されるため、*リソースメトリクス*です。CPU以外のリソースメトリクスを指定することもできます。デフォルトでは、他にメモリだけがリソースメトリクスとしてサポートされています。これらのリソースはクラスター間で名前が変わることはなく、そして`metrics.k8s.io` APIが利用可能である限り常に利用可能です。
|
||||
|
||||
さらに`target.type`において`Utilization`の代わりに`AverageValue`を使い、`target.averageUtilization`フィールドの代わりに対応する`target.averageValue`フィールドを設定することで、リソースメトリクスをrequest値に対する割合に代わり、直接的な値に設定することも可能です。
|
||||
|
||||
PodメトリクスとObjectメトリクスという2つの異なる種類のメトリクスが存在し、どちらも*カスタムメトリクス*とみなされます。これらのメトリクスはクラスター特有の名前を持ち、利用するにはより発展的なクラスター監視設定が必要となります。
|
||||
|
||||
これらの代替メトリクスタイプのうち、最初のものが*Podメトリクス*です。これらのメトリクスはPodを説明し、Podを渡って平均され、レプリカ数を決定するためにターゲット値と比較されます。
|
||||
これらはほとんどリソースメトリクス同様に機能しますが、`target`の種類としては`AverageValue`*のみ*をサポートしている点が異なります。
|
||||
|
||||
Podメトリクスはmetricブロックを使って以下のように指定されます。
|
||||
|
||||
```yaml
|
||||
type: Pods
|
||||
pods:
|
||||
metric:
|
||||
name: packets-per-second
|
||||
target:
|
||||
type: AverageValue
|
||||
averageValue: 1k
|
||||
```
|
||||
|
||||
2つ目のメトリクスタイプは*Objectメトリクス*です。これらのメトリクスはPodを説明するかわりに、同一Namespace内の異なったオブジェクトを説明します。このメトリクスはオブジェクトから取得される必要はありません。単に説明するだけです。Objectメトリクスは`target`の種類として`Value`と`AverageValue`をサポートします。`Value`では、ターゲットはAPIから返ってきたメトリクスと直接比較されます。`AverageValue`では、カスタムメトリクスAPIから返ってきた値はターゲットと比較される前にPodの数で除算されます。以下の例は`requests-per-second`メトリクスのYAML表現です。
|
||||
|
||||
```yaml
|
||||
type: Object
|
||||
object:
|
||||
metric:
|
||||
name: requests-per-second
|
||||
describedObject:
|
||||
apiVersion: networking.k8s.io/v1beta1
|
||||
kind: Ingress
|
||||
name: main-route
|
||||
target:
|
||||
type: Value
|
||||
value: 2k
|
||||
```
|
||||
|
||||
もしこのようなmetricブロックを複数提供した場合、HorizontalPodAutoscalerはこれらのメトリクスを順番に処理します。
|
||||
HorizontalPodAutoscalerはそれぞれのメトリクスについて推奨レプリカ数を算出し、その中で最も多いレプリカ数を採用します。
|
||||
|
||||
例えば、もしあなたがネットワークトラフィックについてのメトリクスを収集する監視システムを持っているなら、`kubectl edit`を使って指定を次のように更新することができます。
|
||||
|
||||
```yaml
|
||||
apiVersion: autoscaling/v2beta2
|
||||
kind: HorizontalPodAutoscaler
|
||||
metadata:
|
||||
name: php-apache
|
||||
spec:
|
||||
scaleTargetRef:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
name: php-apache
|
||||
minReplicas: 1
|
||||
maxReplicas: 10
|
||||
metrics:
|
||||
- type: Resource
|
||||
resource:
|
||||
name: cpu
|
||||
target:
|
||||
type: Utilization
|
||||
averageUtilization: 50
|
||||
- type: Pods
|
||||
pods:
|
||||
metric:
|
||||
name: packets-per-second
|
||||
target:
|
||||
type: AverageValue
|
||||
averageValue: 1k
|
||||
- type: Object
|
||||
object:
|
||||
metric:
|
||||
name: requests-per-second
|
||||
describedObject:
|
||||
apiVersion: networking.k8s.io/v1beta1
|
||||
kind: Ingress
|
||||
name: main-route
|
||||
target:
|
||||
type: Value
|
||||
value: 10k
|
||||
status:
|
||||
observedGeneration: 1
|
||||
lastScaleTime: <some-time>
|
||||
currentReplicas: 1
|
||||
desiredReplicas: 1
|
||||
currentMetrics:
|
||||
- type: Resource
|
||||
resource:
|
||||
name: cpu
|
||||
current:
|
||||
averageUtilization: 0
|
||||
averageValue: 0
|
||||
- type: Object
|
||||
object:
|
||||
metric:
|
||||
name: requests-per-second
|
||||
describedObject:
|
||||
apiVersion: networking.k8s.io/v1beta1
|
||||
kind: Ingress
|
||||
name: main-route
|
||||
current:
|
||||
value: 10k
|
||||
```
|
||||
|
||||
この時、HorizontalPodAutoscalerはそれぞれのPodがCPU requestの50%を使い、1秒当たり1000パケットを送信し、そしてmain-route
|
||||
Ingressの裏にあるすべてのPodが合計で1秒当たり10000パケットを送信する状態を保持しようとします。
|
||||
|
||||
### より詳細なメトリクスをもとにオートスケーリングする
|
||||
|
||||
多くのメトリクスパイプラインは、名前もしくは _labels_ と呼ばれる追加の記述子の組み合わせによって説明することができます。全てのリソースメトリクス以外のメトリクスタイプ（Pod、Object、そして下で説明されている外部メトリクス）において、メトリクスパイプラインに渡す追加のラベルセレクターを指定することができます。例えば、もしあなたが`http_requests`メトリクスを`verb`ラベルとともに収集しているなら、下記のmetricブロックを指定してGETリクエストにのみ基づいてスケールさせることができます。
|
||||
|
||||
```yaml
|
||||
type: Object
|
||||
object:
|
||||
metric:
|
||||
name: http_requests
|
||||
selector: {matchLabels: {verb: GET}}
|
||||
```
|
||||
|
||||
このセレクターは完全なKubernetesラベルセレクターと同じ文法を利用します。もし名前とセレクターが複数の系列に一致した場合、この監視パイプラインはどのようにして複数の系列を一つの値にまとめるかを決定します。このセレクターは付加的なもので、ターゲットオブジェクト（`Pods`タイプの場合は対象Pod、`Object`タイプの場合は説明されるオブジェクト）では**ない**オブジェクトを説明するメトリクスを選択することは出来ません。
|
||||
|
||||
### Kubernetesオブジェクトと関係ないメトリクスに基づいたオートスケーリング
|
||||
|
||||
Kubernetes上で動いているアプリケーションを、Kubernetes Namespaceと直接的な関係がないサービスを説明するメトリクスのような、Kubernetesクラスター内のオブジェクトと明確な関係が無いメトリクスを基にオートスケールする必要があるかもしれません。Kubernetes 1.10以降では、このようなユースケースを*外部メトリクス*によって解決できます。
|
||||
|
||||
外部メトリクスを使うにはあなたの監視システムについての知識が必要となります。この設定はカスタムメトリクスを使うときのものに似ています。外部メトリクスを使うとあなたの監視システムのあらゆる利用可能なメトリクスに基づいてクラスターをオートスケールできるようになります。上記のように`metric`ブロックで`name`と`selector`を設定し、`Object`のかわりに`External`メトリクスタイプを使います。
|
||||
もし複数の時系列が`metricSelector`により一致した場合は、それらの値の合計がHorizontalPodAutoscalerに使われます。
|
||||
外部メトリクスは`Value`と`AverageValue`の両方のターゲットタイプをサポートしています。これらの機能は`Object`タイプを利用するときとまったく同じです。
|
||||
|
||||
例えばもしあなたのアプリケーションがホストされたキューサービスからのタスクを処理している場合、あなたは下記のセクションをHorizontalPodAutoscalerマニフェストに追記し、未処理のタスク30個あたり1つのワーカーを必要とすることを指定します。
|
||||
|
||||
```yaml
|
||||
- type: External
|
||||
external:
|
||||
metric:
|
||||
name: queue_messages_ready
|
||||
selector: "queue=worker_tasks"
|
||||
target:
|
||||
type: AverageValue
|
||||
averageValue: 30
|
||||
```
|
||||
|
||||
可能なら、クラスター管理者がカスタムメトリクスAPIを保護することを簡単にするため、外部メトリクスのかわりにカスタムメトリクスを用いることが望ましいです。外部メトリクスAPIは潜在的に全てのメトリクスへのアクセスを許可するため、クラスター管理者はこれを公開する際には注意が必要です。
|
||||
|
||||
## 付録: Horizontal Pod Autoscaler status conditions
|
||||
|
||||
`autoscaling/v2beta2`形式のHorizontalPodAutoscalerを使っている場合は、KubernetesによるHorizontalPodAutoscaler上の*status conditions*セットを見ることができます。status conditionsはHorizontalPodAutoscalerがスケール可能かどうか、そして現時点でそれが何らかの方法で制限されているかどうかを示しています。
|
||||
|
||||
このconditionsは`status.conditions`フィールドに現れます。HorizontalPodAutoscalerに影響しているconditionsを確認するために、`kubectl describe hpa`を利用できます。
|
||||
|
||||
```shell
|
||||
kubectl describe hpa cm-test
|
||||
```
|
||||
|
||||
```
|
||||
Name: cm-test
|
||||
Namespace: prom
|
||||
Labels: <none>
|
||||
Annotations: <none>
|
||||
CreationTimestamp: Fri, 16 Jun 2017 18:09:22 +0000
|
||||
Reference: ReplicationController/cm-test
|
||||
Metrics: ( current / target )
|
||||
"http_requests" on pods: 66m / 500m
|
||||
Min replicas: 1
|
||||
Max replicas: 4
|
||||
ReplicationController pods: 1 current / 1 desired
|
||||
Conditions:
|
||||
Type Status Reason Message
|
||||
---- ------ ------ -------
|
||||
AbleToScale True ReadyForNewScale the last scale time was sufficiently old as to warrant a new scale
|
||||
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from pods metric http_requests
|
||||
ScalingLimited False DesiredWithinRange the desired replica count is within the acceptable range
|
||||
Events:
|
||||
```
|
||||
|
||||
このHorizontalPodAutoscalerにおいて、いくつかの正常な状態のconditionsを見ることができます。まず最初に、`AbleToScale`は、HPAがスケール状況を取得し、更新させることが出来るかどうかだけでなく、何らかのbackoffに関連した状況がスケーリングを妨げていないかを示しています。2番目に、`ScalingActive`は、HPAが有効化されているかどうか（例えば、レプリカ数のターゲットがゼロでないこと）や、望ましいスケールを算出できるかどうかを示します。もしこれが`False`の場合、大体はメトリクスの取得において問題があることを示しています。最後に、一番最後の状況である`ScalingLimited`は、HorizontalPodAutoscalerの最大値や最小値によって望ましいスケールがキャップされていることを示しています。この指標を見てHorizontalPodAutoscaler上の最大・最小レプリカ数制限を増やす、もしくは減らす検討ができます。
|
||||
|
||||
## 付録: 数量
|
||||
|
||||
全てのHorizontalPodAutoscalerおよびメトリクスAPIにおけるメトリクスは{{< glossary_tooltip term_id="quantity" text="quantity">}}として知られる特殊な整数表記によって指定されます。例えば、`10500m`という数量は10進数表記で`10.5`と書くことができます。メトリクスAPIは可能であれば接尾辞を用いない整数を返し、そうでない場合は基本的にミリ単位での数量を返します。これはメトリクス値が`1`と`1500m`の間で、もしくは10進法表記で書かれた場合は`1`と`1.5`の間で変動するということを意味します。
|
||||
|
||||
## 付録: その他の起きうるシナリオ
|
||||
|
||||
### Autoscalerを宣言的に作成する
|
||||
|
||||
`kubectl autoscale`コマンドを使って命令的にHorizontalPodAutoscalerを作るかわりに、下記のファイルを使って宣言的に作成することができます。
|
||||
|
||||
{{< codenew file="application/hpa/php-apache.yaml" >}}
|
||||
|
||||
下記のコマンドを実行してAutoscalerを作成します。
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/examples/application/hpa/php-apache.yaml
|
||||
```
|
||||
|
||||
```
|
||||
horizontalpodautoscaler.autoscaling/php-apache created
|
||||
```
|
||||
@@ -49,7 +49,6 @@ Kubernetes Deploymentオブジェクトを作成することでアプリケー
|
||||
|
||||
出力はこのようになります:
|
||||
|
||||
user@computer:~/website$ kubectl describe deployment nginx-deployment
|
||||
Name: nginx-deployment
|
||||
Namespace: default
|
||||
CreationTimestamp: Tue, 30 Aug 2016 18:11:37 -0700
|
||||
|
||||
@@ -33,7 +33,7 @@ Helmをインストールし、以下のコマンドを実行することでロ
|
||||
|
||||
|
||||
```shell
|
||||
helm repo add svc-cat https://svc-catalog-charts.storage.googleapis.com
|
||||
helm repo add svc-cat https://kubernetes-sigs.github.io/service-catalog
|
||||
```
|
||||
|
||||
以下のコマンドを実行し、インストールに成功していることを確認します。
|
||||
|
||||
@@ -17,7 +17,7 @@ Kubernetesのコマンドラインツール`kubectl`を使用すると、Kuberne
|
||||
|
||||
[Minikube](https://minikube.sigs.k8s.io/)は、Kubernetesをローカルで実行するツールです。MinikubeはシングルノードのKubernetesクラスターをパーソナルコンピューター上(Windows、macOS、Linux PCを含む)で実行することで、Kubernetesを試したり、日常的な開発作業のために利用できます。
|
||||
|
||||
ツールのインストールについて知りたい場合は、公式の[Get Started!](https://minikube.sigs.k8s.io/docs/start/)のガイドに従うか、[Minikubeのインストール](/ja/docs/tasks/tools/install-minikube/)を読んでください。
|
||||
ツールのインストールについて知りたい場合は、公式の[Get Started!](https://minikube.sigs.k8s.io/docs/start/)のガイドに従ってください。
|
||||
|
||||
Minikubeが起動したら、[サンプルアプリケーションの実行](/ja/docs/tutorials/hello-minikube/)を試すことができます。
|
||||
|
||||
|
||||
@@ -502,7 +502,7 @@ compinit
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [Minikubeをインストールする](/ja/docs/tasks/tools/install-minikube/)
|
||||
* [Minikubeをインストールする](https://minikube.sigs.k8s.io/docs/start/)
|
||||
* クラスターの作成に関する詳細を[スタートガイド](/ja/docs/setup/)で確認する
|
||||
* [アプリケーションを起動して公開する方法を学ぶ](/ja/docs/tasks/access-application-cluster/service-access-application-cluster/)
|
||||
* あなたが作成していないクラスターにアクセスする必要がある場合は、[クラスターアクセスドキュメントの共有](/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)を参照してください
|
||||
|
||||
@@ -1,267 +0,0 @@
|
||||
---
|
||||
title: Minikubeのインストール
|
||||
content_type: task
|
||||
weight: 20
|
||||
card:
|
||||
name: tasks
|
||||
weight: 10
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
このページでは[Minikube](/ja/docs/tutorials/hello-minikube)のインストール方法を説明し、コンピューターの仮想マシン上で単一ノードのKubernetesクラスターを実行します。
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< tabs name="minikube_before_you_begin" >}}
|
||||
{{% tab name="Linux" %}}
|
||||
Linuxで仮想化がサポートされているかどうかを確認するには、次のコマンドを実行して、出力が空でないことを確認します:
|
||||
```
|
||||
grep -E --color 'vmx|svm' /proc/cpuinfo
|
||||
```
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="macOS" %}}
|
||||
仮想化がmacOSでサポートされているかどうかを確認するには、ターミナルで次のコマンドを実行します。
|
||||
```
|
||||
sysctl -a | grep -E --color 'machdep.cpu.features|VMX'
|
||||
```
|
||||
出力に`VMX`が表示されている場合(色付けされているはずです)、VT-x機能がマシンで有効になっています。
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="Windows" %}}
|
||||
Windows 8以降で仮想化がサポートされているかどうかを確認するには、Windowsターミナルまたはコマンドプロンプトで次のコマンドを実行します。
|
||||
```
|
||||
systeminfo
|
||||
```
|
||||
次の出力が表示される場合、仮想化はWindowsでサポートされています。
|
||||
```
|
||||
Hyper-V Requirements: VM Monitor Mode Extensions: Yes
|
||||
Virtualization Enabled In Firmware: Yes
|
||||
Second Level Address Translation: Yes
|
||||
Data Execution Prevention Available: Yes
|
||||
```
|
||||
|
||||
次の出力が表示される場合、システムにはすでにHypervisorがインストールされており、次の手順をスキップできます。
|
||||
```
|
||||
Hyper-V Requirements: A hypervisor has been detected. Features required for Hyper-V will not be displayed.
|
||||
```
|
||||
|
||||
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## minikubeのインストール
|
||||
|
||||
{{< tabs name="tab_with_md" >}}
|
||||
{{% tab name="Linux" %}}
|
||||
|
||||
### kubectlのインストール
|
||||
|
||||
kubectlがインストールされていることを確認してください。
|
||||
[kubectlのインストールとセットアップ](/ja/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux)の指示に従ってkubectlをインストールできます。
|
||||
|
||||
### ハイパーバイザーのインストール
|
||||
|
||||
ハイパーバイザーがまだインストールされていない場合は、これらのいずれかをインストールしてください:
|
||||
|
||||
• [KVM](https://www.linux-kvm.org/)、ただしQEMUも使っているもの
|
||||
|
||||
• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
|
||||
|
||||
Minikubeは、VMではなくホストでKubernetesコンポーネントを実行する`--driver=none`オプションもサポートしています。
|
||||
このドライバーを使用するには、[Docker](https://www.docker.com/products/docker-desktop)とLinux環境が必要ですが、ハイパーバイザーは不要です。
|
||||
|
||||
Debian系のLinuxで`none`ドライバーを使用する場合は、snapパッケージではなく`.deb`パッケージを使用してDockerをインストールしてください。snapパッケージはMinikubeでは機能しません。
|
||||
[Docker](https://www.docker.com/products/docker-desktop)から`.deb`パッケージをダウンロードできます。
|
||||
|
||||
{{< caution >}}
|
||||
`none` VMドライバーは、セキュリティとデータ損失の問題を引き起こす可能性があります。
|
||||
`--driver=none`を使用する前に、詳細について[このドキュメント](https://minikube.sigs.k8s.io/docs/reference/drivers/none/) を参照してください。
|
||||
{{< /caution >}}
|
||||
|
||||
MinikubeはDockerドライバーと似たような`vm-driver=podman`もサポートしています。Podmanを特権ユーザー権限(root user)で実行することは、コンテナがシステム上の利用可能な機能へ完全にアクセスするための最もよい方法です。
|
||||
|
||||
{{< caution >}}
|
||||
`podman` ドライバーは、rootでコンテナを実行する必要があります。これは、通常のユーザーアカウントが、コンテナの実行に必要とされるすべてのOS機能への完全なアクセスを持っていないためです。
|
||||
{{< /caution >}}
|
||||
|
||||
### パッケージを利用したMinikubeのインストール
|
||||
|
||||
Minikubeの*Experimental*パッケージが利用可能です。
|
||||
GitHubのMinikubeの[リリース](https://github.com/kubernetes/minikube/releases)ページからLinux(AMD64)パッケージを見つけることができます。
|
||||
|
||||
Linuxのディストリビューションのパッケージツールを使用して、適切なパッケージをインストールしてください。
|
||||
|
||||
### 直接ダウンロードによるMinikubeのインストール
|
||||
|
||||
パッケージ経由でインストールしない場合は、スタンドアロンバイナリをダウンロードして使用できます。
|
||||
|
||||
```shell
|
||||
curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 \
|
||||
&& chmod +x minikube
|
||||
```
|
||||
|
||||
Minikube実行可能バイナリをパスに追加する簡単な方法を次に示します:
|
||||
|
||||
```shell
|
||||
sudo mkdir -p /usr/local/bin/
|
||||
sudo install minikube /usr/local/bin/
|
||||
```
|
||||
|
||||
### Homebrewを利用したMinikubeのインストール
|
||||
|
||||
別の選択肢として、Linux [Homebrew](https://docs.brew.sh/Homebrew-on-Linux)を利用してインストールできます。
|
||||
|
||||
```shell
|
||||
brew install minikube
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="macOS" %}}
|
||||
### kubectlのインストール
|
||||
|
||||
kubectlがインストールされていることを確認してください。
|
||||
[kubectlのインストールとセットアップ](/ja/docs/tasks/tools/install-kubectl/#install-kubectl-on-macos)の指示に従ってkubectlをインストールできます。
|
||||
|
||||
### ハイパーバイザーのインストール
|
||||
|
||||
ハイパーバイザーがまだインストールされていない場合は、これらのいずれかをインストールしてください:
|
||||
|
||||
• [HyperKit](https://github.com/moby/hyperkit)
|
||||
|
||||
• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
|
||||
|
||||
• [VMware Fusion](https://www.vmware.com/products/fusion)
|
||||
|
||||
### Minikubeのインストール
|
||||
[Homebrew](https://brew.sh)を使うことでmacOSにMinikubeを簡単にインストールできます:
|
||||
|
||||
```shell
|
||||
brew install minikube
|
||||
```
|
||||
|
||||
スタンドアロンのバイナリをダウンロードして、macOSにインストールすることもできます:
|
||||
|
||||
```shell
|
||||
curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64 \
|
||||
&& chmod +x minikube
|
||||
```
|
||||
|
||||
Minikube実行可能バイナリをパスに追加する簡単な方法を次に示します:
|
||||
|
||||
```shell
|
||||
sudo mv minikube /usr/local/bin
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="Windows" %}}
|
||||
### kubectlのインストール
|
||||
|
||||
kubectlがインストールされていることを確認してください。
|
||||
[kubectlのインストールとセットアップ](/ja/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows)の指示に従ってkubectlをインストールできます。
|
||||
|
||||
### ハイパーバイザーのインストール
|
||||
|
||||
ハイパーバイザーがまだインストールされていない場合は、これらのいずれかをインストールしてください:
|
||||
|
||||
• [Hyper-V](https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/quick_start/walkthrough_install)
|
||||
|
||||
• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
|
||||
|
||||
{{< note >}}
|
||||
Hyper-Vは、Windows 10 Enterprise、Windows 10 Professional、Windows 10 Educationの3つのバージョンのWindows 10で実行できます。
|
||||
{{< /note >}}
|
||||
|
||||
### Chocolateyを使用したMinikubeのインストール
|
||||
|
||||
[Chocolatey](https://chocolatey.org/)を使うことでWindowsにMinikubeを簡単にインストールできます(管理者権限で実行する必要があります)。
|
||||
|
||||
```shell
|
||||
choco install minikube
|
||||
```
|
||||
|
||||
Minikubeのインストールが終わったら、現在のCLIのセッションを終了して再起動します。Minikubeは自動的にパスに追加されます。
|
||||
|
||||
### インストーラーを使用したMinikubeのインストール
|
||||
|
||||
[Windowsインストーラー](https://docs.microsoft.com/en-us/windows/desktop/msi/windows-installer-portal)を使用してWindowsにMinikubeを手動でインストールするには、[`minikube-installer.exe`](https://github.com/kubernetes/minikube/releases/latest/download/minikube-installer.exe)をダウンロードしてインストーラーを実行します。
|
||||
|
||||
### 直接ダウンロードによるMinikubeのインストール
|
||||
|
||||
WindowsにMinikubeを手動でインストールするには、[`minikube-windows-amd64`](https://github.com/kubernetes/minikube/releases/latest)をダウンロードし、名前を`minikube.exe`に変更して、パスに追加します。
|
||||
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
|
||||
## インストールの確認
|
||||
|
||||
ハイパーバイザーとMinikube両方のインストール成功を確認するため、以下のコマンドをローカルKubernetesクラスターを起動するために実行してください:
|
||||
|
||||
{{< note >}}
|
||||
|
||||
`minikube start`で`--driver`の設定をするため、次の`<driver_name>`の部分では、インストールしたハイパーバイザーの名前を小文字で入力してください。`--driver`値のすべてのリストは、[specifying the VM driver documentation](/docs/setup/learning-environment/minikube/#specifying-the-vm-driver)で確認できます。
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
{{< caution >}}
|
||||
KVMを使用する場合、Debianおよび他の一部のシステムでのlibvirtのデフォルトのQEMU URIは`qemu:///session`であるのに対し、MinikubeのデフォルトのQEMU URIは`qemu:///system`であることに注意してください。これがあなたのシステムに当てはまる場合、`--kvm-qemu-uri qemu:///session`を`minikube start`に渡す必要があります。
|
||||
{{< /caution >}}
|
||||
|
||||
```shell
|
||||
minikube start --driver=<driver_name>
|
||||
```
|
||||
|
||||
`minikube start`が完了した場合、次のコマンドを実行してクラスターの状態を確認します。
|
||||
|
||||
```shell
|
||||
minikube status
|
||||
```
|
||||
|
||||
クラスターが起動していると、`minikube status`の出力はこのようになります。
|
||||
|
||||
```
|
||||
host: Running
|
||||
kubelet: Running
|
||||
apiserver: Running
|
||||
kubeconfig: Configured
|
||||
```
|
||||
|
||||
選択したハイパーバイザーでMinikubeが動作しているか確認した後は、そのままMinikubeを使い続けることもできます。また、クラスターを停止することもできます。クラスターを停止するためには、次を実行してください。
|
||||
|
||||
```shell
|
||||
minikube stop
|
||||
```
|
||||
|
||||
## ローカル状態のクリーンアップ {#cleanup-local-state}
|
||||
|
||||
もし以前に Minikubeをインストールしていたら、以下のコマンドを実行します。
|
||||
```shell
|
||||
minikube start
|
||||
```
|
||||
|
||||
`minikube start`はエラーを返します。
|
||||
```shell
|
||||
machine does not exist
|
||||
```
|
||||
|
||||
minikubeのローカル状態をクリアする必要があります:
|
||||
```shell
|
||||
minikube delete
|
||||
```
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [Minikubeを使ってローカルでKubernetesを実行する](/ja/docs/setup/learning-environment/minikube/)
|
||||
|
||||
Reference in New Issue
Block a user