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

remove some additional uncecessary files

Browse Source
This commit is contained in:
inductor
2021-05-26 13:33:45 +00:00
parent d322844be6
commit c31af9b03c
6 changed files with 0 additions and 1676 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ja/docs/concepts/services-networking/network-policies.md
-200
View File
@@ -1,200 +0,0 @@
---
title: ネットワークポリシー
content_type: concept
weight: 50
---
<!-- overview -->
ネットワークポリシーは、{{< glossary_tooltip text="Pod" term_id="pod">}}のグループが、Pod相互や他のネットワークエンドポイントと通信する場合に許可を与える方法を指定するための仕様です。
NetworkPolicyリソースは、{{< glossary_tooltip text="ラベル" term_id="label">}}を使用してPodを選択し、選択したPodに対してどんなトラフィックを許可するかを指定するルールを定義します。
<!-- body -->
## 前提条件
ネットワークポリシーは、[ネットワークプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)により実装されます。ネットワークポリシーを使用するには、NetworkPolicyをサポートするネットワークソリューションを使用しなければなりません。ネットワークポリシーを実装したコントローラーを使用せずにNetworkPolicyリソースを作成した場合は、何も効果はありません。
## 分離されたPodと分離されていないPod
デフォルトでは、Podは分離されていない状態(non-isolated)となるため、すべてのソースからのトラフィックを受信します。
Podを選択するNetworkPolicyが存在すると、Podは分離されるようになります。名前空間内に特定のPodを選択するNetworkPolicyが1つでも存在すると、そのPodはいずれかのNetworkPolicyで許可されていないすべての接続を拒否するようになります。(同じ名前空間内のPodでも、どのNetworkPolicyにも選択されなかった他のPodは、引き続きすべてのトラフィックを許可します。)
ネットワークポリシーは追加式であるため、競合することはありません。複数のポリシーがPodを選択する場合、そのPodに許可されるトラフィックは、それらのポリシーのingress/egressルールの和集合で制限されます。したがって、評価の順序はポリシーの結果には影響がありません。
## NetworkPolicyリソース {#networkpolicy-resource}
リソースの完全な定義については、リファレンスの[NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io)のセクションを参照してください。
以下は、NetworkPolicyの一例です。
```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: test-network-policy
namespace: default
spec:
podSelector:
matchLabels:
role: db
policyTypes:
- Ingress
- Egress
ingress:
- from:
- ipBlock:
cidr: 172.17.0.0/16
except:
- 172.17.1.0/24
- namespaceSelector:
matchLabels:
project: myproject
- podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 6379
egress:
- to:
- ipBlock:
cidr: 10.0.0.0/24
ports:
- protocol: TCP
port: 5978
```
{{< note >}}
選択したネットワークソリューションがネットワークポリシーをサポートしていない場合には、これをクラスターのAPIサーバーにPOSTしても効果はありません。
{{< /note >}}
__必須フィールド__: 他のKubernetesの設定と同様に、NetworkPolicyにも`apiVersion`、`kind`、`metadata`フィールドが必須です。設定ファイルの扱い方に関する一般的な情報については、[ConfigMapを使用してコンテナを構成する](/ja/docs/tasks/configure-pod-container/configure-pod-configmap/)と[オブジェクト管理](/ja/docs/concepts/overview/working-with-objects/object-management)を参照してください。
__spec__: NetworkPolicyの[spec](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)を見ると、指定した名前空間内で特定のネットワークポリシーを定義するのに必要なすべての情報が確認できます。
__podSelector__: 各NetworkPolicyには、ポリシーを適用するPodのグループを選択する`podSelector`が含まれます。ポリシーの例では、ラベル"role=db"を持つPodを選択しています。`podSelector`を空にすると、名前空間内のすべてのPodが選択されます。
__policyTypes__: 各NetworkPolicyには、`policyTypes`として、`Ingress`、`Egress`、またはその両方からなるリストが含まれます。`policyTypes`フィールドでは、指定したポリシーがどの種類のトラフィックに適用されるかを定めます。トラフィックの種類としては、選択したPodへの内向きのトラフィック(Ingress)、選択したPodからの外向きのトラフィック(Egress)、またはその両方を指定します。`policyTypes`を指定しなかった場合、デフォルトで常に
`Ingress`が指定され、NetworkPolicyにegressルールが1つでもあれば`Egress`も設定されます。
__ingress__: 各NetworkPolicyには、許可する`ingress`ルールのリストを指定できます。各ルールは、`from`および`ports`セクションの両方に一致するトラフィックを許可します。ポリシーの例には1つのルールが含まれ、このルールは、3つのソースのいずれかから送信された1つのポート上のトラフィックに一致します。1つ目のソースは`ipBlock`で、2つ目のソースは`namespaceSelector`で、3つ目のソースは`podSelector`でそれぞれ定められます。
__egress__: 各NetworkPolicyには、許可する`egress`ルールのリストを指定できます。各ルールは、`to`および`ports`セクションの両方に一致するトラフィックを許可します。ポリシーの例には1つのルールが含まれ、このルールは、1つのポート上で`10.0.0.0/24`の範囲内の任意の送信先へ送られるトラフィックに一致します。
したがって、上のNetworkPolicyの例では、次のようにネットワークポリシーを適用します。
1. "default"名前空間内にある"role=db"のPodを、内向きと外向きのトラフィックに対して分離する(まだ分離されていない場合)
2. (Ingressルール) "default"名前空間内の"role=db"ラベルが付いたすべてのPodのTCPの6379番ポートへの接続のうち、次の送信元からのものを許可する
* "default"名前空間内のラベル"role=frontend"が付いたすべてのPod
* ラベル"project=myproject"が付いた名前空間内のすべてのPod
* 172.17.0.0–172.17.0.255および172.17.2.0–172.17.255.255(言い換えれば、172.17.1.0/24の範囲を除く172.17.0.0/16)の範囲内のすべてのIPアドレス
3. (Egressルール) "role=db"というラベルが付いた"default"名前空間内のすべてのPodからの、TCPの5978番ポート上でのCIDR 10.0.0.0/24への接続を許可する
追加の例については、[ネットワークポリシーを宣言する](/ja/docs/tasks/administer-cluster/declare-network-policy/)の説明を参照してください。
## `to`と`from`のセレクターの振る舞い
`ingress`の`from`セクションまたは`egress`の`to`セクションに指定できるセレクターは4種類あります。
__podSelector__: NetworkPolicyと同じ名前空間内の特定のPodを選択して、ingressの送信元またはegressの送信先を許可します。
__namespaceSelector__: 特定の名前空間を選択して、その名前空間内のすべてのPodについて、ingressの送信元またはegressの送信先を許可します。
__namespaceSelector__ *および* __podSelector__: 1つの`to`または`from`エントリーで`namespaceSelector`と`podSelector`の両方を指定して、特定の名前空間内の特定のPodを選択します。正しいYAMLの構文を使うように気をつけてください。このポリシーの例を以下に示します。
```yaml
...
ingress:
- from:
- namespaceSelector:
matchLabels:
user: alice
podSelector:
matchLabels:
role: client
...
```
このポリシーには、1つの`from`要素があり、ラベル`user=alice`の付いた名前空間内にある、ラベル`role=client`の付いたPodからの接続を許可します。しかし、*以下の*ポリシーには注意が必要です。
```yaml
...
ingress:
- from:
- namespaceSelector:
matchLabels:
user: alice
- podSelector:
matchLabels:
role: client
...
```
このポリシーには、`from`配列の中に2つの要素があります。そのため、ラベル`role=client`の付いた名前空間内にあるすべてのPodからの接続、*または*、任意の名前空間内にあるラベル`user=alice`の付いたすべてのPodからの接続を許可します。
正しいルールになっているか自信がないときは、`kubectl describe`を使用すると、Kubernetesがどのようにポリシーを解釈したのかを確認できます。
__ipBlock__: 特定のIPのCIDRの範囲を選択して、ingressの送信元またはegressの送信先を許可します。PodのIPは一時的なもので予測できないため、ここにはクラスター外のIPを指定するべきです。
クラスターのingressとegressの仕組みはパケットの送信元IPや送信先IPの書き換えを必要とすることがよくあります。その場合、NetworkPolicyの処理がIPの書き換えの前後どちらで行われるのかは定義されていません。そのため、ネットワークプラグイン、クラウドプロバイダー、`Service`の実装などの組み合わせによっては、動作が異なる可能性があります。
内向きのトラフィックの場合は、実際のオリジナルの送信元IPに基づいてパケットをフィルタリングできる可能性もあれば、NetworkPolicyが対象とする「送信元IP」が`LoadBalancer`やPodのノードなどのIPになってしまっている可能性もあることになります。
外向きのトラフィックの場合は、クラスター外のIPに書き換えられたPodから`Service`のIPへの接続は、`ipBlock`ベースのポリシーの対象になる場合とならない場合があることになります。
## デフォルトのポリシー
デフォルトでは、名前空間にポリシーが存在しない場合、その名前空間内のPodの内向きと外向きのトラフィックはすべて許可されます。以下の例を利用すると、その名前空間内でのデフォルトの振る舞いを変更できます。
### デフォルトですべての内向きのトラフィックを拒否する
すべてのPodを選択して、そのPodへのすべての内向きのトラフィックを許可しないNetworkPolicyを作成すると、その名前空間に対する「デフォルト」の分離ポリシーを作成できます。
{{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}}
このポリシーを利用すれば、他のいかなるNetworkPolicyにも選択されなかったPodでも分離されることを保証できます。このポリシーは、デフォルトの外向きの分離の振る舞いを変更しません。
### デフォルトで内向きのすべてのトラフィックを許可する
(たとえPodを「分離されたもの」として扱うポリシーが追加された場合でも)名前空間内のすべてのPodへのすべてのトラフィックを許可したい場合には、その名前空間内のすべてのトラフィックを明示的に許可するポリシーを作成できます。
{{< codenew file="service/networking/network-policy-allow-all-ingress.yaml" >}}
### デフォルトで外向きのすべてのトラフィックを拒否する
すべてのPodを選択して、そのPodからのすべての外向きのトラフィックを許可しないNetworkPolicyを作成すると、その名前空間に対する「デフォルト」の外向きの分離ポリシーを作成できます。
{{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}}
このポリシーを利用すれば、他のいかなるNetworkPolicyにも選択されなかったPodでも、外向きのトラフィックが許可されないことを保証できます。このポリシーは、デフォルトの内向きの分離の振る舞いを変更しません。
### デフォルトで外向きのすべてのトラフィックを許可する
(たとえPodを「分離されたもの」として扱うポリシーが追加された場合でも)名前空間内のすべてのPodからのすべてのトラフィックを許可したい場合には、その名前空間内のすべての外向きのトラフィックを明示的に許可するポリシーを作成できます。
{{< codenew file="service/networking/network-policy-allow-all-egress.yaml" >}}
### デフォルトで内向きと外向きのすべてのトラフィックを拒否する
名前空間内に以下のNetworkPolicyを作成すると、その名前空間で内向きと外向きのすべてのトラフィックを拒否する「デフォルト」のポリシーを作成できます。
{{< codenew file="service/networking/network-policy-default-deny-all.yaml" >}}
このポリシーを利用すれば、他のいかなるNetworkPolicyにも選択されなかったPodでも、内向きと外向きのトラフィックが許可されないことを保証できます。
## SCTPのサポート
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
この機能を利用するには、クラスター管理者がAPIサーバーで`--feature-gates=SCTPSupport=true,…`と指定して、`SCTPSupport`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にする必要があります。フィーチャーゲートが有効になれば、NetworkPolicyの`protocol`フィールドに`SCTP`が指定できるようになります。
{{< note >}}
SCTPプロトコルのネットワークポリシーをサポートする{{< glossary_tooltip text="CNI" term_id="cni" >}}プラグインを使用している必要があります。
{{< /note >}}
## {{% heading "whatsnext" %}}
- [ネットワークポリシーを宣言する](/ja/docs/tasks/administer-cluster/declare-network-policy/)で追加の例の説明を読む。
- NetworkPolicyリソースで実現できるよくあるシナリオのためのさまざまな[レシピ](https://github.com/ahmetb/kubernetes-network-policy-recipes)を確認する。
content/ja/docs/reference/access-authn-authz/rbac.md
-1102
View File
File diff suppressed because it is too large Load Diff
content/ja/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md
-83
View File
@@ -1,83 +0,0 @@
---
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
content/ja/docs/reference/glossary/cloud-controller-manager.md
-18
View File
@@ -1,18 +0,0 @@
---
title: クラウドコントローラーマネージャー
id: cloud-controller-manager
date: 2018-04-12
full_link: /ja/docs/concepts/architecture/cloud-controller/
short_description: >
サードパーティクラウドプロバイダーにKubernetewを結合するコントロールプレーンコンポーネント
aka:
tags:
- core-object
- architecture
- operation
---
クラウド特有の制御ロジックを組み込むKubernetesの{{< glossary_tooltip text="control plane" term_id="control-plane" >}}コンポーネントです。クラウドコントロールマネージャーは、クラスターをクラウドプロバイダーAPIをリンクし、クラスタのみで相互作用するコンポーネントからクラウドプラットフォームで相互作用するコンポーネントを分離します。
<!--more-->
Kubernetesと下のクラウドインフラストラクチャー間の相互運用ロジックを分離することで、cloud-controller-managerコンポーネントはクラウドプロバイダを主なKubernetesプロジェクトと比較し異なるペースで機能をリリース可能にします。
content/ja/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
-181
View File
@@ -1,181 +0,0 @@
---
title: Windowsノードの追加
min-kubernetes-server-version: 1.17
content_type: tutorial
weight: 30
---
<!-- overview -->
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
Kubernetesを使用してLinuxノードとWindowsノードを混在させて実行できるため、Linuxで実行するPodとWindowsで実行するPodを混在させることができます。このページでは、Windowsノードをクラスターに登録する方法を示します。
## {{% heading "prerequisites" %}}
{{< version-check >}}
* WindowsコンテナをホストするWindowsノードを構成するには、[Windows Server 2019ライセンス](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing)(またはそれ以上)を取得します。
VXLAN/オーバーレイネットワークを使用している場合は、[KB4489899](https://support.microsoft.com/help/4489899)もインストールされている必要があります。
* コントロールプレーンにアクセスできるLinuxベースのKubernetes kubeadmクラスター([kubeadmを使用したシングルコントロールプレーンクラスターの作成](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)を参照)
## {{% heading "objectives" %}}
* Windowsノードをクラスターに登録する
* LinuxとWindowsのPodとServiceが相互に通信できるようにネットワークを構成する
<!-- lessoncontent -->
## はじめに: クラスターへのWindowsノードの追加
### ネットワーク構成
LinuxベースのKubernetesコントロールプレーンノードを取得したら、ネットワーキングソリューションを選択できます。このガイドでは、簡単にするためにVXLANモードでのFlannelの使用について説明します。
#### Flannel構成
1. FlannelのためにKubernetesコントロールプレーンを準備する
クラスター内のKubernetesコントロールプレーンでは、多少の準備が推奨されます。Flannelを使用する場合は、iptablesチェーンへのブリッジIPv4トラフィックを有効にすることをお勧めします。すべてのLinuxノードで次のコマンドを実行する必要があります:
```bash
sudo sysctl net.bridge.bridge-nf-call-iptables=1
```
1. Linux用のFlannelをダウンロードして構成する
最新のFlannelマニフェストをダウンロード:
```bash
wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
```
VNIを4096、ポートを4789に設定するために、flannelマニフェストの`net-conf.json`セクションを変更します。次のようになります:
```json
net-conf.json: |
{
"Network": "10.244.0.0/16",
"Backend": {
"Type": "vxlan",
"VNI" : 4096,
"Port": 4789
}
}
```
{{< note >}}Linux上のFlannelがWindows上のFlannelと相互運用するには、VNIを4096およびポート4789に設定する必要があります。これらのフィールドの説明については、[VXLANドキュメント](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)を参照してください。{{< /note >}}
{{< note >}}L2Bridge/Host-gatewayモードを使用するには、代わりに`Type`の値を`"host-gw"`に変更し、`VNI`と`Port`を省略します。{{< /note >}}
1. Flannelマニフェストを適用して検証する
Flannelの構成を適用しましょう:
```bash
kubectl apply -f kube-flannel.yml
```
数分後、Flannel Podネットワークがデプロイされていれば、すべてのPodが実行されていることがわかります。
```bash
kubectl get pods -n kube-system
```
出力結果には、実行中のLinux flannel DaemonSetが含まれているはずです:
```
NAMESPACE NAME READY STATUS RESTARTS AGE
...
kube-system kube-flannel-ds-54954 1/1 Running 0 1m
```
1. Windows Flannelとkube-proxy DaemonSetを追加する
これで、Windows互換バージョンのFlannelおよびkube-proxyを追加できます。
互換性のあるバージョンのkube-proxyを確実に入手するには、イメージのタグを置換する必要があります。
次の例は、Kubernetes{{< param "fullversion" >}}の使用方法を示していますが、
独自のデプロイに合わせてバージョンを調整する必要があります。
```bash
curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/kube-proxy.yml | sed 's/VERSION/{{< param "fullversion" >}}/g' | kubectl apply -f -
kubectl apply -f https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-overlay.yml
```
{{< note >}}
ホストゲートウェイを使用している場合は、代わりに https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-host-gw.yml を使用してください。
{{< /note >}}
{{< note >}}
Windowsノードでイーサネット(「Ethernet0 2」など)ではなく別のインターフェースを使用している場合は、次の行を変更する必要があります:
```powershell
wins cli process run --path /k/flannel/setup.exe --args "--mode=overlay --interface=Ethernet"
```
`flannel-host-gw.yml`または`flannel-overlay.yml`ファイルで、それに応じてインターフェースを指定します。
```bash
# 例
curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-overlay.yml | sed 's/Ethernet/Ethernet0 2/g' | kubectl apply -f -
```
{{< /note >}}
### Windowsワーカーノードの参加
{{< note >}}
`Containers`機能をインストールし、Dockerをインストールする必要があります。
行うための指示としては、[Dockerエンジンのインストール - Windowsサーバー上のエンタープライズ](https://docs.mirantis.com/docker-enterprise/v3.1/dockeree-products/docker-engine-enterprise/dee-windows.html)を利用できます。
{{< /note >}}
{{< note >}}
Windowsセクションのすべてのコードスニペットは、
Windowsワーカーノードの(管理者)権限を持つPowerShell環境で実行されます。
{{< /note >}}
1. wins、kubelet、kubeadmをインストールします。
```PowerShell
curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/PrepareNode.ps1
.\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}}
```
1. `kubeadm`を実行してノードに参加します
コントロールプレーンホストで`kubeadm init`を実行したときに提供されたコマンドを使用します。
このコマンドがなくなった場合、またはトークンの有効期限が切れている場合は、`kubeadm token create --print-join-command`
(コントロールプレーンホスト上で)を実行して新しいトークンを生成します。
#### インストールの確認
次のコマンドを実行して、クラスター内のWindowsノードを表示できるようになります:
```bash
kubectl get nodes -o wide
```
新しいノードが`NotReady`状態の場合は、flannelイメージがまだダウンロード中の可能性があります。
`kube-system`名前空間のflannel Podを確認することで、以前と同様に進行状況を確認できます:
```shell
kubectl -n kube-system get pods -l app=flannel
```
flannel Podが実行されると、ノードは`Ready`状態になり、ワークロードを処理できるようになります。
## {{% heading "whatsnext" %}}
- [Windows kubeadmノードのアップグレード](/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes)
content/ja/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md
-92
View File
@@ -1,92 +0,0 @@
---
title: Windowsノードのアップグレード
min-kubernetes-server-version: 1.17
content_type: task
weight: 40
---
<!-- overview -->
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
このページでは、[kubeadmで作られた](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes)Windowsノードをアップグレードする方法について説明します。
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* [残りのkubeadmクラスターをアップグレードするプロセス](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade)を理解します。
Windowsノードをアップグレードする前にコントロールプレーンノードをアップグレードしたいと思うかもしれません。
<!-- steps -->
## ワーカーノードをアップグレード
### kubeadmをアップグレード
1. Windowsノードから、kubeadmをアップグレードします。:
```powershell
# {{< param "fullversion" >}}を目的のバージョンに置き換えます
curl.exe -Lo C:\k\kubeadm.exe https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubeadm.exe
```
### ノードをドレインする
1. Kubernetes APIにアクセスできるマシンから、
ノードをスケジュール不可としてマークして、ワークロードを削除することでノードのメンテナンスを準備します:
```shell
# <node-to-drain>をドレインするノードの名前に置き換えます
kubectl drain <node-to-drain> --ignore-daemonsets
```
このような出力結果が表示されるはずです:
```
node/ip-172-31-85-18 cordoned
node/ip-172-31-85-18 drained
```
### kubeletの構成をアップグレード
1. Windowsノードから、次のコマンドを呼び出して新しいkubelet構成を同期します:
```powershell
kubeadm upgrade node
```
### kubeletをアップグレード
1. Windowsノードから、kubeletをアップグレードして再起動します:
```powershell
stop-service kubelet
curl.exe -Lo C:\k\kubelet.exe https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubelet.exe
restart-service kubelet
```
### ノードをオンライン状態に
1. Kubernetes APIにアクセスできるマシンから、
スケジュール可能としてマークして、ノードをオンラインに戻します:
```shell
# <node-to-drain>をノードの名前に置き換えます
kubectl uncordon <node-to-drain>
```
### kube-proxyをアップグレード
1. Kubernetes APIにアクセスできるマシンから、次を実行します、
もう一度{{< param "fullversion" >}}を目的のバージョンに置き換えます:
```shell
curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/kube-proxy.yml | sed 's/VERSION/{{< param "fullversion" >}}/g' | kubectl apply -f -
```