[ja] replaced {{< codenew ... >}} with {{% codenew ... %}} (#42211)
* JA localization: replaced {{< codenew ... >}} with {{% codenew ... %}} in all files
* JA localization: replaced {{< codenew ... >}} with {{% codenew ... %}} in all files
pull/43089/head
Andrey Goran
GitHub
parent
6d32bb501e
commit
ff1985d92e
|
|
@ -22,7 +22,7 @@ weight: 60
|
|||
|
||||
この例では、1秒に1回標準出力ストリームにテキストを書き込むコンテナを利用する、`Pod` specificationを使います。
|
||||
|
||||
{{< codenew file="debug/counter-pod.yaml" >}}
|
||||
{{% codenew file="debug/counter-pod.yaml" %}}
|
||||
|
||||
このPodを実行するには、次のコマンドを使用します:
|
||||
|
||||
|
|
@ -131,13 +131,13 @@ Kubernetesはクラスターレベルロギングのネイティブソリュー
|
|||
|
||||
たとえば、Podは単一のコンテナを実行し、コンテナは2つの異なる形式を使用して2つの異なるログファイルに書き込みます。Podの構成ファイルは次のとおりです:
|
||||
|
||||
{{< codenew file="admin/logging/two-files-counter-pod.yaml" >}}
|
||||
{{% codenew file="admin/logging/two-files-counter-pod.yaml" %}}
|
||||
|
||||
両方のコンポーネントをコンテナの`stdout`ストリームにリダイレクトできたとしても、異なる形式のログエントリを同じログストリームに書き込むことはおすすめしません。代わりに、2つのサイドカーコンテナを作成できます。各サイドカーコンテナは、共有ボリュームから特定のログファイルを追跡し、ログを自身の`stdout`ストリームにリダイレクトできます。
|
||||
|
||||
2つのサイドカーコンテナを持つPodの構成ファイルは次のとおりです:
|
||||
|
||||
{{< codenew file="admin/logging/two-files-counter-pod-streaming-sidecar.yaml" >}}
|
||||
{{% codenew file="admin/logging/two-files-counter-pod-streaming-sidecar.yaml" %}}
|
||||
|
||||
これで、このPodを実行するときに、次のコマンドを実行して、各ログストリームに個別にアクセスできます:
|
||||
|
||||
|
|
@ -185,7 +185,7 @@ CPUとメモリーの使用量が少ない(CPUの場合は数ミリコアのオ
|
|||
|
||||
ロギングエージェントを使用したサイドカーコンテナを実装するために使用できる、2つの構成ファイルを次に示します。最初のファイルには、fluentdを設定するための[`ConfigMap`](/ja/docs/tasks/configure-pod-container/configure-pod-configmap/)が含まれています。
|
||||
|
||||
{{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}}
|
||||
{{% codenew file="admin/logging/fluentd-sidecar-config.yaml" %}}
|
||||
|
||||
{{< note >}}
|
||||
fluentdの構成については、[fluentd documentation](https://docs.fluentd.org/)を参照してください。
|
||||
|
|
@ -193,7 +193,7 @@ fluentdの構成については、[fluentd documentation](https://docs.fluentd.o
|
|||
|
||||
2番目のファイルは、fluentdを実行しているサイドカーコンテナを持つPodを示しています。Podは、fluentdが構成データを取得できるボリュームをマウントします。
|
||||
|
||||
{{< codenew file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" >}}
|
||||
{{% codenew file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" %}}
|
||||
|
||||
サンプル構成では、fluentdを任意のロギングエージェントに置き換えて、アプリケーションコンテナ内の任意のソースから読み取ることができます。
|
||||
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ weight: 40
|
|||
多くのアプリケーションではDeploymentやServiceなど複数のリソースの作成を要求します。複数のリソースの管理は、同一のファイルにひとまとめにしてグループ化すると簡単になります(YAMLファイル内で`---`で区切る)。
|
||||
例えば:
|
||||
|
||||
{{< codenew file="application/nginx-app.yaml" >}}
|
||||
{{% codenew file="application/nginx-app.yaml" %}}
|
||||
|
||||
複数のリソースは単一のリソースと同様の方法で作成できます。
|
||||
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ Kubernetesでオブジェクトを作成する場合、オブジェクトの基
|
|||
|
||||
ここで、KubernetesのDeploymentに必要なフィールドとオブジェクトのspecを記載した`.yaml`ファイルの例を示します:
|
||||
|
||||
{{< codenew file="application/deployment.yaml" >}}
|
||||
{{% codenew file="application/deployment.yaml" %}}
|
||||
|
||||
上に示した`.yaml`ファイルを利用してDeploymentを作成するには、`kubectl`コマンドラインインターフェースに含まれている[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply)コマンドに`.yaml`ファイルを引数に指定し、実行します。ここで例を示します:
|
||||
|
||||
|
|
|
|||
|
|
@ -88,7 +88,7 @@ Podのspec(仕様)にある`.spec.affinity.nodeAffinity`フィールドを使用
|
|||
|
||||
例えば、次のようなPodのspec(仕様)を考えてみましょう:
|
||||
|
||||
{{< codenew file="pods/pod-with-node-affinity.yaml" >}}
|
||||
{{% codenew file="pods/pod-with-node-affinity.yaml" %}}
|
||||
|
||||
この例では、以下のルールが適用されます:
|
||||
|
||||
|
|
@ -118,7 +118,7 @@ Podの他のスケジューリング要件をすべて満たすNodeを見つけ
|
|||
|
||||
例えば、次のようなPodのspec(仕様)を考えてみましょう:
|
||||
|
||||
{{< codenew file="pods/pod-with-affinity-anti-affinity.yaml" >}}
|
||||
{{% codenew file="pods/pod-with-affinity-anti-affinity.yaml" %}}
|
||||
|
||||
`preferredDuringSchedulingIgnoredDuringExecution`ルールにマッチするNodeとして、一つは`label-1:key-1`ラベル、もう一つは`label-2:key-2`ラベルの2つの候補がある場合、スケジューラーは各Nodeの`weight`を考慮し、その重みとNodeの他のスコアを加え、最終スコアが最も高いNodeにPodをスケジューリングします。
|
||||
|
||||
|
|
@ -197,7 +197,7 @@ Pod間アフィニティを使用するには、Pod仕様(spec)の`affinity.podA
|
|||
|
||||
次のようなPod仕様(spec)を考えてみましょう:
|
||||
|
||||
{{< codenew file="pods/pod-with-pod-affinity.yaml" >}}
|
||||
{{% codenew file="pods/pod-with-pod-affinity.yaml" %}}
|
||||
|
||||
この例では、PodアフィニティルールとPodアンチアフィニティルールを1つずつ定義しています。
|
||||
Podアフィニティルールは"ハード"な`requiredDuringSchedulingIgnoredDuringExecution`を使用し、アンチアフィニティルールは"ソフト"な`preferredDuringSchedulingIgnoredDuringExecution`を使用しています。
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@ tolerations:
|
|||
|
||||
tolerationを設定したPodの例を示します。
|
||||
|
||||
{{< codenew file="pods/pod-with-toleration.yaml" >}}
|
||||
{{% codenew file="pods/pod-with-toleration.yaml" %}}
|
||||
|
||||
`operator`のデフォルトは`Equal`です。
|
||||
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ Kubernetesでは、どのホストで稼働するかに関わらず、Podが他
|
|||
前の例でネットワークモデルを紹介しましたが、再度ネットワークの観点に焦点を当てましょう。
|
||||
nginx Podを作成し、コンテナポートの仕様を指定していることに注意してください。
|
||||
|
||||
{{< codenew file="service/networking/run-my-nginx.yaml" >}}
|
||||
{{% codenew file="service/networking/run-my-nginx.yaml" %}}
|
||||
|
||||
これにより、クラスター内のどのノードからでもアクセスできるようになります。
|
||||
Podが実行されているノードを確認します:
|
||||
|
|
@ -87,7 +87,7 @@ service/my-nginx exposed
|
|||
|
||||
これは次のyamlを`kubectl apply -f`することと同等です:
|
||||
|
||||
{{< codenew file="service/networking/nginx-svc.yaml" >}}
|
||||
{{% codenew file="service/networking/nginx-svc.yaml" %}}
|
||||
|
||||
この仕様は、`run：my-nginx`ラベルを持つ任意のPodのTCPポート80をターゲットとするサービスを作成し、抽象化されたサービスポートでPodを公開します(`targetPort`:はコンテナがトラフィックを受信するポート、`port`:は抽象化されたServiceのポートであり、他のPodがServiceへのアクセスに使用する任意のポートにすることができます)。
|
||||
サービス定義でサポートされているフィールドのリストは[Service](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core) APIオブジェクトを参照してください。
|
||||
|
|
@ -308,7 +308,7 @@ nginxsecret kubernetes.io/tls 2 1m
|
|||
|
||||
次に、nginxレプリカを変更して、シークレットの証明書とServiceを使用してhttpsサーバーを起動し、両方のポート(80と443)を公開します:
|
||||
|
||||
{{< codenew file="service/networking/nginx-secure-app.yaml" >}}
|
||||
{{% codenew file="service/networking/nginx-secure-app.yaml" %}}
|
||||
|
||||
nginx-secure-appマニフェストに関する注目すべき点:
|
||||
|
||||
|
|
@ -341,7 +341,7 @@ CNameの不一致を無視するようcurlに指示する必要があります
|
|||
Serviceを作成することにより、証明書で使用されるCNameを、Service検索中にPodで使用される実際のDNS名にリンクしました。
|
||||
これをPodからテストしましょう(簡単にするために同じシークレットを再利用しています。PodはServiceにアクセスするためにnginx.crtのみを必要とします):
|
||||
|
||||
{{< codenew file="service/networking/curlpod.yaml" >}}
|
||||
{{% codenew file="service/networking/curlpod.yaml" %}}
|
||||
|
||||
```shell
|
||||
kubectl apply -f ./curlpod.yaml
|
||||
|
|
|
|||
|
|
@ -193,7 +193,7 @@ PodのDNS設定は、ユーザーがPodに対してそのDNS設定上でさら
|
|||
|
||||
下記のファイルはカスタムDNS設定を持ったPodの例です。
|
||||
|
||||
{{< codenew file="service/networking/custom-dns.yaml" >}}
|
||||
{{% codenew file="service/networking/custom-dns.yaml" %}}
|
||||
|
||||
上記のPodが作成されたとき、`test`コンテナは、コンテナ内の`/etc/resolv.conf`ファイル内にある下記の内容を取得します。
|
||||
|
||||
|
|
|
|||
|
|
@ -74,15 +74,15 @@ IPv6 CIDRの例: `fdXY:IJKL:MNOP:15::/64` (これはフォーマットを示す
|
|||
|
||||
次のServiceのspecには`ipFamily`フィールドが含まれていません。Kubernetesは、最初に設定した`service-cluster-ip-range`の範囲からこのServiceにIPアドレス(別名「cluster IP」)を割り当てます。
|
||||
|
||||
{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
|
||||
{{% codenew file="service/networking/dual-stack-default-svc.yaml" %}}
|
||||
|
||||
次のServiceのspecには`ipFamily`フィールドが含まれています。Kubernetesは、最初に設定した`service-cluster-ip-range`の範囲からこのServiceにIPv6のアドレス(別名「cluster IP」)を割り当てます。
|
||||
|
||||
{{< codenew file="service/networking/dual-stack-ipv6-svc.yaml" >}}
|
||||
{{% codenew file="service/networking/dual-stack-ipv6-svc.yaml" %}}
|
||||
|
||||
比較として次のServiceのspecを見ると、このServiceには最初に設定した`service-cluster-ip-range`の範囲からIPv4のアドレス(別名「cluster IP」)が割り当てられます。
|
||||
|
||||
{{< codenew file="service/networking/dual-stack-ipv4-svc.yaml" >}}
|
||||
{{% codenew file="service/networking/dual-stack-ipv4-svc.yaml" %}}
|
||||
|
||||
### Type LoadBalancer
|
||||
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ Ingressコントローラーのドキュメントを確認して、選択する
|
|||
|
||||
Ingressリソースの最小構成の例は以下のとおりです。
|
||||
|
||||
{{< codenew file="service/networking/minimal-ingress.yaml" >}}
|
||||
{{% codenew file="service/networking/minimal-ingress.yaml" %}}
|
||||
|
||||
Ingressには`apiVersion`、`kind`、`metadata`や`spec`フィールドが必要です。Ingressオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。設定ファイルに関する一般的な情報は、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/ja/docs/tasks/configure-pod-container/configure-pod-configmap/)、[リソースの管理](/ja/docs/concepts/cluster-administration/manage-deployment/)を参照してください。Ingressでは、Ingressコントローラーに依存しているいくつかのオプションの設定をするためにアノテーションを一般的に使用します。例としては、[rewrite-targetアノテーション](https://github.com/kubernetes/ingress-nginx/blob/main/docs/examples/rewrite/README.md)などがあります。[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)の種類が異なれば、サポートするアノテーションも異なります。サポートされているアノテーションについて学ぶためには、使用するIngressコントローラーのドキュメントを確認してください。
|
||||
|
||||
|
|
@ -82,7 +82,7 @@ HTTPリクエストがIngressオブジェクトのホスト名とパスの条件
|
|||
`Resource`はServiceの設定とは排他であるため、両方を指定するとバリデーションに失敗します。
|
||||
`Resource`バックエンドの一般的な用途は、静的なアセットが入ったオブジェクトストレージバックエンドにデータを導入することです。
|
||||
|
||||
{{< codenew file="service/networking/ingress-resource-backend.yaml" >}}
|
||||
{{% codenew file="service/networking/ingress-resource-backend.yaml" %}}
|
||||
|
||||
上記のIngressを作成した後に、次のコマンドで参照することができます。
|
||||
|
||||
|
|
@ -157,14 +157,14 @@ Ingressのそれぞれのパスは対応するパスのタイプを持ちます
|
|||
| `*.foo.com` | `baz.bar.foo.com` | 一致しない。ワイルドカードは単一のDNSラベルのみを対象とする |
|
||||
| `*.foo.com` | `foo.com` | 一致しない。ワイルドカードは単一のDNSラベルのみを対象とする |
|
||||
|
||||
{{< codenew file="service/networking/ingress-wildcard-host.yaml" >}}
|
||||
{{% codenew file="service/networking/ingress-wildcard-host.yaml" %}}
|
||||
|
||||
## Ingress Class
|
||||
|
||||
Ingressは異なったコントローラーで実装されうるため、しばしば異なった設定を必要とします。
|
||||
各Ingressはクラス、つまりIngressClassリソースへの参照を指定する必要があります。IngressClassリソースには、このクラスを実装するコントローラーの名前などの追加設定が含まれています。
|
||||
|
||||
{{< codenew file="service/networking/external-lb.yaml" >}}
|
||||
{{% codenew file="service/networking/external-lb.yaml" %}}
|
||||
|
||||
IngressClassの`.spec.parameters`フィールドを使って、そのIngressClassに関連する設定を持っている別のリソースを参照することができます。
|
||||
|
||||
|
|
@ -257,7 +257,7 @@ IngressClassリソースの`ingressclass.kubernetes.io/is-default-class`アノ
|
|||
Ingressコントローラーの中には、デフォルトの`IngressClass`を定義しなくても動作するものがあります。 例えば、Ingress-NGINXコントローラーは[フラグ](https://kubernetes.github.io/ingress-nginx/#what-is-the-flag-watch-ingress-without-class)
|
||||
`--watch-ingress-without-class`で設定することができます。ただし、デフォルト`IngressClass`を指定することを[推奨します](https://kubernetes.github.io/ingress-nginx/#i-have-only-one-instance-of-the-ingresss-nginx-controller-in-my-cluster-what-should-i-do):
|
||||
|
||||
{{< codenew file="service/networking/default-ingressclass.yaml" >}}
|
||||
{{% codenew file="service/networking/default-ingressclass.yaml" %}}
|
||||
|
||||
## Ingressのタイプ
|
||||
|
||||
|
|
@ -265,7 +265,7 @@ Ingressコントローラーの中には、デフォルトの`IngressClass`を
|
|||
|
||||
Kubernetesには、単一のServiceを公開できるようにする既存の概念があります（[Ingressの代替案](#alternatives)を参照してください）。ルールなしで*デフォルトのバックエンド* を指定することにより、Ingressでこれを実現することもできます。
|
||||
|
||||
{{< codenew file="service/networking/test-ingress.yaml" >}}
|
||||
{{% codenew file="service/networking/test-ingress.yaml" %}}
|
||||
|
||||
`kubectl apply -f`を実行してIngressを作成すると、その作成したIngressの状態を確認することができます。
|
||||
|
||||
|
|
@ -292,7 +292,7 @@ IngressコントローラーとロードバランサーがIPアドレス割り
|
|||
|
||||
Ingressを以下のように設定します。
|
||||
|
||||
{{< codenew file="service/networking/simple-fanout-example.yaml" >}}
|
||||
{{% codenew file="service/networking/simple-fanout-example.yaml" %}}
|
||||
|
||||
Ingressを`kubectl apply -f`によって作成したとき:
|
||||
|
||||
|
|
@ -332,13 +332,13 @@ IngressコントローラーはService(`service1`、`service2`)が存在する
|
|||
|
||||
以下のIngress設定は、ロードバランサーに対して、[Hostヘッダー](https://tools.ietf.org/html/rfc7230#section-5.4)に基づいてリクエストを転送するように指示するものです。
|
||||
|
||||
{{< codenew file="service/networking/name-virtual-host-ingress.yaml" >}}
|
||||
{{% codenew file="service/networking/name-virtual-host-ingress.yaml" %}}
|
||||
|
||||
rules項目でのホストの設定がないIngressを作成すると、IngressコントローラーのIPアドレスに対するwebトラフィックは、要求されている名前ベースのバーチャルホストなしにマッチさせることができます。
|
||||
|
||||
例えば、以下のIngressは`first.bar.com`に対するトラフィックを`service1`へ、`second.foo.com`に対するトラフィックを`service2`へ、リクエストにおいてホスト名が指定されていない(リクエストヘッダーがないことを意味します)トラフィックは`service3`へ転送します。
|
||||
|
||||
{{< codenew file="service/networking/name-virtual-host-ingress-no-third-host.yaml" >}}
|
||||
{{% codenew file="service/networking/name-virtual-host-ingress-no-third-host.yaml" %}}
|
||||
|
||||
### TLS
|
||||
|
||||
|
|
@ -364,7 +364,7 @@ IngressでこのSecretを参照すると、クライアントとロードバラ
|
|||
そのため、`tls`セクションの`hosts`は`rules`セクションの`host`と明示的に一致する必要があります。
|
||||
{{< /note >}}
|
||||
|
||||
{{< codenew file="service/networking/tls-example-ingress.yaml" >}}
|
||||
{{% codenew file="service/networking/tls-example-ingress.yaml" %}}
|
||||
|
||||
{{< note >}}
|
||||
サポートされるTLSの機能はIngressコントローラーによって違いがあります。利用する環境でTLSがどのように動作するかを理解するためには、[nginx](https://kubernetes.github.io/ingress-nginx/user-guide/tls/)や、[GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https)、または他のプラットフォーム固有のIngressコントローラーのドキュメントを確認してください。
|
||||
|
|
|
|||
|
|
@ -160,7 +160,7 @@ __ipBlock__: 特定のIPのCIDRの範囲を選択して、ingressの送信元ま
|
|||
|
||||
すべてのPodを選択して、そのPodへのすべての内向きのトラフィックを許可しないNetworkPolicyを作成すると、その名前空間に対する「デフォルト」の分離ポリシーを作成できます。
|
||||
|
||||
{{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}}
|
||||
{{% codenew file="service/networking/network-policy-default-deny-ingress.yaml" %}}
|
||||
|
||||
このポリシーを利用すれば、他のいかなるNetworkPolicyにも選択されなかったPodでも分離されることを保証できます。このポリシーは、デフォルトの外向きの分離の振る舞いを変更しません。
|
||||
|
||||
|
|
@ -168,13 +168,13 @@ __ipBlock__: 特定のIPのCIDRの範囲を選択して、ingressの送信元ま
|
|||
|
||||
(たとえPodを「分離されたもの」として扱うポリシーが追加された場合でも)名前空間内のすべてのPodへのすべてのトラフィックを許可したい場合には、その名前空間内のすべてのトラフィックを明示的に許可するポリシーを作成できます。
|
||||
|
||||
{{< codenew file="service/networking/network-policy-allow-all-ingress.yaml" >}}
|
||||
{{% codenew file="service/networking/network-policy-allow-all-ingress.yaml" %}}
|
||||
|
||||
### デフォルトで外向きのすべてのトラフィックを拒否する
|
||||
|
||||
すべてのPodを選択して、そのPodからのすべての外向きのトラフィックを許可しないNetworkPolicyを作成すると、その名前空間に対する「デフォルト」の外向きの分離ポリシーを作成できます。
|
||||
|
||||
{{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}}
|
||||
{{% codenew file="service/networking/network-policy-default-deny-egress.yaml" %}}
|
||||
|
||||
このポリシーを利用すれば、他のいかなるNetworkPolicyにも選択されなかったPodでも、外向きのトラフィックが許可されないことを保証できます。このポリシーは、デフォルトの内向きの分離の振る舞いを変更しません。
|
||||
|
||||
|
|
@ -182,13 +182,13 @@ __ipBlock__: 特定のIPのCIDRの範囲を選択して、ingressの送信元ま
|
|||
|
||||
(たとえPodを「分離されたもの」として扱うポリシーが追加された場合でも)名前空間内のすべてのPodからのすべてのトラフィックを許可したい場合には、その名前空間内のすべての外向きのトラフィックを明示的に許可するポリシーを作成できます。
|
||||
|
||||
{{< codenew file="service/networking/network-policy-allow-all-egress.yaml" >}}
|
||||
{{% codenew file="service/networking/network-policy-allow-all-egress.yaml" %}}
|
||||
|
||||
### デフォルトで内向きと外向きのすべてのトラフィックを拒否する
|
||||
|
||||
名前空間内に以下のNetworkPolicyを作成すると、その名前空間で内向きと外向きのすべてのトラフィックを拒否する「デフォルト」のポリシーを作成できます。
|
||||
|
||||
{{< codenew file="service/networking/network-policy-default-deny-all.yaml" >}}
|
||||
{{% codenew file="service/networking/network-policy-default-deny-all.yaml" %}}
|
||||
|
||||
このポリシーを利用すれば、他のいかなるNetworkPolicyにも選択されなかったPodでも、内向きと外向きのトラフィックが許可されないことを保証できます。
|
||||
|
||||
|
|
|
|||
|
|
@ -25,11 +25,11 @@ weight: 21 # just after persistent volumes
|
|||
|
||||
### secret、downwardAPI、およびconfigMapを使用した構成例 {#example-configuration-secret-downwardapi-configmap}
|
||||
|
||||
{{< codenew file="pods/storage/projected-secret-downwardapi-configmap.yaml" >}}
|
||||
{{% codenew file="pods/storage/projected-secret-downwardapi-configmap.yaml" %}}
|
||||
|
||||
### 構成例:デフォルト以外のアクセス許可モードが設定されたsecret {#example-configuration-secrets-nondefault-permission-mode}
|
||||
|
||||
{{< codenew file="pods/storage/projected-secrets-nondefault-permission-mode.yaml" >}}
|
||||
{{% codenew file="pods/storage/projected-secrets-nondefault-permission-mode.yaml" %}}
|
||||
|
||||
各投影ボリュームソースは、specの`sources`にリストされています。パラメーターは、2つの例外を除いてほぼ同じです。
|
||||
|
||||
|
|
@ -38,7 +38,7 @@ weight: 21 # just after persistent volumes
|
|||
|
||||
`TokenRequestProjection`機能が有効になっている場合、現在の[サービスアカウントトークン](/ja/docs/reference/access-authn-authz/authentication/#service-account-token)を指定されたパスのPodに挿入できます。例えば:
|
||||
|
||||
{{< codenew file="pods/storage/projected-service-account-token.yaml" >}}
|
||||
{{% codenew file="pods/storage/projected-service-account-token.yaml" %}}
|
||||
|
||||
この例のPodには、挿入されたサービスアカウントトークンを含む投影ボリュームがあります。このトークンはPodのコンテナがKubernetes APIサーバーにアクセスするために使用できます。この`audience`フィールドにはトークンの受信対象者が含まれています。トークンの受信者は、トークンの`audience`フィールドで指定された識別子で自分自身であるかを識別します。そうでない場合はトークンを拒否します。このフィールドはオプションで、デフォルトではAPIサーバーの識別子が指定されます。
|
||||
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ CronJobは、クラスターがアイドル状態になりそうなときにJob
|
|||
|
||||
このCronJobマニフェスト例は、毎分ごとに現在の時刻とhelloメッセージを表示します。
|
||||
|
||||
{{< codenew file="application/job/cronjob.yaml" >}}
|
||||
{{% codenew file="application/job/cronjob.yaml" %}}
|
||||
|
||||
([Running Automated Tasks with a CronJob](/ja/docs/tasks/job/automated-tasks-with-cron-jobs/)ではこの例をより詳しく説明しています。).
|
||||
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ DaemonSetのいくつかの典型的な使用例は以下の通りです。
|
|||
|
||||
ユーザーはYAMLファイル内でDaemonSetの設定を記述することができます。例えば、下記の`daemonset.yaml`ファイルでは`fluentd-elasticsearch`というDockerイメージを稼働させるDaemonSetの設定を記述します。
|
||||
|
||||
{{< codenew file="controllers/daemonset.yaml" >}}
|
||||
{{% codenew file="controllers/daemonset.yaml" %}}
|
||||
|
||||
YAMLファイルに基づいてDaemonSetを作成します。
|
||||
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ Deploymentによって作成されたReplicaSetを管理しないでください
|
|||
|
||||
以下はDeploymentの例です。これは`nginx`Podのレプリカを3つ持つReplicaSetを作成します。
|
||||
|
||||
{{< codenew file="controllers/nginx-deployment.yaml" >}}
|
||||
{{% codenew file="controllers/nginx-deployment.yaml" %}}
|
||||
|
||||
この例では、
|
||||
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ Jobで複数のPodを並列で実行することもできます。
|
|||
|
||||
下記にJobの定義例を記載しています。πを2000桁まで計算して出力するJobで、完了するまで約10秒かかります。
|
||||
|
||||
{{< codenew file="controllers/job.yaml" >}}
|
||||
{{% codenew file="controllers/job.yaml" %}}
|
||||
|
||||
このコマンドで実行できます:
|
||||
|
||||
|
|
@ -311,7 +311,7 @@ Podがノードからキックされた(ノードがアップグレード、再
|
|||
|
||||
以下は、`podFailurePolicy`を定義するJobのマニフェストです:
|
||||
|
||||
{{< codenew file="controllers/job-pod-failure-policy-example.yaml" >}}
|
||||
{{% codenew file="controllers/job-pod-failure-policy-example.yaml" %}}
|
||||
|
||||
上記の例では、Pod失敗ポリシーの最初のルールは、`main`コンテナが42の終了コードで失敗した場合、そのJobを失敗とマークすることを指定しています。以下は特に `main`コンテナに関するルールです:
|
||||
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ ReplicaSetはどんな時でも指定された数のPodのレプリカが稼働
|
|||
|
||||
## ReplicaSetの使用例
|
||||
|
||||
{{< codenew file="controllers/frontend.yaml" >}}
|
||||
{{% codenew file="controllers/frontend.yaml" %}}
|
||||
|
||||
上記のマニフェストを`frontend.yaml`ファイルに保存しKubernetesクラスターに適用すると、マニフェストに定義されたReplicaSetとそれが管理するPod群を作成します。
|
||||
|
||||
|
|
@ -128,7 +128,7 @@ metadata:
|
|||
|
||||
前のセクションで取り上げた`frontend`ReplicaSetと、下記のマニフェストのPodをみてみます。
|
||||
|
||||
{{< codenew file="pods/pod-rs.yaml" >}}
|
||||
{{% codenew file="pods/pod-rs.yaml" %}}
|
||||
|
||||
これらのPodは`ownerReferences`に何のコントローラー(もしくはオブジェクト)も指定されておらず、そして`frontend`ReplicaSetにマッチするセレクターをもっており、これらのPodは即座に`frontend`ReplicaSetによって所有されます。
|
||||
|
||||
|
|
@ -297,7 +297,7 @@ ReplicaSetはまた、[Horizontal Pod Autoscalers (HPA)](/docs/tasks/run-applica
|
|||
これはつまりReplicaSetがHPAによってオートスケールされうることを意味します。
|
||||
ここではHPAが、前の例で作成したReplicaSetをターゲットにする例を示します。
|
||||
|
||||
{{< codenew file="controllers/hpa-rs.yaml" >}}
|
||||
{{% codenew file="controllers/hpa-rs.yaml" %}}
|
||||
|
||||
このマニフェストを`hpa-rs.yaml`に保存し、Kubernetesクラスターに適用すると、レプリケートされたPodのCPU使用量にもとづいてターゲットのReplicaSetをオートスケールするHPAを作成します。
|
||||
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ Dockerの概念を使って説明すると、Podは共有の名前空間と共
|
|||
|
||||
以下は、`nginx:1.14.2`イメージが実行されるコンテナからなるPodの例を記載しています。
|
||||
|
||||
{{< codenew file="pods/simple-pod.yaml" >}}
|
||||
{{% codenew file="pods/simple-pod.yaml" %}}
|
||||
|
||||
上記のようなPodを作成するには、以下のコマンドを実行します:
|
||||
```shell
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ weight: 120
|
|||
2つのコンテナは、通信に使用できるボリュームを共有します。
|
||||
これがPodの設定ファイルです:
|
||||
|
||||
{{< codenew file="pods/two-container-pod.yaml" >}}
|
||||
{{% codenew file="pods/two-container-pod.yaml" %}}
|
||||
|
||||
設定ファイルで、Podに`shared-data`という名前のボリュームがあることがわかります。
|
||||
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ weight: 70
|
|||
バックエンドは、単純な挨拶マイクロサービスです。
|
||||
バックエンドのDeploymentの構成ファイルは次のとおりです:
|
||||
|
||||
{{< codenew file="service/access/hello.yaml" >}}
|
||||
{{% codenew file="service/access/hello.yaml" %}}
|
||||
|
||||
バックエンドのDeploymentを作成します:
|
||||
|
||||
|
|
@ -100,7 +100,7 @@ Serviceは{{< glossary_tooltip text="セレクター" term_id="selector" >}}を
|
|||
|
||||
まず、Service構成ファイルを調べます:
|
||||
|
||||
{{< codenew file="service/access/hello-service.yaml" >}}
|
||||
{{% codenew file="service/access/hello-service.yaml" %}}
|
||||
|
||||
設定ファイルで、Serviceが`app：hello`および`tier：backend`というラベルを持つPodにトラフィックをルーティングしていることがわかります。
|
||||
|
||||
|
|
@ -121,12 +121,12 @@ DNS名は`hello`です。これは、前のサービス設定ファイルの`nam
|
|||
フロントエンドDeploymentのPodは、helloバックエンドServiceを見つけるように構成されたnginxイメージを実行します。
|
||||
これはnginx設定ファイルです:
|
||||
|
||||
{{< codenew file="service/access/frontend.conf" >}}
|
||||
{{% codenew file="service/access/frontend.conf" %}}
|
||||
|
||||
バックエンドと同様に、フロントエンドにはDeploymentとServiceがあります。
|
||||
Serviceの設定には`type：LoadBalancer`があります。これは、Serviceがクラウドプロバイダーのデフォルトのロードバランサーを使用することを意味します。
|
||||
|
||||
{{< codenew file="service/access/frontend.yaml" >}}
|
||||
{{% codenew file="service/access/frontend.yaml" %}}
|
||||
|
||||
フロントエンドのDeploymentとServiceを作成します:
|
||||
|
||||
|
|
|
|||
|
|
@ -134,7 +134,7 @@ weight: 110
|
|||
|
||||
1. 以下の内容で`example-ingress.yaml`を作成します。
|
||||
|
||||
{{< codenew file="service/networking/example-ingress.yaml" >}}
|
||||
{{% codenew file="service/networking/example-ingress.yaml" %}}
|
||||
|
||||
1. 次のコマンドを実行して、Ingressリソースを作成します。
|
||||
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ weight: 60
|
|||
|
||||
アプリケーションDeploymentの設定ファイルは以下の通りです:
|
||||
|
||||
{{< codenew file="service/access/hello-application.yaml" >}}
|
||||
{{% codenew file="service/access/hello-application.yaml" %}}
|
||||
|
||||
1. クラスターでHello Worldアプリケーションを稼働させます:
|
||||
上記のファイルを使用し、アプリケーションのDeploymentを作成します:
|
||||
|
|
|
|||
|
|
@ -86,7 +86,7 @@ remote file exists
|
|||
|
||||
`nginx` Serviceへのアクセスを制限するために、`access: true`というラベルが付いたPodだけがクエリできるようにします。次の内容でNetworkPolicyオブジェクトを作成してください。
|
||||
|
||||
{{< codenew file="service/networking/nginx-policy.yaml" >}}
|
||||
{{% codenew file="service/networking/nginx-policy.yaml" %}}
|
||||
|
||||
NetworkPolicyオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)でなければなりません。
|
||||
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ kubectl create namespace constraints-mem-example
|
|||
|
||||
LimitRangeの設定ファイルです。
|
||||
|
||||
{{< codenew file="admin/resource/memory-constraints.yaml" >}}
|
||||
{{% codenew file="admin/resource/memory-constraints.yaml" %}}
|
||||
|
||||
LimitRangeを作成します。
|
||||
|
||||
|
|
@ -82,7 +82,7 @@ Kubernetesは以下の手順を実行するようになっています。
|
|||
以下は、1つのコンテナを持つPodの設定ファイルです。設定ファイルのコンテナ(containers)では、600MiBのメモリー要求と800MiBのメモリー制限が指定されています。これらはLimitRangeによって課される最小と最大のメモリー制約を満たしています。
|
||||
|
||||
|
||||
{{< codenew file="admin/resource/memory-constraints-pod.yaml" >}}
|
||||
{{% codenew file="admin/resource/memory-constraints-pod.yaml" %}}
|
||||
|
||||
Podの作成
|
||||
|
||||
|
|
@ -124,7 +124,7 @@ kubectl delete pod constraints-mem-demo --namespace=constraints-mem-example
|
|||
これは、1つのコンテナを持つPodの設定ファイルです。コンテナは800MiBのメモリー要求と1.5GiBのメモリー制限を指定しています。
|
||||
|
||||
|
||||
{{< codenew file="admin/resource/memory-constraints-pod-2.yaml" >}}
|
||||
{{% codenew file="admin/resource/memory-constraints-pod-2.yaml" %}}
|
||||
|
||||
Podを作成してみます。
|
||||
|
||||
|
|
@ -146,7 +146,7 @@ pods "constraints-mem-demo-2" is forbidden: maximum memory usage per Container i
|
|||
これは、1つのコンテナを持つPodの設定ファイルです。コンテナは100MiBのメモリー要求と800MiBのメモリー制限を指定しています。
|
||||
|
||||
|
||||
{{< codenew file="admin/resource/memory-constraints-pod-3.yaml" >}}
|
||||
{{% codenew file="admin/resource/memory-constraints-pod-3.yaml" %}}
|
||||
|
||||
Podを作成してみます。
|
||||
|
||||
|
|
@ -166,7 +166,7 @@ pods "constraints-mem-demo-3" is forbidden: minimum memory usage per Container i
|
|||
|
||||
これは、1つのコンテナを持つPodの設定ファイルです。コンテナはメモリー要求を指定しておらず、メモリー制限も指定していません。
|
||||
|
||||
{{< codenew file="admin/resource/memory-constraints-pod-4.yaml" >}}
|
||||
{{% codenew file="admin/resource/memory-constraints-pod-4.yaml" %}}
|
||||
|
||||
Podを作成します。
|
||||
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ kubectl create namespace default-mem-example
|
|||
|
||||
以下は、{{< glossary_tooltip text="LimitRange" term_id="limitrange" >}}のマニフェストの例です。このマニフェストでは、デフォルトのメモリー要求とデフォルトのメモリー制限を指定しています。
|
||||
|
||||
{{< codenew file="admin/resource/memory-defaults.yaml" >}}
|
||||
{{% codenew file="admin/resource/memory-defaults.yaml" %}}
|
||||
|
||||
default-mem-exampleネームスペースにLimitRangeを作成します:
|
||||
|
||||
|
|
@ -53,7 +53,7 @@ default-mem-exampleネームスペースでPodを作成し、そのPod内のコ
|
|||
|
||||
以下は、コンテナを1つ持つPodのマニフェストの例です。コンテナは、メモリー要求とメモリー制限を指定していません。
|
||||
|
||||
{{< codenew file="admin/resource/memory-defaults-pod.yaml" >}}
|
||||
{{% codenew file="admin/resource/memory-defaults-pod.yaml" %}}
|
||||
|
||||
Podを作成します:
|
||||
|
||||
|
|
@ -92,7 +92,7 @@ kubectl delete pod default-mem-demo --namespace=default-mem-example
|
|||
|
||||
以下は1つのコンテナを持つPodのマニフェストです。コンテナはメモリー制限を指定しますが、メモリー要求は指定しません。
|
||||
|
||||
{{< codenew file="admin/resource/memory-defaults-pod-2.yaml" >}}
|
||||
{{% codenew file="admin/resource/memory-defaults-pod-2.yaml" %}}
|
||||
|
||||
Podを作成します:
|
||||
|
||||
|
|
@ -122,7 +122,7 @@ resources:
|
|||
|
||||
1つのコンテナを持つPodのマニフェストです。コンテナはメモリー要求を指定しますが、メモリー制限は指定しません。
|
||||
|
||||
{{< codenew file="admin/resource/memory-defaults-pod-3.yaml" >}}
|
||||
{{% codenew file="admin/resource/memory-defaults-pod-3.yaml" %}}
|
||||
|
||||
Podを作成します:
|
||||
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ Kubernetesのコアリポジトリにないクラウドコントローラーマ
|
|||
|
||||
すでにKubernetesのコアリポジトリにあるプロバイダーの場合、クラスター内でデーモンセットとしてKubernetesリポジトリ内部のクラウドコントローラーマネージャーを実行できます。以下をガイドラインとして使用してください。
|
||||
|
||||
{{< codenew file="admin/cloud/ccm-example.yaml" >}}
|
||||
{{% codenew file="admin/cloud/ccm-example.yaml" %}}
|
||||
|
||||
|
||||
## 制限
|
||||
|
|
|
|||
|
|
@ -58,7 +58,7 @@ kubectl create namespace cpu-example
|
|||
|
||||
この練習では、一つのコンテナをもつPodを作成します。コンテナに0.5 CPUの要求と1 CPUの制限を与えます。Podの設定ファイルは次のようになります:
|
||||
|
||||
{{< codenew file="pods/resource/cpu-request-limit.yaml" >}}
|
||||
{{% codenew file="pods/resource/cpu-request-limit.yaml" %}}
|
||||
|
||||
設定ファイルの`args`セクションでは、コンテナ起動時の引数を与えます。`-cpus "2"`という引数では、コンテナに2 CPUを割り当てます。
|
||||
|
||||
|
|
@ -136,7 +136,7 @@ Podのスケジューリングはリソースの要求量に基づいていま
|
|||
|
||||
この練習では、クラスター内のノードのキャパシティを超える大きさのCPU要求を与えたPodを作成します。以下に100 CPUの要求を与えた一つのコンテナを持つ、Podの設定ファイルを示します。これは、クラスター内のノードのキャパシティを超える可能性があります。
|
||||
|
||||
{{< codenew file="pods/resource/cpu-request-limit-2.yaml" >}}
|
||||
{{% codenew file="pods/resource/cpu-request-limit-2.yaml" %}}
|
||||
|
||||
Podを作成してください:
|
||||
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ kubectl create namespace mem-example
|
|||
|
||||
この練習では、一つのコンテナをもつPodを作成します。コンテナに100MiBのメモリー要求と200MiBのメモリー制限を与えます。Podの設定ファイルは次のようになります:
|
||||
|
||||
{{< codenew file="pods/resource/memory-request-limit.yaml" >}}
|
||||
{{% codenew file="pods/resource/memory-request-limit.yaml" %}}
|
||||
|
||||
設定ファイルの`args`セクションでは、コンテナ起動時の引数を与えます。`"--vm-bytes", "150M"`という引数では、コンテナに150MiBのメモリーを割り当てます。
|
||||
|
||||
|
|
@ -116,7 +116,7 @@ kubectl delete pod memory-demo --namespace=mem-example
|
|||
|
||||
この練習では、制限を超えてメモリーを確保しようとするPodを作成します。以下に50MiBのメモリー要求と100MiBのメモリー制限を与えたコンテナを持つ、Podの設定ファイルを示します:
|
||||
|
||||
{{< codenew file="pods/resource/memory-request-limit-2.yaml" >}}
|
||||
{{% codenew file="pods/resource/memory-request-limit-2.yaml" %}}
|
||||
|
||||
設定ファイルの`args`セクションでは、コンテナに250MiBのメモリーを割り当てており、これは100MiBの制限を十分に超えています。
|
||||
|
||||
|
|
@ -216,7 +216,7 @@ Podのスケジューリングは要求に基づいています。Podはノー
|
|||
|
||||
この練習では、クラスター内のノードのキャパシティを超える大きさのメモリー要求を与えたPodを作成します。以下に1000GiBのメモリー要求を与えた一つのコンテナを持つ、Podの設定ファイルを示します。これは、クラスター内のノードのキャパシティを超える可能性があります。
|
||||
|
||||
{{< codenew file="pods/resource/memory-request-limit-3.yaml" >}}
|
||||
{{% codenew file="pods/resource/memory-request-limit-3.yaml" %}}
|
||||
|
||||
Podを作成してください:
|
||||
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ weight: 160
|
|||
|
||||
以下に示すマニフェストには、`requiredDuringSchedulingIgnoredDuringExecution`に`disktype: ssd`というnode affinityを使用したPodが書かれています。このように書くと、Podは`disktype=ssd`というラベルを持つノードにだけスケジューリングされるようになります。
|
||||
|
||||
{{< codenew file="pods/pod-nginx-required-affinity.yaml" >}}
|
||||
{{% codenew file="pods/pod-nginx-required-affinity.yaml" %}}
|
||||
|
||||
1. マニフェストを適用して、選択したノード上にスケジューリングされるPodを作成します。
|
||||
|
||||
|
|
@ -88,7 +88,7 @@ weight: 160
|
|||
|
||||
以下に示すマニフェストには、`preferredDuringSchedulingIgnoredDuringExecution`に`disktype: ssd`というnode affinityを使用したPodが書かれています。このように書くと、Podは`disktype=ssd`というラベルを持つノードに優先的にスケジューリングされるようになります。
|
||||
|
||||
{{< codenew file="pods/pod-nginx-preferred-affinity.yaml" >}}
|
||||
{{% codenew file="pods/pod-nginx-preferred-affinity.yaml" %}}
|
||||
|
||||
1. マニフェストを適用して、選択したノード上にスケジューリングされるPodを作成します。
|
||||
|
||||
|
|
|
|||
|
|
@ -58,7 +58,7 @@ weight: 150
|
|||
|
||||
以下のPodの構成ファイルには、nodeSelectorに`disktype: ssd`を持つPodが書かれています。これにより、Podは`disktype: ssd`というラベルを持っているノードにスケジューリングされるようになります。
|
||||
|
||||
{{< codenew file="pods/pod-nginx.yaml" >}}
|
||||
{{% codenew file="pods/pod-nginx.yaml" %}}
|
||||
|
||||
1. 構成ファイルを使用して、選択したノードにスケジューリングされるPodを作成します。
|
||||
|
||||
|
|
@ -83,7 +83,7 @@ weight: 150
|
|||
|
||||
`nodeName`という設定を使用して、Podを特定のノードにスケジューリングすることもできます。
|
||||
|
||||
{{< codenew file="pods/pod-nginx-specific-node.yaml" >}}
|
||||
{{% codenew file="pods/pod-nginx-specific-node.yaml" %}}
|
||||
|
||||
構成ファイルを使用して、`foo-node`にだけスケジューリングされるPodを作成します。
|
||||
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ weight: 180
|
|||
|
||||
これがPodの設定ファイルです:
|
||||
|
||||
{{< codenew file="pods/lifecycle-events.yaml" >}}
|
||||
{{% codenew file="pods/lifecycle-events.yaml" %}}
|
||||
|
||||
設定ファイルでは、postStartコマンドが`message`ファイルをコンテナの`/usr/share`ディレクトリに書き込むことがわかります。preStopコマンドはnginxを適切にシャットダウンします。これは、障害のためにコンテナが終了している場合に役立ちます。
|
||||
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ Kubernetesはこのような状況を検知し、回復するためのLiveness P
|
|||
この演習では、`registry.k8s.io/busybox`イメージのコンテナを起動するPodを作成します。
|
||||
Podの構成ファイルは次の通りです。
|
||||
|
||||
{{< codenew file="pods/probe/exec-liveness.yaml" >}}
|
||||
{{% codenew file="pods/probe/exec-liveness.yaml" %}}
|
||||
|
||||
この構成ファイルでは、Podは一つの`Container`を起動します。
|
||||
`periodSeconds`フィールドは、kubeletがLiveness Probeを5秒おきに行うように指定しています。
|
||||
|
|
@ -119,7 +119,7 @@ liveness-exec 1/1 Running 1 1m
|
|||
別の種類のLiveness Probeでは、HTTP GETリクエストを使用します。
|
||||
次の構成ファイルは、`registry.k8s.io/liveness`イメージを使用したコンテナを起動するPodを作成します。
|
||||
|
||||
{{< codenew file="pods/probe/http-liveness.yaml" >}}
|
||||
{{% codenew file="pods/probe/http-liveness.yaml" %}}
|
||||
|
||||
この構成ファイルでは、Podは一つの`Container`を起動します。
|
||||
`periodSeconds`フィールドは、kubeletがLiveness Probeを3秒おきに行うように指定しています。
|
||||
|
|
@ -175,7 +175,7 @@ v1.13より後のリリースにおいては、ローカルHTTPプロキシ環
|
|||
この構成においては、kubeletは指定したコンテナのソケットを開くことを試みます。
|
||||
コネクションが確立できる場合はコンテナを正常とみなし、失敗する場合は異常とみなします。
|
||||
|
||||
{{< codenew file="pods/probe/tcp-liveness-readiness.yaml" >}}
|
||||
{{% codenew file="pods/probe/tcp-liveness-readiness.yaml" %}}
|
||||
|
||||
見ての通り、TCPによるチェックの構成はHTTPによるチェックと非常に似ています。
|
||||
この例では、Readiness ProbeとLiveness Probeを両方使用しています。
|
||||
|
|
|
|||
|
|
@ -457,7 +457,7 @@ configmap/special-config-2-c92b5mmcf2 created
|
|||
|
||||
2. ConfigMapに定義された値`special.how`をPod specificationの環境変数`SPECIAL_LEVEL_KEY`に割り当てます。
|
||||
|
||||
{{< codenew file="pods/pod-single-configmap-env-variable.yaml" >}}
|
||||
{{% codenew file="pods/pod-single-configmap-env-variable.yaml" %}}
|
||||
|
||||
Podを作成します:
|
||||
|
||||
|
|
@ -471,7 +471,7 @@ configmap/special-config-2-c92b5mmcf2 created
|
|||
|
||||
* 先ほどの例の通り、まずはConfigMapを作成します。
|
||||
|
||||
{{< codenew file="configmap/configmaps.yaml" >}}
|
||||
{{% codenew file="configmap/configmaps.yaml" %}}
|
||||
|
||||
ConfigMapを作成します:
|
||||
|
||||
|
|
@ -481,7 +481,7 @@ configmap/special-config-2-c92b5mmcf2 created
|
|||
|
||||
* Pod specificationの環境変数を定義します
|
||||
|
||||
{{< codenew file="pods/pod-multiple-configmap-env-variable.yaml" >}}
|
||||
{{% codenew file="pods/pod-multiple-configmap-env-variable.yaml" %}}
|
||||
|
||||
Podを作成します:
|
||||
|
||||
|
|
@ -498,7 +498,7 @@ configmap/special-config-2-c92b5mmcf2 created
|
|||
|
||||
* 複数のキーバリューペアを含むConfigMapを作成します。
|
||||
|
||||
{{< codenew file="configmap/configmap-multikeys.yaml" >}}
|
||||
{{% codenew file="configmap/configmap-multikeys.yaml" %}}
|
||||
|
||||
ConfigMapを作成します:
|
||||
|
||||
|
|
@ -508,7 +508,7 @@ configmap/special-config-2-c92b5mmcf2 created
|
|||
|
||||
* `envFrom`を利用して全てのConfigMapのデータをコンテナ環境変数として定義します。ConfigMapからのキーがPodの環境変数名になります。
|
||||
|
||||
{{< codenew file="pods/pod-configmap-envFrom.yaml" >}}
|
||||
{{% codenew file="pods/pod-configmap-envFrom.yaml" %}}
|
||||
|
||||
Podを作成します:
|
||||
|
||||
|
|
@ -525,7 +525,7 @@ ConfigMapに環境変数を定義し、Pod specificationの`command` セクシ
|
|||
|
||||
例えば以下のPod specificationは
|
||||
|
||||
{{< codenew file="pods/pod-configmap-env-var-valueFrom.yaml" >}}
|
||||
{{% codenew file="pods/pod-configmap-env-var-valueFrom.yaml" %}}
|
||||
|
||||
以下コマンドの実行で作成され、
|
||||
|
||||
|
|
@ -545,7 +545,7 @@ very charm
|
|||
|
||||
このセクションの例は以下に示されているspecial-configと名付けれたConfigMapについて言及したものです。
|
||||
|
||||
{{< codenew file="configmap/configmap-multikeys.yaml" >}}
|
||||
{{% codenew file="configmap/configmap-multikeys.yaml" %}}
|
||||
|
||||
ConfigMapを作成します:
|
||||
|
||||
|
|
@ -558,7 +558,7 @@ kubectl create -f https://kubernetes.io/examples/configmap/configmap-multikeys.y
|
|||
ConfigMap名をPod specificationの`volumes`セクション配下に追加します。
|
||||
これによりConfigMapデータが`volumeMounts.mountPath`で指定されたディレクトリに追加されます (このケースでは、`/etc/config`に)。`command`セクションはConfigMapのキーに合致したディレクトリファイルを名前別でリスト表示します。
|
||||
|
||||
{{< codenew file="pods/pod-configmap-volume.yaml" >}}
|
||||
{{% codenew file="pods/pod-configmap-volume.yaml" %}}
|
||||
|
||||
Podを作成します:
|
||||
|
||||
|
|
@ -586,7 +586,7 @@ SPECIAL_TYPE
|
|||
`path`フィールドを利用して特定のConfigMapのアイテム向けに希望のファイルパスを指定します。
|
||||
このケースでは`SPECIAL_LEVEL`アイテムが`/etc/config/keys`の`config-volume`ボリュームにマウントされます。
|
||||
|
||||
{{< codenew file="pods/pod-configmap-volume-specific-key.yaml" >}}
|
||||
{{% codenew file="pods/pod-configmap-volume-specific-key.yaml" %}}
|
||||
|
||||
Podを作成します:
|
||||
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ weight: 100
|
|||
|
||||
以下にPodの設定ファイルを示します:
|
||||
|
||||
{{< codenew file="pods/storage/projected.yaml" >}}
|
||||
{{% codenew file="pods/storage/projected.yaml" %}}
|
||||
|
||||
1. Secretを作成します:
|
||||
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ weight: 80
|
|||
今回作成するPodには、コンテナが終了して再起動した場合でもPodの寿命が続く[emptyDir](/docs/concepts/storage/volumes/#emptydir)タイプのボリュームがあります。
|
||||
これがPodの設定ファイルです:
|
||||
|
||||
{{< codenew file="pods/storage/redis.yaml" >}}
|
||||
{{% codenew file="pods/storage/redis.yaml" %}}
|
||||
|
||||
1. Podを作成します:
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ weight: 70
|
|||
|
||||
1つのコンテナからなるPodの構成ファイルを示します。
|
||||
|
||||
{{< codenew file="pods/resource/extended-resource-pod.yaml" >}}
|
||||
{{% codenew file="pods/resource/extended-resource-pod.yaml" %}}
|
||||
|
||||
構成ファイルでは、コンテナが3つのdongleをリクエストしていることがわかります。
|
||||
|
||||
|
|
@ -59,7 +59,7 @@ Requests:
|
|||
|
||||
以下に、1つのコンテナを持つPodの構成ファイルを示します。コンテナは2つのdongleをリクエストします。
|
||||
|
||||
{{< codenew file="pods/resource/extended-resource-pod-2.yaml" >}}
|
||||
{{% codenew file="pods/resource/extended-resource-pod-2.yaml" %}}
|
||||
|
||||
Kubernetesは、2つのdongleのリクエストを満たすことができません。1つ目のPodが、利用可能な4つのdongleのうち3つを使用してしまっているためです。
|
||||
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ PodにGuaranteedのQoSクラスを与えるには、以下が必要になりま
|
|||
|
||||
以下に1つのコンテナをもつPodの設定ファイルを示します。コンテナには200MiBのメモリー制限とリクエストを与え、700ミリCPUの制限と要求を与えます。
|
||||
|
||||
{{< codenew file="pods/qos/qos-pod.yaml" >}}
|
||||
{{% codenew file="pods/qos/qos-pod.yaml" %}}
|
||||
|
||||
Podを作成してください:
|
||||
|
||||
|
|
@ -99,7 +99,7 @@ kubectl delete pod qos-demo --namespace=qos-example
|
|||
|
||||
以下に1つのコンテナをもつPodの設定ファイルを示します。コンテナには200MiBのメモリー制限と100MiBのメモリー要求を与えます。
|
||||
|
||||
{{< codenew file="pods/qos/qos-pod-2.yaml" >}}
|
||||
{{% codenew file="pods/qos/qos-pod-2.yaml" %}}
|
||||
|
||||
Podを作成してください:
|
||||
|
||||
|
|
@ -143,7 +143,7 @@ PodにBestEffort QoSクラスを与えるには、Pod内のコンテナにはメ
|
|||
|
||||
以下に1つのコンテナをもつPodの設定ファイルを示します。コンテナにはメモリーやCPUの制限や要求がありません:
|
||||
|
||||
{{< codenew file="pods/qos/qos-pod-3.yaml" >}}
|
||||
{{% codenew file="pods/qos/qos-pod-3.yaml" %}}
|
||||
|
||||
Podを作成してください:
|
||||
|
||||
|
|
@ -179,7 +179,7 @@ kubectl delete pod qos-demo-3 --namespace=qos-example
|
|||
|
||||
以下に2つのコンテナをもつPodの設定ファイルを示します。一方のコンテナは200MiBのメモリー要求を指定し、もう一方のコンテナには要求や制限を指定しません。
|
||||
|
||||
{{< codenew file="pods/qos/qos-pod-4.yaml" >}}
|
||||
{{% codenew file="pods/qos/qos-pod-4.yaml" %}}
|
||||
|
||||
このPodがBurstable QoSクラスの基準を満たしていることに注目してください。つまり、Guaranteed QoSクラスの基準に満たしておらず、一方のコンテナにはメモリー要求を与えられています。
|
||||
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ Podにセキュリティ設定を行うには、Podの設定に`securityContext`
|
|||
`securityContext`フィールドは[PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core)オブジェクトが入ります。
|
||||
Podに設定したセキュリティ設定はPod内の全てのコンテナに適用されます。こちらは`securityContext`と`emptyDir`ボリュームを持ったPodの設定ファイルです。
|
||||
|
||||
{{< codenew file="pods/security/security-context.yaml" >}}
|
||||
{{% codenew file="pods/security/security-context.yaml" %}}
|
||||
|
||||
設定ファイルの中の`runAsUser`フィールドは、Pod内のコンテナに対して全てのプロセスをユーザーID 1000で実行するように指定します。
|
||||
`runAsGroup`フィールドはPod内のコンテナに対して全てのプロセスをプライマリーグループID 3000で実行するように指定します。このフィールドが省略されたときは、コンテナのプライマリーグループIDはroot(0)になります。`runAsGroup`が指定されている場合、作成されたファイルもユーザー1000とグループ3000の所有物になります。
|
||||
|
|
@ -185,7 +185,7 @@ securityContext:
|
|||
|
||||
こちらは一つのコンテナを持つPodの設定ファイルです。Podもコンテナも`securityContext`フィールドを含んでいます。
|
||||
|
||||
{{< codenew file="pods/security/security-context-2.yaml" >}}
|
||||
{{% codenew file="pods/security/security-context-2.yaml" %}}
|
||||
|
||||
Podを作成します。
|
||||
|
||||
|
|
@ -234,7 +234,7 @@ exit
|
|||
まず、`capabilities`フィールドを含まない場合どうなるかを見てみましょう。
|
||||
こちらはコンテナに対してケーパビリティを渡していない設定ファイルです。
|
||||
|
||||
{{< codenew file="pods/security/security-context-3.yaml" >}}
|
||||
{{% codenew file="pods/security/security-context-3.yaml" %}}
|
||||
|
||||
Podを作成します。
|
||||
|
||||
|
|
@ -295,7 +295,7 @@ exit
|
|||
こちらは1つのコンテナを実行するPodの設定ファイルです。
|
||||
`CAP_NET_ADMIN`と`CAP_SYS_TIME`ケーパビリティを設定に追加しました。
|
||||
|
||||
{{< codenew file="pods/security/security-context-4.yaml" >}}
|
||||
{{% codenew file="pods/security/security-context-4.yaml" %}}
|
||||
|
||||
Podを作成します。
|
||||
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ weight: 200
|
|||
プロセス名前空間の共有は、`v1.PodSpec`の`shareProcessNamespace`フィールドを使用して有効にします。
|
||||
例:
|
||||
|
||||
{{< codenew file="pods/share-process-namespace.yaml" >}}
|
||||
{{% codenew file="pods/share-process-namespace.yaml" %}}
|
||||
|
||||
1. クラスターにPod `nginx`を作成します:
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ content_type: task
|
|||
|
||||
この例では、先ほどの例と同様に、Deploymentを使用して2つのpodを作成します。
|
||||
|
||||
{{< codenew file="application/nginx-with-request.yaml" >}}
|
||||
{{% codenew file="application/nginx-with-request.yaml" %}}
|
||||
|
||||
以下のコマンドを実行して、Deploymentを作成します:
|
||||
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ weight: 30
|
|||
この課題では、1つのコンテナを実行するPodを作成します。
|
||||
設定ファイルには、コンテナの開始時に実行されるコマンドを指定します。
|
||||
|
||||
{{< codenew file="debug/termination.yaml" >}}
|
||||
{{% codenew file="debug/termination.yaml" %}}
|
||||
|
||||
1. YAML設定ファイルに基づいてPodを作成します:
|
||||
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ content_type: task
|
|||
このエクササイズでは、1つのコンテナを持つPodを作成します。
|
||||
コンテナはnginxのイメージを実行します。以下がそのPodの設定ファイルです:
|
||||
|
||||
{{< codenew file="application/shell-demo.yaml" >}}
|
||||
{{% codenew file="application/shell-demo.yaml" %}}
|
||||
|
||||
Podを作成します:
|
||||
|
||||
|
|
|
|||
|
|
@ -67,7 +67,7 @@ Kubernetesの監査はクラスター内の一連の行動を記録するセキ
|
|||
|
||||
以下は監査ポリシーファイルの例です:
|
||||
|
||||
{{< codenew file="audit/audit-policy.yaml" >}}
|
||||
{{% codenew file="audit/audit-policy.yaml" %}}
|
||||
|
||||
最小限の監査ポリシーファイルを使用して、すべてのリクエストを `Metadata`レベルで記録することができます。
|
||||
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ weight: 20
|
|||
|
||||
1. `node-problem-detector.yaml`のような`Node Problem Detector`の設定を作成します:
|
||||
|
||||
{{< codenew file="debug/node-problem-detector.yaml" >}}
|
||||
{{% codenew file="debug/node-problem-detector.yaml" %}}
|
||||
|
||||
{{< note >}}
|
||||
システムログのディレクトリが、お使いのOSのディストリビューションに合っていることを確認する必要があります。
|
||||
|
|
@ -74,7 +74,7 @@ weight: 20
|
|||
|
||||
1. `node-problem-detector.yaml`を変更して、`ConfigMap`を使用するようにします。
|
||||
|
||||
{{< codenew file="debug/node-problem-detector-configmap.yaml" >}}
|
||||
{{% codenew file="debug/node-problem-detector-configmap.yaml" %}}
|
||||
|
||||
1. 新しい設定ファイルで`Node Problem Detector`を再作成します。
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ Podを作成するとき、そのPodで実行するコンテナに環境変数
|
|||
|
||||
この演習では、1つのコンテナを実行するPodを作成します。Podの設定ファイルには、名前 `DEMO_GREETING`、値 `"Hello from the environment"`を持つ環境変数が定義されています。Podの設定マニフェストを以下に示します:
|
||||
|
||||
{{< codenew file="pods/inject/envars.yaml" >}}
|
||||
{{% codenew file="pods/inject/envars.yaml" %}}
|
||||
|
||||
1. マニフェストに基づいてPodを作成します:
|
||||
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ OSから信頼されているローカルツールを使用することで、外
|
|||
|
||||
以下はユーザー名とパスワードを保持するSecretを作成するために使用できる設定ファイルです:
|
||||
|
||||
{{< codenew file="pods/inject/secret.yaml" >}}
|
||||
{{% codenew file="pods/inject/secret.yaml" %}}
|
||||
|
||||
1. Secret を作成する
|
||||
|
||||
|
|
@ -97,7 +97,7 @@ kubectl create secret generic test-secret --from-literal='username=my-app' --fro
|
|||
|
||||
これはPodの作成に使用できる設定ファイルです。
|
||||
|
||||
{{< codenew file="pods/inject/secret-pod.yaml" >}}
|
||||
{{% codenew file="pods/inject/secret-pod.yaml" %}}
|
||||
|
||||
1. Podを作成する:
|
||||
|
||||
|
|
@ -161,7 +161,7 @@ kubectl create secret generic test-secret --from-literal='username=my-app' --fro
|
|||
|
||||
* Secretで定義された`backend-username`の値をPodの環境変数`SECRET_USERNAME`に割り当てます。
|
||||
|
||||
{{< codenew file="pods/inject/pod-single-secret-env-variable.yaml" >}}
|
||||
{{% codenew file="pods/inject/pod-single-secret-env-variable.yaml" %}}
|
||||
|
||||
* Podを作成する:
|
||||
|
||||
|
|
@ -191,7 +191,7 @@ kubectl create secret generic test-secret --from-literal='username=my-app' --fro
|
|||
|
||||
* Podの中で環境変数を定義する:
|
||||
|
||||
{{< codenew file="pods/inject/pod-multiple-secret-env-variable.yaml" >}}
|
||||
{{% codenew file="pods/inject/pod-multiple-secret-env-variable.yaml" %}}
|
||||
|
||||
* Podを作成する:
|
||||
|
||||
|
|
@ -225,7 +225,7 @@ kubectl create secret generic test-secret --from-literal='username=my-app' --fro
|
|||
|
||||
* envFromを使用してSecretのすべてのデータをコンテナの環境変数として定義します。SecretのキーがPodの環境変数名になります。
|
||||
|
||||
{{< codenew file="pods/inject/pod-secret-envFrom.yaml" >}}
|
||||
{{% codenew file="pods/inject/pod-secret-envFrom.yaml" %}}
|
||||
|
||||
* Podを作成する:
|
||||
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ Podとコンテナのフィールドを実行中のコンテナに共有する
|
|||
|
||||
この演習では、1つのコンテナを持つPodを作成します。Podの設定ファイルは次のとおりです:
|
||||
|
||||
{{< codenew file="pods/inject/dapi-envars-pod.yaml" >}}
|
||||
{{% 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のフィールドから名前を取得します。
|
||||
|
||||
|
|
@ -102,7 +102,7 @@ MY_POD_NAME=dapi-envars-fieldref
|
|||
|
||||
前の演習では、環境変数の値としてPodフィールドを使用しました。次の演習では、環境変数の値としてコンテナフィールドを使用します。これは、1つのコンテナを持つPodの設定ファイルです:
|
||||
|
||||
{{< codenew file="pods/inject/dapi-envars-container.yaml" >}}
|
||||
{{% 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`フィールドから取得することを指定します。同様に、他の環境変数もコンテナのフィールドから値を取得します。
|
||||
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ CronJobには制限と特性があります。たとえば、特定の状況下
|
|||
|
||||
CronJobには設定ファイルが必要です。次の例のCronJobの`.spec`は、現在の時刻とhelloというメッセージを1分ごとに表示します。
|
||||
|
||||
{{< codenew file="application/job/cronjob.yaml" >}}
|
||||
{{% codenew file="application/job/cronjob.yaml" %}}
|
||||
|
||||
次のコマンドで例のCronJobを実行します。
|
||||
|
||||
|
|
|
|||
|
|
@ -50,13 +50,13 @@ rev data.txt
|
|||
|
||||
以下は、completion modeとして`Indexed`を使用するJobのマニフェストの例です。
|
||||
|
||||
{{< codenew language="yaml" file="application/job/indexed-job.yaml" >}}
|
||||
{{% codenew language="yaml" file="application/job/indexed-job.yaml" %}}
|
||||
|
||||
上記の例では、Jobコントローラーがすべてのコンテナに設定する組み込みの`JOB_COMPLETION_INDEX`環境変数を使っています。[initコンテナ](/ja/docs/concepts/workloads/pods/init-containers/)がインデックスを静的な値にマッピングし、その値をファイルに書き込み、ファイルを[emptyDir volume](/docs/concepts/storage/volumes/#emptydir)を介してワーカーを実行しているコンテナと共有します。オプションとして、インデックスとコンテナに公開するために[downward APIを使用して独自の環境変数を定義する](/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)こともできます。[環境変数やファイルとして設定したConfigMap](/ja/docs/tasks/configure-pod-container/configure-pod-configmap/)から値のリストを読み込むという選択肢もあります。
|
||||
|
||||
他には、以下の例のように、直接[downward APIを使用してアノテーションの値をボリュームファイルとして渡す](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#store-pod-fields)こともできます。
|
||||
|
||||
{{< codenew language="yaml" file="application/job/indexed-job-vol.yaml" >}}
|
||||
{{% codenew language="yaml" file="application/job/indexed-job-vol.yaml" %}}
|
||||
|
||||
## Jobを実行する
|
||||
|
||||
|
|
|
|||
|
|
@ -61,7 +61,7 @@ fe00::2 ip6-allrouters
|
|||
|
||||
デフォルトのボイラープレートに加えて、`hosts`ファイルに追加エントリーを追加できます。たとえば、`foo.local`と`bar.local`を`127.0.0.1`に、`foo.remote`と`bar.remote`を`10.1.2.3`にそれぞれ解決するためには、PodのHostAliasesを`.spec.hostAliases`以下に設定します。
|
||||
|
||||
{{< codenew file="service/networking/hostaliases-pod.yaml" >}}
|
||||
{{% codenew file="service/networking/hostaliases-pod.yaml" %}}
|
||||
|
||||
この設定を使用したPodを開始するには、次のコマンドを実行します。
|
||||
|
||||
|
|
|
|||
|
|
@ -100,7 +100,7 @@ fe00::2 ip6-allrouters
|
|||
|
||||
`.spec.isFamilyPolicy`を明示的に定義していない、以下のようなServiceを作成してみます。Kubernetesは最初に設定した`service-cluster-ip-range`の範囲からServiceにcluster IPを割り当てて、`.spec.ipFamilyPolicy`を`SingleStack`に設定します。
|
||||
|
||||
{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
|
||||
{{% codenew file="service/networking/dual-stack-default-svc.yaml" %}}
|
||||
|
||||
`kubectl`を使ってServiceのYAMLを表示します。
|
||||
|
||||
|
|
@ -137,7 +137,7 @@ status:
|
|||
|
||||
`.spec.ipFamilies`内の配列の1番目の要素に`IPv6`を明示的に指定した、次のようなServiceを作成してみます。Kubernetesは`service-cluster-ip-range`で設定したIPv6の範囲からcluster IPを割り当てて、`.spec.ipFamilyPolicy`を`SingleStack`に設定します。
|
||||
|
||||
{{< codenew file="service/networking/dual-stack-ipfamilies-ipv6.yaml" >}}
|
||||
{{% codenew file="service/networking/dual-stack-ipfamilies-ipv6.yaml" %}}
|
||||
|
||||
`kubectl`を使ってServiceのYAMLを表示します。
|
||||
|
||||
|
|
@ -175,7 +175,7 @@ status:
|
|||
|
||||
`.spec.ipFamiliePolicy`に`PreferDualStack`を明示的に指定した、次のようなServiceを作成してみます。Kubernetesは(クラスターでデュアルスタックを有効化しているため)IPv4およびIPv6のアドレスの両方を割り当て、`.spec.ClusterIPs`のリストから、`.spec.ipFamilies`配列の最初の要素のアドレスファミリーに基づいた`.spec.ClusterIP`を設定します。
|
||||
|
||||
{{< codenew file="service/networking/dual-stack-preferred-svc.yaml" >}}
|
||||
{{% codenew file="service/networking/dual-stack-preferred-svc.yaml" %}}
|
||||
|
||||
{{< note >}}
|
||||
`kubectl get svc`コマンドは、`CLUSTER-IP`フィールドにプライマリーのIPだけしか表示しません。
|
||||
|
|
@ -216,7 +216,7 @@ Events: <none>
|
|||
|
||||
クラウドプロバイダーがIPv6を有効化した外部ロードバランサーのプロビジョニングをサポートする場合、`.spec.ipFamilyPolicy`に`PreferDualStack`を指定し、`.spec.ipFamilies`の最初の要素を`IPv6`にして、`type`フィールドに`LoadBalancer`を指定したServiceを作成できます。
|
||||
|
||||
{{< codenew file="service/networking/dual-stack-prefer-ipv6-lb-svc.yaml" >}}
|
||||
{{% codenew file="service/networking/dual-stack-prefer-ipv6-lb-svc.yaml" %}}
|
||||
|
||||
Serviceを確認します。
|
||||
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ RUN chmod a+rx index.php
|
|||
まず最初に、イメージを動かすDeploymentを起動し、Serviceとして公開しましょう。
|
||||
下記の設定を使います。
|
||||
|
||||
{{< codenew file="application/php-apache.yaml" >}}
|
||||
{{% codenew file="application/php-apache.yaml" %}}
|
||||
|
||||
以下のコマンドを実行してください。
|
||||
|
||||
|
|
@ -390,7 +390,7 @@ Events:
|
|||
|
||||
`kubectl autoscale`コマンドを使って命令的にHorizontalPodAutoscalerを作るかわりに、下記のファイルを使って宣言的に作成することができます。
|
||||
|
||||
{{< codenew file="application/hpa/php-apache.yaml" >}}
|
||||
{{% codenew file="application/hpa/php-apache.yaml" %}}
|
||||
|
||||
下記のコマンドを実行してAutoscalerを作成します。
|
||||
|
||||
|
|
|
|||
|
|
@ -56,7 +56,7 @@ weight: 30
|
|||
kubectl apply -f https://k8s.io/examples/application/mysql/mysql-configmap.yaml
|
||||
```
|
||||
|
||||
{{< codenew file="application/mysql/mysql-configmap.yaml" >}}
|
||||
{{% codenew file="application/mysql/mysql-configmap.yaml" %}}
|
||||
|
||||
このConfigMapは、MySQLマスターとスレーブの設定を独立して制御するために、
|
||||
それぞれの`my.cnf`を上書きする内容を提供します。
|
||||
|
|
@ -75,7 +75,7 @@ ConfigMap自体に特別なことはありませんが、ConfigMapの各部分
|
|||
kubectl apply -f https://k8s.io/examples/application/mysql/mysql-services.yaml
|
||||
```
|
||||
|
||||
{{< codenew file="application/mysql/mysql-services.yaml" >}}
|
||||
{{% codenew file="application/mysql/mysql-services.yaml" %}}
|
||||
|
||||
ヘッドレスサービスは、StatefulSetコントローラーが
|
||||
StatefulSetの一部であるPodごとに作成するDNSエントリーのベースエントリーを提供します。
|
||||
|
|
@ -98,7 +98,7 @@ MySQLマスターは1つしかいないため、クライアントが書き込
|
|||
kubectl apply -f https://k8s.io/examples/application/mysql/mysql-statefulset.yaml
|
||||
```
|
||||
|
||||
{{< codenew file="application/mysql/mysql-statefulset.yaml" >}}
|
||||
{{% codenew file="application/mysql/mysql-statefulset.yaml" %}}
|
||||
|
||||
次のコマンドを実行して起動の進行状況を確認できます。
|
||||
|
||||
|
|
|
|||
|
|
@ -42,8 +42,8 @@ Kubernetes Deploymentを作成し、PersistentVolumeClaimを使用して既存
|
|||
|
||||
注：パスワードはYAMLファイル内に定義されており、これは安全ではありません。安全な解決策については[Kubernetes Secret](/docs/concepts/configuration/secret/)を参照してください 。
|
||||
|
||||
{{< codenew file="application/mysql/mysql-deployment.yaml" >}}
|
||||
{{< codenew file="application/mysql/mysql-pv.yaml" >}}
|
||||
{{% codenew file="application/mysql/mysql-deployment.yaml" %}}
|
||||
{{% codenew file="application/mysql/mysql-pv.yaml" %}}
|
||||
|
||||
1. YAMLファイルに記述されたPVとPVCをデプロイします。
|
||||
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ weight: 10
|
|||
|
||||
Kubernetes Deploymentオブジェクトを作成することでアプリケーションを実行できます。また、YAMLファイルでDeploymentを記述できます。例えば、このYAMLファイルはnginx:1.14.2 Dockerイメージを実行するデプロイメントを記述しています:
|
||||
|
||||
{{< codenew file="application/deployment.yaml" >}}
|
||||
{{% codenew file="application/deployment.yaml" %}}
|
||||
|
||||
|
||||
1. YAMLファイルに基づいてDeploymentを作成します:
|
||||
|
|
@ -97,7 +97,7 @@ Kubernetes Deploymentオブジェクトを作成することでアプリケー
|
|||
|
||||
新しいYAMLファイルを適用してDeploymentを更新できます。このYAMLファイルは、Deploymentを更新してnginx 1.16.1を使用するように指定しています。
|
||||
|
||||
{{< codenew file="application/deployment-update.yaml" >}}
|
||||
{{% codenew file="application/deployment-update.yaml" %}}
|
||||
|
||||
1. 新しいYAMLファイルを適用します:
|
||||
|
||||
|
|
@ -111,7 +111,7 @@ Kubernetes Deploymentオブジェクトを作成することでアプリケー
|
|||
|
||||
新しいYAMLファイルを適用することで、Deployment内のPodの数を増やすことができます。このYAMLファイルは`replicas`を4に設定します。これはDeploymentが4つのPodを持つべきであることを指定します:
|
||||
|
||||
{{< codenew file="application/deployment-scale.yaml" >}}
|
||||
{{% codenew file="application/deployment-scale.yaml" %}}
|
||||
|
||||
1. 新しいYAMLファイルを適用します:
|
||||
|
||||
|
|
|
|||
|
|
@ -161,7 +161,7 @@ done
|
|||
|
||||
次に、deny-writeプロファイルを使用した単純な "Hello AppArmor" Podを実行します。
|
||||
|
||||
{{< codenew file="pods/security/hello-apparmor.yaml" >}}
|
||||
{{% codenew file="pods/security/hello-apparmor.yaml" %}}
|
||||
|
||||
```shell
|
||||
kubectl create -f ./hello-apparmor.yaml
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ content_type: tutorial
|
|||
|
||||
最初に、`redis-config`ファイルからConfigMapを含む`kustomization.yaml`を作成します:
|
||||
|
||||
{{< codenew file="pods/config/redis-config" >}}
|
||||
{{% codenew file="pods/config/redis-config" %}}
|
||||
|
||||
```shell
|
||||
curl -OL https://k8s.io/examples/pods/config/redis-config
|
||||
|
|
@ -54,7 +54,7 @@ EOF
|
|||
|
||||
Podリソースの設定を`kustomization.yaml`に入れます:
|
||||
|
||||
{{< codenew file="pods/config/redis-pod.yaml" >}}
|
||||
{{% codenew file="pods/config/redis-pod.yaml" %}}
|
||||
|
||||
```shell
|
||||
curl -OL https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/pods/config/redis-pod.yaml
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ Kubernetesは各Podにそれぞれ固有のクラスタープライベートなI
|
|||
これは前出の例でも行いましたが、もう一度やってみて、ネットワークからの観点に着目してみましょう。
|
||||
nginx Podを作成し、コンテナのポート指定も記載します:
|
||||
|
||||
{{< codenew file="service/networking/run-my-nginx.yaml" >}}
|
||||
{{% codenew file="service/networking/run-my-nginx.yaml" %}}
|
||||
|
||||
この設定で、あなたのクラスターにはどのノードからもアクセス可能になります。Podを実行中のノードを確認してみましょう:
|
||||
|
||||
|
|
@ -79,7 +79,7 @@ service/my-nginx exposed
|
|||
|
||||
これは`kubectl apply -f`を以下のyamlに対して実行するのと同じです:
|
||||
|
||||
{{< codenew file="service/networking/nginx-svc.yaml" >}}
|
||||
{{% codenew file="service/networking/nginx-svc.yaml" %}}
|
||||
|
||||
この指定は、`run: my-nginx`ラベルの付いた任意のPod上のTCPポート80を宛先とし、それを抽象化されたServiceポート(`targetPort`はコンテナがトラフィックを許可するポート、`port`は抽象化されたServiceポートで、ほかのPodがServiceにアクセスするのに使う任意のポートです)で公開するServiceを作成します。
|
||||
Service定義内でサポートされているフィールドのリストを見るには、[Service](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core) APIオブジェクトを参照してください。
|
||||
|
|
@ -303,7 +303,7 @@ nginxsecret kubernetes.io/tls 2 1m
|
|||
|
||||
Secretにある証明書を使ってhttpsサーバーを開始するために、nginxレプリカを変更します。また、Serviceは(80および443の)両方のポートを公開するようにします:
|
||||
|
||||
{{< codenew file="service/networking/nginx-secure-app.yaml" >}}
|
||||
{{% codenew file="service/networking/nginx-secure-app.yaml" %}}
|
||||
|
||||
nginx-secure-appマニフェストの注目すべきポイント:
|
||||
|
||||
|
|
@ -335,7 +335,7 @@ node $ curl -k https://10.244.3.5
|
|||
Serviceを作成することで、証明書で使われているCNameと、PodがServiceルックアップ時に使う実際のDNS名とがリンクされます。
|
||||
Podからこれをテストしてみましょう(単純化のため同じSecretが再利用されるので、ServiceにアクセスするのにPodが必要なのはnginx.crtだけです):
|
||||
|
||||
{{< codenew file="service/networking/curlpod.yaml" >}}
|
||||
{{% codenew file="service/networking/curlpod.yaml" %}}
|
||||
|
||||
```shell
|
||||
kubectl apply -f ./curlpod.yaml
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ weight: 60
|
|||
|
||||
1つの`nginx`レプリカを含むDeployment(純粋にデモンストレーション目的です)とServiceがあるとします:
|
||||
|
||||
{{< codenew file="service/pod-with-graceful-termination.yaml" >}}
|
||||
{{% codenew file="service/pod-with-graceful-termination.yaml" %}}
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ StatefulSetはステートフルアプリケーションや分散システムで
|
|||
|
||||
はじめに、以下の例を使ってStatefulSetを作成しましょう。これは、コンセプトの[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)のページで使ったものと同じような例です。`nginx`という[headless Service](/ja/docs/concepts/services-networking/service/#headless-services)を作成し、`web`というStatefulSet内のPodのIPアドレスを公開します。
|
||||
|
||||
{{< codenew file="application/web/web.yaml" >}}
|
||||
{{% codenew file="application/web/web.yaml" %}}
|
||||
|
||||
上の例をダウンロードして、`web.yaml`という名前で保存します。
|
||||
|
||||
|
|
@ -908,7 +908,7 @@ statefulset "web" deleted
|
|||
|
||||
`Parallel`のPod管理では、StatefulSetコントローラーに対して、PodがRunningかつReadyの状態や完全に停止するまで待たないように指示し、すべてのPodを並列に起動または停止させるようにします。
|
||||
|
||||
{{< codenew file="application/web/web-parallel.yaml" >}}
|
||||
{{% codenew file="application/web/web-parallel.yaml" %}}
|
||||
|
||||
上の例をダウンロードして、`web-parallel.yaml`という名前でファイルに保存してください。
|
||||
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ Kubernetesでは、{{< glossary_tooltip text="Service" term_id="service" >}}は
|
|||
|
||||
以下のServiceは、Cassandra Podとクラスター内のクライアント間のDNSルックアップに使われます:
|
||||
|
||||
{{< codenew file="application/cassandra/cassandra-service.yaml" >}}
|
||||
{{% codenew file="application/cassandra/cassandra-service.yaml" %}}
|
||||
|
||||
`cassandra-service.yaml`ファイルから、Cassandra StatefulSetのすべてのメンバーをトラッキングするServiceを作成します。
|
||||
|
||||
|
|
@ -91,7 +91,7 @@ cassandra ClusterIP None <none> 9042/TCP 45s
|
|||
クラウドを使用している場合、StatefulSetを更新してください。
|
||||
{{< /note >}}
|
||||
|
||||
{{< codenew file="application/cassandra/cassandra-statefulset.yaml" >}}
|
||||
{{% codenew file="application/cassandra/cassandra-statefulset.yaml" %}}
|
||||
|
||||
`cassandra-statefulset.yaml`ファイルから、CassandraのStatefulSetを作成します:
|
||||
|
||||
|
|
|
|||
|
|
@ -92,12 +92,12 @@ EOF
|
|||
|
||||
以下のマニフェストには、シングルインスタンスのMySQLのDeploymentが書かれています。MySQLコンテナはPersistentVolumeを`/var/lib/mysql`にマウントします。`MYSQL_ROOT_PASSWORD`環境変数には、Secretから得られたデータベースのパスワードが設定されます。
|
||||
|
||||
{{< codenew file="application/wordpress/mysql-deployment.yaml" >}}
|
||||
{{% codenew file="application/wordpress/mysql-deployment.yaml" %}}
|
||||
|
||||
以下のマニフェストには、シングルインスタンスのWordPressのDeploymentが書かれています。WordPressコンテナはPersistentVolumeをウェブサイトのデータファイルのために`/var/www/html`にマウントします。`WORDPRESS_DB_HOST`環境変数に上で定義したMySQLのServiceの名前を設定すると、WordPressはServiceによってデータベースにアクセスします。`WORDPRESS_DB_PASSWORD`環境変数には、kustomizeが生成したSecretから得たデータベースのパスワードが設定されます。
|
||||
|
||||
|
||||
{{< codenew file="application/wordpress/wordpress-deployment.yaml" >}}
|
||||
{{% codenew file="application/wordpress/wordpress-deployment.yaml" %}}
|
||||
|
||||
1. MySQLのDeploymentの設定ファイルをダウンロードします。
|
||||
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ WALを際限のない増加から防ぐために、ZooKeeperサーバーは、
|
|||
|
||||
以下のマニフェストは[Headless Service](/ja/docs/concepts/services-networking/service/#headless-services)、[Service](/ja/docs/concepts/services-networking/service/)、[PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/#pod-disruption-budgets)、[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)を含んでいます。
|
||||
|
||||
{{< codenew file="application/zookeeper/zookeeper.yaml" >}}
|
||||
{{% codenew file="application/zookeeper/zookeeper.yaml" %}}
|
||||
|
||||
ターミナルを開き、マニフェストを作成するために
|
||||
[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply)コマンドを使います。
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ weight: 10
|
|||
|
||||
1. クラスターにてHello Worldアプリケーションを実行してください。
|
||||
|
||||
{{< codenew file="service/load-balancer-example.yaml" >}}
|
||||
{{% codenew file="service/load-balancer-example.yaml" %}}
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ card:
|
|||
|
||||
以下のマニフェストファイルは、シングルレプリカのRedisのマスターPodを実行するDeploymentコントローラーを指定しています。
|
||||
|
||||
{{< codenew file="application/guestbook/redis-master-deployment.yaml" >}}
|
||||
{{% codenew file="application/guestbook/redis-master-deployment.yaml" %}}
|
||||
|
||||
1. マニフェストファイルをダウンロードしたディレクトリ内で、ターミナルウィンドウを起動します。
|
||||
1. `redis-master-deployment.yaml`ファイルから、RedisのマスターのDeploymentを適用します。
|
||||
|
|
@ -81,7 +81,7 @@ POD-NAMEの部分を実際のPodの名前に書き換えてください。
|
|||
|
||||
ゲストブックアプリケーションは、データを書き込むためにRedisのマスターと通信する必要があります。そのためには、[Service](/ja/docs/concepts/services-networking/service/)を適用して、トラフィックをRedisのマスターのPodへプロキシーしなければなりません。Serviceは、Podにアクセスするためのポリシーを指定します。
|
||||
|
||||
{{< codenew file="application/guestbook/redis-master-service.yaml" >}}
|
||||
{{% codenew file="application/guestbook/redis-master-service.yaml" %}}
|
||||
|
||||
1. 次の`redis-master-service.yaml`から、RedisのマスターのServiceを適用します。
|
||||
|
||||
|
|
@ -118,7 +118,7 @@ Deploymentはマニフェストファイル内に書かれた設定に基づい
|
|||
|
||||
もし1つもレプリカが実行されていなければ、このDeploymentは2つのレプリカをコンテナクラスター上で起動します。逆に、もしすでに2つ以上のレプリカが実行されていれば、実行中のレプリカが2つになるようにスケールダウンします。
|
||||
|
||||
{{< codenew file="application/guestbook/redis-slave-deployment.yaml" >}}
|
||||
{{% codenew file="application/guestbook/redis-slave-deployment.yaml" %}}
|
||||
|
||||
1. `redis-slave-deployment.yaml`ファイルから、RedisのスレーブのDeploymentを適用します。
|
||||
|
||||
|
|
@ -145,7 +145,7 @@ Deploymentはマニフェストファイル内に書かれた設定に基づい
|
|||
|
||||
ゲストブックアプリケーションは、データを読み込むためにRedisのスレーブと通信する必要があります。Redisのスレーブが発見できるようにするためには、Serviceをセットアップする必要があります。Serviceは一連のPodに対する透過的なロードバランシングを提供します。
|
||||
|
||||
{{< codenew file="application/guestbook/redis-slave-service.yaml" >}}
|
||||
{{% codenew file="application/guestbook/redis-slave-service.yaml" %}}
|
||||
|
||||
1. 次の`redis-slave-service.yaml`ファイルから、RedisのスレーブのServiceを適用します。
|
||||
|
||||
|
|
@ -174,7 +174,7 @@ Deploymentはマニフェストファイル内に書かれた設定に基づい
|
|||
|
||||
### ゲストブックのフロントエンドのDeploymentを作成する
|
||||
|
||||
{{< codenew file="application/guestbook/frontend-deployment.yaml" >}}
|
||||
{{% codenew file="application/guestbook/frontend-deployment.yaml" %}}
|
||||
|
||||
1. `frontend-deployment.yaml`ファイルから、フロントエンドのDeploymentを適用します。
|
||||
|
||||
|
|
@ -207,7 +207,7 @@ Deploymentはマニフェストファイル内に書かれた設定に基づい
|
|||
一部のクラウドプロバイダーでは、Google Compute EngineやGoogle Kubernetes Engineなど、外部のロードバランサーをサポートしているものがあります。もしクラウドプロバイダーがロードバランサーをサポートしていて、それを使用したい場合は、`type: NodePort`という行を単に削除またはコメントアウトして、`type: LoadBalancer`のコメントアウトを外せば使用できます。
|
||||
{{< /note >}}
|
||||
|
||||
{{< codenew file="application/guestbook/frontend-service.yaml" >}}
|
||||
{{% codenew file="application/guestbook/frontend-service.yaml" %}}
|
||||
|
||||
1. `frontend-service.yaml`ファイルから、フロントエンドのServiceを提供します。
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue