[ja] replaced {{< codenew ... >}} with {{% codenew ... %}} (#42211)

* JA localization: replaced {{< codenew ... >}} with {{% codenew ... %}} in all files * JA localization: replaced {{< codenew ... >}} with {{% codenew ... %}} in all files

Author: andreygoran

content/ja/docs/concepts/cluster-administration/logging.md

@@ -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,15 +185,15 @@ 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/)を参照してください。
 {{< /note >}}
 
 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を任意のロギングエージェントに置き換えて、アプリケーションコンテナ内の任意のソースから読み取ることができます。
 

content/ja/docs/concepts/cluster-administration/manage-deployment.md

@@ -21,7 +21,7 @@ weight: 40
 多くのアプリケーションではDeploymentやServiceなど複数のリソースの作成を要求します。複数のリソースの管理は、同一のファイルにひとまとめにしてグループ化すると簡単になります(YAMLファイル内で`---`で区切る)。
 例えば:
 
-{{< codenew file="application/nginx-app.yaml" >}}
+{{% codenew file="application/nginx-app.yaml" %}}
 
 複数のリソースは単一のリソースと同様の方法で作成できます。
 

content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md

@@ -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`ファイルを引数に指定し、実行します。ここで例を示します:
 

content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md

@@ -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`を使用しています。

content/ja/docs/concepts/scheduling-eviction/taint-and-toleration.md

@@ -52,7 +52,7 @@ tolerations:
 
 tolerationを設定したPodの例を示します。
 
-{{< codenew file="pods/pod-with-toleration.yaml" >}}
+{{% codenew file="pods/pod-with-toleration.yaml" %}}
 
 `operator`のデフォルトは`Equal`です。
 

content/ja/docs/concepts/services-networking/connect-applications-service.md

@@ -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

content/ja/docs/concepts/services-networking/dns-pod-service.md

@@ -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`ファイル内にある下記の内容を取得します。
 

content/ja/docs/concepts/services-networking/dual-stack.md

@@ -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
 

content/ja/docs/concepts/services-networking/ingress.md

@@ -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,15 +257,15 @@ 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のタイプ
 
 ### 単一ServiceのIngress {#single-service-ingress}
 
 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コントローラーのドキュメントを確認してください。