commit first work from 1.19 milestone

This commit is contained in:
inductor
2021-05-26 10:10:10 +00:00
parent 6866260642
commit 73b3cf8784
134 changed files with 4305 additions and 2983 deletions
+5 -5
View File
@@ -16,8 +16,8 @@ content_type: concept
## APIリファレンス
* [Kubernetes API概要](/docs/reference/using-api/api-overview/) - Kubernetes APIの概要です。
* [Kubernetes APIリファレンス {{< param "version" >}}](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
* [Kubernetes API概要](/docs/reference/using-api/) - Kubernetes APIの概要です。
* [Kubernetes APIリファレンス {{< latest-version >}}](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/)
## APIクライアントライブラリー
@@ -30,9 +30,9 @@ content_type: concept
## CLIリファレンス
* [kubectl](/docs/reference/kubectl/overview/) - コマンドの実行やKubernetesクラスターの管理に使う主要なCLIツールです。
* [JSONPath](/docs/reference/kubectl/jsonpath/) - kubectlで[JSONPath記法](https://goessner.net/articles/JsonPath/)を使うための構文ガイドです。
* [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) - セキュアなKubernetesクラスターを簡単にプロビジョニングするためのCLIツールです。
* [kubectl](/ja/docs/reference/kubectl/overview/) - コマンドの実行やKubernetesクラスターの管理に使う主要なCLIツールです。
* [JSONPath](/ja/docs/reference/kubectl/jsonpath/) - kubectlで[JSONPath記法](https://goessner.net/articles/JsonPath/)を使うための構文ガイドです。
* [kubeadm](ja/docs/reference/setup-tools/kubeadm/) - セキュアなKubernetesクラスターを簡単にプロビジョニングするためのCLIツールです。
## コンポーネントリファレンス
@@ -43,7 +43,7 @@ ClusterRolesにはいくつかの用途があります。ClusterRoleを利用し
2. Namespaceに属するリソースに対する権限を定義し、すべてのNamespaceにわたって付与する
3. クラスター単位でスコープされているリソースに対するアクセス許可を定義する
NamespaceでRoleを定義する場合は、Roleを使用します。クラスター全体でRoleを定義するは、ClusterRoleを使用します
NamespaceでRoleを定義する場合は、Roleを使用します。クラスター全体でRoleを定義する場合は、ClusterRoleを使用します
#### Roleの例
@@ -137,7 +137,8 @@ content_type: concept
| `TokenRequestProjection` | `false` | Alpha | 1.11 | 1.11 |
| `TokenRequestProjection` | `true` | Beta | 1.12 | |
| `TTLAfterFinished` | `false` | Alpha | 1.12 | |
| `TopologyManager` | `false` | Alpha | 1.16 | |
| `TopologyManager` | `false` | Alpha | 1.16 | 1.17 |
| `TopologyManager` | `true` | Beta | 1.18 | |
| `ValidateProxyRedirects` | `false` | Alpha | 1.12 | 1.13 |
| `ValidateProxyRedirects` | `true` | Beta | 1.14 | |
| `VolumePVCDataSource` | `false` | Alpha | 1.15 | 1.15 |
@@ -202,6 +203,7 @@ content_type: concept
| `DynamicProvisioningScheduling` | - | Deprecated| 1.12 | - |
| `DynamicVolumeProvisioning` | `true` | Alpha | 1.3 | 1.7 |
| `DynamicVolumeProvisioning` | `true` | GA | 1.8 | - |
| `EnableAggregatedDiscoveryTimeout` | `true` | Deprecated | 1.16 | - |
| `EnableEquivalenceClassCache` | `false` | Alpha | 1.8 | 1.14 |
| `EnableEquivalenceClassCache` | - | Deprecated | 1.15 | - |
| `ExperimentalCriticalPodAnnotation` | `false` | Alpha | 1.5 | 1.12 |
@@ -0,0 +1,83 @@
---
title: Kubelet 認証/認可
---
## 概要
kubeletのHTTPSエンドポイントは、さまざまな感度のデータへのアクセスを提供するAPIを公開し、
ノードとコンテナ内のさまざまなレベルの権限でタスクを実行できるようにします。
このドキュメントでは、kubeletのHTTPSエンドポイントへのアクセスを認証および承認する方法について説明します。
## Kubelet 認証
デフォルトでは、他の構成済み認証方法によって拒否されないkubeletのHTTPSエンドポイントへのリクエストは
匿名リクエストとして扱われ、ユーザー名は`system:anonymous`
グループは`system:unauthenticated`になります。
匿名アクセスを無効にし、認証されていないリクエストに対して`401 Unauthorized`応答を送信するには:
* `--anonymous-auth=false`フラグでkubeletを開始します。
kubeletのHTTPSエンドポイントに対するX509クライアント証明書認証を有効にするには:
* `--client-ca-file`フラグでkubeletを起動し、クライアント証明書を確認するためのCAバンドルを提供します。
* `--kubelet-client-certificate`および`--kubelet-client-key`フラグを使用してapiserverを起動します。
* 詳細については、[apiserver認証ドキュメント](/ja/docs/reference/access-authn-authz/authentication/#x509-client-certs)を参照してください。
APIベアラートークン(サービスアカウントトークンを含む)を使用して、kubeletのHTTPSエンドポイントへの認証を行うには:
* APIサーバーで`authentication.k8s.io/v1beta1`グループが有効になっていることを確認します。
* `--authentication-token-webhook`および`--kubeconfig`フラグを使用してkubeletを開始します。
* kubeletは、構成済みのAPIサーバーで `TokenReview` APIを呼び出して、ベアラートークンからユーザー情報を判別します。
## Kubelet 承認
認証に成功した要求(匿名要求を含む)はすべて許可されます。デフォルトの認可モードは、すべての要求を許可する`AlwaysAllow`です。
kubelet APIへのアクセスを細分化するのは、次のような多くの理由が考えられます:
* 匿名認証は有効になっていますが、匿名ユーザーがkubeletのAPIを呼び出す機能は制限する必要があります。
* ベアラートークン認証は有効になっていますが、kubeletのAPIを呼び出す任意のAPIユーザー(サービスアカウントなど)の機能を制限する必要があります。
* クライアント証明書の認証は有効になっていますが、構成されたCAによって署名されたクライアント証明書の一部のみがkubeletのAPIの使用を許可されている必要があります。
kubeletのAPIへのアクセスを細分化するには、APIサーバーに承認を委任します:
* APIサーバーで`authorization.k8s.io/v1beta1` APIグループが有効になっていることを確認します。
* `--authorization-mode=Webhook``--kubeconfig`フラグでkubeletを開始します。
* kubeletは、構成されたAPIサーバーで`SubjectAccessReview` APIを呼び出して、各リクエストが承認されているかどうかを判断します。
kubeletは、apiserverと同じ[リクエスト属性](/docs/reference/access-authn-authz/authorization/#review-your-request-attributes)アプローチを使用してAPIリクエストを承認します。
動詞は、受けとったリクエストのHTTP動詞から決定されます:
HTTP動詞 | 要求 動詞
----------|---------------
POST | create
GET, HEAD | get
PUT | update
PATCH | patch
DELETE | delete
リソースとサブリソースは、受けとったリクエストのパスから決定されます:
Kubelet API | リソース | サブリソース
-------------|----------|------------
/stats/\* | nodes | stats
/metrics/\* | nodes | metrics
/logs/\* | nodes | log
/spec/\* | nodes | spec
*all others* | nodes | proxy
名前空間とAPIグループの属性は常に空の文字列であり、
リソース名は常にkubeletの`Node` APIオブジェクトの名前です。
このモードで実行する場合は、apiserverに渡される`--kubelet-client-certificate`フラグと`--kubelet-client-key`
フラグで識別されるユーザーが次の属性に対して許可されていることを確認します:
* verb=\*, resource=nodes, subresource=proxy
* verb=\*, resource=nodes, subresource=stats
* verb=\*, resource=nodes, subresource=log
* verb=\*, resource=nodes, subresource=spec
* verb=\*, resource=nodes, subresource=metrics
@@ -2,7 +2,7 @@
title: APIサーバー
id: kube-apiserver
date: 2018-04-12
full_link: /docs/reference/generated/kube-apiserver/
full_link: /docs/concepts/overview/components/#kube-apiserver
short_description: >
Kubernetes APIを提供するコントロールプレーンのコンポーネントです。
@@ -0,0 +1,19 @@
---
title: ワークロード
id: workloads
date: 2019-02-13
full_link: /docs/concepts/workloads/
short_description: >
ワークロードとは、Kubernetes上で実行中のアプリケーションです。
aka:
tags:
- fundamental
---
ワークロードとは、Kubernetes上で実行中のアプリケーションです。
<!--more-->
異なる種類のワークロードやその一部を表すコアオブジェクトはさまざまなものがあり、DaemonSet、Deployment、Job、ReplicaSet、StatefulSetオブジェクトなどがあります。
たとえば、ウェブサーバーとデータベースを含むワークロードの場合、データベースを1つの{{< glossary_tooltip term_id="StatefulSet" >}}で実行し、ウェブサーバーを{{< glossary_tooltip term_id="Deployment" >}}で実行するという構成が考えられます。
@@ -8,16 +8,10 @@ card:
<!-- overview -->
[Kubectl概要](/ja/docs/reference/kubectl/overview/)と[JsonPathガイド](/docs/reference/kubectl/jsonpath)も合わせてご覧ください
このページは`kubectl`コマンドの概要です。
このページには、一般的によく使われる`kubectl`コマンドとフラグのリストが含まれています
<!-- body -->
# kubectl - チートシート
## Kubectlコマンドの補完
### BASH
@@ -76,7 +70,7 @@ kubectl config set-context gce --user=cluster-admin --namespace=foo \
kubectl config unset users.foo # ユーザーfooを削除します
```
## Apply
## Kubectl Apply
`apply`はKubernetesリソースを定義するファイルを通じてアプリケーションを管理します。`kubectl apply`を実行して、クラスター内のリソースを作成および更新します。これは、本番環境でKubernetesアプリケーションを管理する推奨方法です。
詳しくは[Kubectl Book](https://kubectl.docs.kubernetes.io)をご覧ください。
@@ -372,6 +366,7 @@ kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="k8s.gcr.
kubectl get pods -A -o=custom-columns='DATA:metadata.*'
```
kubectlに関するより多くのサンプルは[カスタムカラムのリファレンス](/ja/docs/reference/kubectl/overview/#custom-columns)を参照してください。
### Kubectlのログレベルとデバッグ
kubectlのログレベルは、レベルを表す整数が後に続く`-v`または`--v`フラグで制御されます。一般的なKubernetesのログ記録規則と関連するログレベルについて、[こちら](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)で説明します。
@@ -392,11 +387,10 @@ kubectlのログレベルは、レベルを表す整数が後に続く`-v`また
## {{% heading "whatsnext" %}}
* kubectlについてより深く学びたい方は[kubectl概要](/ja/docs/reference/kubectl/overview/)をご覧ください。
* kubectlについてより深く学びたい方は[kubectl概要](/ja/docs/reference/kubectl/overview/)や[JsonPath](/docs/reference/kubectl/jsonpath)をご覧ください。
* オプションについては[kubectl](/docs/reference/kubectl/kubectl/) optionsをご覧ください。
* また[kubectlの利用パターン](/docs/reference/kubectl/conventions/)では再利用可能なスクリプトでkubectlを利用する方法を学べます。
* コミュニティ版[kubectlチートシート](https://github.com/dennyzhang/cheatsheet-kubernetes-A4)もご覧ください。
@@ -0,0 +1,112 @@
---
title: JSONPathのサポート
content_type: concept
weight: 25
---
<!-- overview -->
kubectlはJSONPathのテンプレートをサポートしています。
<!-- body -->
JSONPathのテンプレートは、波括弧`{}`によって囲まれたJSONPathの式によって構成されています。
kubectlでは、JSONPathの式を使うことで、JSONオブジェクトの特定のフィールドをフィルターしたり、出力のフォーマットを変更することができます。
本来のJSONPathのテンプレートの構文に加え、以下の機能と構文が使えます:
1. JSONPathの式の内部でテキストをクォートするために、ダブルクォーテーションを使用します。
2. リストを反復するために、`range``end`オペレーターを使用します。
3. リストを末尾側から参照するために、負の数のインデックスを使用します。負の数のインデックスはリストを「周回」せず、`-index + listLength >= 0`が満たされる限りにおいて有効になります。
{{< note >}}
- 式は常にルートのオブジェクトから始まるので、`$`オペレーターの入力は任意になります。
- 結果のオブジェクトはString()関数を適用した形で表示されます。
{{< /note >}}
以下のようなJSONの入力が与えられたとします。
```json
{
"kind": "List",
"items":[
{
"kind":"None",
"metadata":{"name":"127.0.0.1"},
"status":{
"capacity":{"cpu":"4"},
"addresses":[{"type": "LegacyHostIP", "address":"127.0.0.1"}]
}
},
{
"kind":"None",
"metadata":{"name":"127.0.0.2"},
"status":{
"capacity":{"cpu":"8"},
"addresses":[
{"type": "LegacyHostIP", "address":"127.0.0.2"},
{"type": "another", "address":"127.0.0.3"}
]
}
}
],
"users":[
{
"name": "myself",
"user": {}
},
{
"name": "e2e",
"user": {"username": "admin", "password": "secret"}
}
]
}
```
機能 | 説明 | 例 | 結果
--------------------|---------------------------|-----------------------------------------------------------------|------------------
`text` | プレーンテキスト | `kind is {.kind}` | `kind is List`
`@` | 現在のオブジェクト | `{@}` | 入力した値と同じ値
`.` or `[]` | 子要素 | `{.kind}`, `{['kind']}` or `{['name\.type']}` | `List`
`..` | 子孫要素を再帰的に探す | `{..name}` | `127.0.0.1 127.0.0.2 myself e2e`
`*` | ワイルドカード。すべてのオブジェクトを取得する | `{.items[*].metadata.name}` | `[127.0.0.1 127.0.0.2]`
`[start:end:step]` | 添字 | `{.users[0].name}` | `myself`
`[,]` | 和集合 | `{.items[*]['metadata.name', 'status.capacity']}` | `127.0.0.1 127.0.0.2 map[cpu:4] map[cpu:8]`
`?()` | フィルター | `{.users[?(@.name=="e2e")].user.password}` | `secret`
`range`, `end` | リストの反復 | `{range .items[*]}[{.metadata.name}, {.status.capacity}] {end}` | `[127.0.0.1, map[cpu:4]] [127.0.0.2, map[cpu:8]]`
`''` | 解釈済みの文字列をクォートする | `{range .items[*]}{.metadata.name}{'\t'}{end}` | `127.0.0.1 127.0.0.2`
`kubectl`とJSONPathの式を使った例:
```shell
kubectl get pods -o json
kubectl get pods -o=jsonpath='{@}'
kubectl get pods -o=jsonpath='{.items[0]}'
kubectl get pods -o=jsonpath='{.items[0].metadata.name}'
kubectl get pods -o=jsonpath="{.items[*]['metadata.name', 'status.capacity']}"
kubectl get pods -o=jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.startTime}{"\n"}{end}'
```
{{< note >}}
Windowsでは、空白が含まれるJSONPathのテンプレートをクォートする場合は(上記のようにシングルクォーテーションを使うのではなく)、ダブルクォーテーションを使わなければなりません。
また、テンプレート内のリテラルをクォートする際には、シングルクォーテーションか、エスケープされたダブルクォーテーションを使わなければなりません。例えば:
```cmd
kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{'\t'}{.status.startTime}{'\n'}{end}"
kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{\"\t\"}{.status.startTime}{\"\n\"}{end}"
```
{{< /note >}}
{{< note >}}
JSONPathの正規表現はサポートされていません。正規表現を利用した検索を行いたい場合は、`jq`のようなツールを使ってください。
```shell
# kubectlはJSONpathの出力として正規表現をサポートしていないので、以下のコマンドは動作しない
kubectl get pods -o jsonpath='{.items[?(@.metadata.name=~/^test$/)].metadata.name}'
# 上のコマンドに期待される結果が欲しい場合、以下のコマンドを使うとよい
kubectl get pods -o json | jq -r '.items[] | select(.metadata.name | test("test-")).spec.containers[].image'
```
{{< /note >}}
@@ -191,8 +191,8 @@ kubectl [command] [TYPE] [NAME] -o <output_format>
`-o custom-columns=<spec>` | [カスタムカラム](#custom-columns)のコンマ区切りのリストを使用して、テーブルを表示します。
`-o custom-columns-file=<filename>` | `<filename>`ファイル内の[カスタムカラム](#custom-columns)のテンプレートを使用して、テーブルを表示します。
`-o json` | JSON形式のAPIオブジェクトを出力します。
`-o jsonpath=<template>` | [jsonpath](/docs/reference/kubectl/jsonpath/)式で定義されたフィールドを表示します。
`-o jsonpath-file=<filename>` | `<filename>`ファイル内の[jsonpath](/docs/reference/kubectl/jsonpath/)式で定義されたフィールドを表示します。
`-o jsonpath=<template>` | [jsonpath](/ja/docs/reference/kubectl/jsonpath/)式で定義されたフィールドを表示します。
`-o jsonpath-file=<filename>` | `<filename>`ファイル内の[jsonpath](/ja/docs/reference/kubectl/jsonpath/)式で定義されたフィールドを表示します。
`-o name` | リソース名のみを表示します。
`-o wide` | 追加情報を含めて、プレーンテキスト形式で出力します。Podの場合は、Node名が含まれます。
`-o yaml` | YAML形式のAPIオブジェクトを出力します。
@@ -263,7 +263,7 @@ pod-name 1m
### オブジェクトリストのソート
ターミナルウィンドウで、オブジェクトをソートされたリストに出力するには、サポートされている`kubectl`コマンドに`--sort-by`フラグを追加します。`--sort-by`フラグで任意の数値フィールドや文字列フィールドを指定することで、オブジェクトをソートします。フィールドの指定には、[jsonpath](/docs/reference/kubectl/jsonpath/)式を使用します。
ターミナルウィンドウで、オブジェクトをソートされたリストに出力するには、サポートされている`kubectl`コマンドに`--sort-by`フラグを追加します。`--sort-by`フラグで任意の数値フィールドや文字列フィールドを指定することで、オブジェクトをソートします。フィールドの指定には、[jsonpath](/ja/docs/reference/kubectl/jsonpath/)式を使用します。
#### 構文
+46
View File
@@ -0,0 +1,46 @@
---
title: ツール
content_type: concept
---
<!-- overview -->
Kubernetesには、Kubernetesシステムの操作に役立ついくつかの組み込みツールが含まれています。
<!-- body -->
## Kubectl
[`kubectl`](/docs/tasks/tools/install-kubectl/)は、Kubernetesのためのコマンドラインツールです。このコマンドはKubernetes cluster managerを操作します。
## Kubeadm
[`kubeadm`](docs/setup/production-environment/tools/kubeadm/install-kubeadm/)は、物理サーバやクラウドサーバ、仮想マシン上にKubenetesクラスタを容易にプロビジョニングするためのコマンドラインツールです(現在はアルファ版です)。
## Minikube
[`minikube`](https://minikube.sigs.k8s.io/docs/)は、開発やテストのためにワークステーション上でシングルノードのKubernetesクラスタをローカルで実行するツールです。
## Dashboard
[`Dashboard`](/docs/tasks/access-application-cluster/web-ui-dashboard/)は、KubernetesのWebベースのユーザインタフェースで、コンテナ化されたアプリケーションをKubernetesクラスタにデプロイしたり、トラブルシューティングしたり、クラスタとそのリソース自体を管理したりすることが出来ます。
## Helm
[`Kubernetes Helm`](https://github.com/helm/helm)は、事前に設定されたKubernetesリソースのパッケージ、別名Kubernetes chartsを管理するためのツールです。
Helmを用いて以下のことを行います。
* Kubernetes chartsとしてパッケージ化された人気のあるソフトウェアの検索と利用
* Kubernetes chartsとして所有するアプリケーションを共有すること
* Kubernetesアプリケーションの再現性のあるビルドの作成
* Kubernetesマニフェストファイルを知的な方法で管理
* Helmパッケージのリリース管理
## Kompose
[`Kompose`](https://github.com/kubernetes/kompose)は、Docker ComposeユーザがKubernetesに移行する手助けをするツールです。
Komposeを用いて以下のことを行います。
* Docker ComposeファイルのKubernetesオブジェクトへの変換
* ローカルのDocker開発からKubernetesを経由したアプリケーション管理への移行
* v1またはv2のDocker Compose用 `yaml` ファイルならびに[分散されたアプリケーションバンドル](https://docs.docker.com/compose/bundles/)の変換