From 3337ce58bf2253f59debab01c0762ec8699c59a3 Mon Sep 17 00:00:00 2001 From: Junya Okabe Date: Sat, 24 Feb 2024 02:17:13 +0900 Subject: [PATCH] fix: internal refs --- content/ja/docs/concepts/_index.md | 8 +-- .../ja/docs/concepts/architecture/cgroups.md | 4 +- .../control-plane-node-communication.md | 2 +- .../architecture/garbage-collection.md | 8 +-- .../ja/docs/concepts/architecture/nodes.md | 4 +- .../cluster-administration-overview.md | 14 ++--- .../manage-deployment.md | 2 +- .../cluster-administration/system-logs.md | 6 +- .../manage-resources-containers.md | 10 +-- .../docs/concepts/configuration/overview.md | 2 +- .../ja/docs/concepts/configuration/secret.md | 12 ++-- content/ja/docs/concepts/containers/_index.md | 2 +- .../docs/concepts/containers/runtime-class.md | 2 +- .../docs/concepts/extend-kubernetes/_index.md | 16 ++--- .../extend-kubernetes/extend-cluster.md | 12 ++-- content/ja/docs/concepts/overview/_index.md | 2 +- .../docs/concepts/overview/kubernetes-api.md | 10 +-- .../working-with-objects/field-selectors.md | 2 +- .../working-with-objects/finalizers.md | 4 +- .../kubernetes-objects.md | 2 +- .../overview/working-with-objects/labels.md | 2 +- .../working-with-objects/namespaces.md | 2 +- .../ja/docs/concepts/policy/limit-range.md | 2 +- .../docs/concepts/policy/resource-quotas.md | 2 +- .../scheduling-eviction/api-eviction.md | 2 +- .../scheduling-eviction/assign-pod-node.md | 2 +- .../scheduling-eviction/kube-scheduler.md | 10 +-- .../scheduling-eviction/pod-overhead.md | 2 +- .../resource-bin-packing.md | 2 +- .../scheduling-framework.md | 4 +- .../taint-and-toleration.md | 6 +- content/ja/docs/concepts/security/overview.md | 6 +- .../security/pod-security-admission.md | 4 +- .../security/pod-security-standards.md | 10 +-- .../service-traffic-policy.md | 2 +- .../concepts/storage/dynamic-provisioning.md | 4 +- .../concepts/storage/ephemeral-volumes.md | 2 +- .../concepts/storage/persistent-volumes.md | 62 +++++++++---------- .../concepts/storage/projected-volumes.md | 10 +-- .../docs/concepts/storage/storage-capacity.md | 4 +- .../docs/concepts/storage/storage-classes.md | 2 +- .../storage/volume-health-monitoring.md | 2 +- .../concepts/storage/volume-pvc-datasource.md | 2 +- .../storage/volume-snapshot-classes.md | 2 +- content/ja/docs/concepts/storage/volumes.md | 22 +++---- content/ja/docs/concepts/workloads/_index.md | 2 +- .../workloads/controllers/cron-jobs.md | 2 +- .../workloads/controllers/statefulset.md | 2 +- .../workloads/controllers/ttlafterfinished.md | 2 +- .../ja/docs/concepts/workloads/pods/_index.md | 2 +- .../concepts/workloads/pods/pod-lifecycle.md | 2 +- content/ja/docs/contribute/_index.md | 8 +-- content/ja/docs/contribute/localization.md | 2 +- .../ja/docs/contribute/new-content/_index.md | 8 +-- .../ja/docs/contribute/participate/_index.md | 4 +- .../docs/contribute/review/for-approvers.md | 2 +- .../docs/contribute/review/reviewing-prs.md | 6 +- .../ja/docs/contribute/style/content-guide.md | 2 +- .../contribute/style/content-organization.md | 6 +- .../ja/docs/home/supported-doc-versions.md | 2 +- content/ja/docs/reference/_index.md | 2 +- .../feature-gates/index.md | 52 ++++++++-------- content/ja/docs/reference/glossary/csi.md | 2 +- .../ja/docs/reference/kubectl/cheatsheet.md | 6 +- .../ja/docs/reference/kubectl/conventions.md | 2 +- .../ja/docs/reference/scheduling/config.md | 8 +-- content/ja/docs/reference/using-api/_index.md | 4 +- content/ja/docs/setup/_index.md | 6 +- .../docs/setup/best-practices/certificates.md | 6 +- .../setup/learning-environment/minikube.md | 4 +- .../container-runtimes.md | 2 +- .../production-environment/tools/kops.md | 4 +- .../tools/kubeadm/create-cluster-kubeadm.md | 8 +-- .../tools/kubeadm/self-hosting.md | 4 +- .../kubeadm/setup-ha-etcd-with-kubeadm.md | 2 +- .../tools/kubeadm/troubleshooting-kubeadm.md | 4 +- .../production-environment/tools/kubespray.md | 2 +- .../windows/intro-windows-in-kubernetes.md | 16 ++--- .../configure-access-multiple-clusters.md | 2 +- .../connecting-frontend-backend.md | 4 +- .../list-all-running-container-images.md | 4 +- .../web-ui-dashboard.md | 4 +- .../declare-network-policy.md | 2 +- .../extended-resource-node.md | 2 +- .../kubeadm/configure-cgroup-driver.md | 2 +- .../kubeadm/kubeadm-certs.md | 16 ++--- .../memory-constraint-namespace.md | 8 +-- .../migrating-from-dockershim/_index.md | 2 +- ...check-if-dockershim-removal-affects-you.md | 4 +- .../administer-cluster/securing-a-cluster.md | 8 +-- .../managing-secret-using-config-file.md | 2 +- .../managing-secret-using-kubectl.md | 2 +- .../assign-cpu-resource.md | 6 +- .../assign-memory-resource.md | 8 +-- .../configure-pod-configmap.md | 8 +-- .../configure-projected-volume-storage.md | 6 +- .../configure-volume-storage.md | 6 +- .../quality-service-pod.md | 6 +- .../security-context.md | 8 +-- .../configure-pod-container/static-pod.md | 4 +- content/ja/docs/tasks/debug/_index.md | 2 +- .../determine-reason-pod-failure.md | 2 +- .../docs/tasks/debug/debug-cluster/_index.md | 4 +- .../docs/tasks/debug/debug-cluster/audit.md | 2 +- .../resource-metrics-pipeline.md | 4 +- .../resource-usage-monitoring.md | 2 +- .../define-environment-variable-container.md | 2 +- .../distribute-credentials-secure.md | 4 +- .../job/automated-tasks-with-cron-jobs.md | 2 +- .../job/indexed-parallel-processing-static.md | 4 +- .../horizontal-pod-autoscale-walkthrough.md | 6 +- .../horizontal-pod-autoscale.md | 4 +- ...un-single-instance-stateful-application.md | 4 +- .../ja/docs/tasks/tls/certificate-rotation.md | 2 +- .../ja/docs/tasks/tools/install-kubectl.md | 2 +- content/ja/docs/tutorials/_index.md | 8 +-- .../configure-redis-using-configmap.md | 4 +- .../tutorials/security/cluster-level-pss.md | 4 +- .../docs/tutorials/security/ns-level-pss.md | 6 +- .../pods-and-endpoint-termination-flow.md | 4 +- .../mysql-wordpress-persistent-volume.md | 6 +- .../expose-external-ip-address.md | 2 +- .../guestbook-logs-metrics-with-elk.md | 4 +- 123 files changed, 339 insertions(+), 339 deletions(-) diff --git a/content/ja/docs/concepts/_index.md b/content/ja/docs/concepts/_index.md index 8075e3eb34e90..048a7184b50a5 100644 --- a/content/ja/docs/concepts/_index.md +++ b/content/ja/docs/concepts/_index.md @@ -21,7 +21,7 @@ Kubernetesを機能させるには、*Kubernetes API オブジェクト* を使 * **Kubernetes Master**: [kube-apiserver](/docs/admin/kube-apiserver/)、[kube-controller-manager](/docs/admin/kube-controller-manager/)、[kube-scheduler](/docs/admin/kube-scheduler/) の3プロセスの集合です。これらのプロセスはクラスター内の一つのノード上で実行されます。実行ノードはマスターノードとして指定します。 * クラスター内の個々の非マスターノードは、それぞれ2つのプロセスを実行します。 - * **[kubelet](/docs/admin/kubelet/)**: Kubernetes Masterと通信します。 + * **[kubelet](/ja/docs/admin/kubelet/)**: Kubernetes Masterと通信します。 * **[kube-proxy](/docs/admin/kube-proxy/)**: 各ノードのKubernetesネットワークサービスを反映するネットワークプロキシです。 ## Kubernetesオブジェクト {#kubernetes-objects} @@ -32,7 +32,7 @@ Kubernetesには、デプロイ済みのコンテナ化されたアプリケー * [Pod](/ja/docs/concepts/workloads/pods/pod-overview/) * [Service](/ja/docs/concepts/services-networking/service/) -* [Volume](/docs/concepts/storage/volumes/) +* [Volume](/ja/docs/concepts/storage/volumes/) * [Namespace](/ja/docs/concepts/overview/working-with-objects/namespaces/) Kubernetesには、[コントローラー](/ja/docs/concepts/architecture/controller/)に依存して基本オブジェクトを構築し、追加の機能と便利な機能を提供する高レベルの抽象化も含まれています。これらには以下のものを含みます: @@ -41,7 +41,7 @@ Kubernetesには、[コントローラー](/ja/docs/concepts/architecture/contro * [DaemonSet](/ja/docs/concepts/workloads/controllers/daemonset/) * [StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/) * [ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/) -* [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) +* [Job](/ja/docs/concepts/workloads/controllers/jobs-run-to-completion/) ## Kubernetesコントロールプレーン {#kubernetes-control-plane} @@ -65,7 +65,7 @@ Kubernetesのマスターは、クラスターの望ましい状態を維持す コンセプトページを追加したい場合は、 -[ページテンプレートの使用](/docs/home/contribute/page-templates/) +[ページテンプレートの使用](/ja/docs/home/contribute/page-templates/) のコンセプトページタイプとコンセプトテンプレートに関する情報を確認してください。 diff --git a/content/ja/docs/concepts/architecture/cgroups.md b/content/ja/docs/concepts/architecture/cgroups.md index 9ad161c183c27..52a659c741739 100644 --- a/content/ja/docs/concepts/architecture/cgroups.md +++ b/content/ja/docs/concepts/architecture/cgroups.md @@ -8,7 +8,7 @@ weight: 50 Linuxでは、{{< glossary_tooltip text="コントロールグループ" term_id="cgroup" >}}がプロセスに割り当てられるリソースを制限しています。 -コンテナ化されたワークロードの、CPU/メモリーの要求と制限を含む[Podとコンテナのリソース管理](/docs/concepts/configuration/manage-resources-containers/)を強制するために、 +コンテナ化されたワークロードの、CPU/メモリーの要求と制限を含む[Podとコンテナのリソース管理](/ja/docs/concepts/configuration/manage-resources-containers/)を強制するために、 {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}と基盤となるコンテナランタイムはcgroupをインターフェースとして接続する必要があります。 Linuxではcgroup v1とcgroup v2の2つのバージョンのcgroupがあります。 @@ -32,7 +32,7 @@ cgroup v2はリソース管理機能を強化した統合制御システムを - ページキャッシュの書き戻しといった、非即時のリソース変更 Kubernetesのいくつかの機能では、強化されたリソース管理と隔離のためにcgroup v2のみを使用しています。 -例えば、[MemoryQoS](/blog/2021/11/26/qos-memory-resources/)機能はメモリーQoSを改善し、cgroup v2の基本的な機能に依存しています。 +例えば、[MemoryQoS](/ja/blog/2021/11/26/qos-memory-resources/)機能はメモリーQoSを改善し、cgroup v2の基本的な機能に依存しています。 ## cgroup v2を使う {#using-cgroupv2} diff --git a/content/ja/docs/concepts/architecture/control-plane-node-communication.md b/content/ja/docs/concepts/architecture/control-plane-node-communication.md index 674dee02ed487..7c5121299dc92 100644 --- a/content/ja/docs/concepts/architecture/control-plane-node-communication.md +++ b/content/ja/docs/concepts/architecture/control-plane-node-communication.md @@ -18,7 +18,7 @@ aliases: Kubernetesには「ハブアンドスポーク」というAPIパターンがあります。ノード(またはノードが実行するPod)からのすべてのAPIの使用は、APIサーバーで終了します。他のコントロールプレーンコンポーネントは、どれもリモートサービスを公開するようには設計されていません。APIサーバーは、1つ以上の形式のクライアント[認証](/ja/docs/reference/access-authn-authz/authentication/)が有効になっている状態で、セキュアなHTTPSポート(通常は443)でリモート接続をリッスンするように設定されています。 特に[匿名リクエスト](/ja/docs/reference/access-authn-authz/authentication/#anonymous-requests)や[サービスアカウントトークン](/ja/docs/reference/access-authn-authz/authentication/#service-account-token)が許可されている場合は、1つ以上の[認可](/docs/reference/access-authn-authz/authorization/)形式を有効にする必要があります。 -ノードは、有効なクライアント認証情報とともに、APIサーバーに安全に接続できるように、クラスターのパブリックルート{{< glossary_tooltip text="証明書" term_id="certificate" >}}でプロビジョニングされる必要があります。適切なやり方は、kubeletに提供されるクライアント認証情報が、クライアント証明書の形式であることです。kubeletクライアント証明書の自動プロビジョニングについては、[kubelet TLSブートストラップ](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)を参照してください。 +ノードは、有効なクライアント認証情報とともに、APIサーバーに安全に接続できるように、クラスターのパブリックルート{{< glossary_tooltip text="証明書" term_id="certificate" >}}でプロビジョニングされる必要があります。適切なやり方は、kubeletに提供されるクライアント認証情報が、クライアント証明書の形式であることです。kubeletクライアント証明書の自動プロビジョニングについては、[kubelet TLSブートストラップ](/ja/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)を参照してください。 APIサーバーに接続したい{{< glossary_tooltip text="Pod" term_id="pod" >}}は、サービスアカウントを利用することで、安全に接続することができます。これにより、Podのインスタンス化時に、Kubernetesはパブリックルート証明書と有効なBearerトークンを自動的にPodに挿入します。 `kubernetes`サービス(`デフォルト`の名前空間)は、APIサーバー上のHTTPSエンドポイントに(`{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}`経由で)リダイレクトされる仮想IPアドレスで構成されます。 diff --git a/content/ja/docs/concepts/architecture/garbage-collection.md b/content/ja/docs/concepts/architecture/garbage-collection.md index 71515771d272b..b9e48a8575467 100644 --- a/content/ja/docs/concepts/architecture/garbage-collection.md +++ b/content/ja/docs/concepts/architecture/garbage-collection.md @@ -20,12 +20,12 @@ weight: 70 ## オーナーの依存関係 {#owners-dependents} -Kubernetesの多くのオブジェクトは、[*owner reference*](/docs/concepts/overview/working-with-objects/owners-dependents/)を介して相互にリンクしています。 +Kubernetesの多くのオブジェクトは、[*owner reference*](/ja/docs/concepts/overview/working-with-objects/owners-dependents/)を介して相互にリンクしています。 owner referenceは、どのオブジェクトが他のオブジェクトに依存しているかをコントロールプレーンに通知します。 Kubernetesは、owner referenceを使用して、コントロールプレーンやその他のAPIクライアントに、オブジェクトを削除する前に関連するリソースをクリーンアップする機会を提供します。 ほとんどの場合、Kubernetesはowner referenceを自動的に管理します。 -Ownershipは、一部のリソースでも使用される[ラベルおよびセレクター](/docs/concepts/overview/working-with-objects/labels/)メカニズムとは異なります。 +Ownershipは、一部のリソースでも使用される[ラベルおよびセレクター](/ja/docs/concepts/overview/working-with-objects/labels/)メカニズムとは異なります。 たとえば、`EndpointSlice`オブジェクトを作成する{{}}を考えます。 Serviceは*ラベル*を使用して、コントロールプレーンがServiceに使用されている`EndpointSlice`オブジェクトを判別できるようにします。 ラベルに加えて、Serviceに代わって管理される各`EndpointSlice`には、owner referenceがあります。 @@ -131,6 +131,6 @@ kubeletは、次の変数に基づいて未使用のコンテナをガベージ ## {{% heading "whatsnext" %}} -* [Kubernetes オブジェクトの所有権](/docs/concepts/overview/working-with-objects/owners-dependents/)を学びます。 -* Kubernetes [finalizer](/docs/concepts/overview/working-with-objects/finalizers/)を学びます。 +* [Kubernetes オブジェクトの所有権](/ja/docs/concepts/overview/working-with-objects/owners-dependents/)を学びます。 +* Kubernetes [finalizer](/ja/docs/concepts/overview/working-with-objects/finalizers/)を学びます。 * 完了したジョブをクリーンアップする[TTL controller](/ja/docs/concepts/workloads/controllers/ttlafterfinished/)(beta)について学びます。 diff --git a/content/ja/docs/concepts/architecture/nodes.md b/content/ja/docs/concepts/architecture/nodes.md index 1ae9f39a4ff16..5ff09e02f5161 100644 --- a/content/ja/docs/concepts/architecture/nodes.md +++ b/content/ja/docs/concepts/architecture/nodes.md @@ -249,7 +249,7 @@ kubeletはリソースの割当を決定する際にトポロジーのヒント kubeletは、ノードのシステムシャットダウンを検出すると、ノード上で動作しているPodを終了させます。 -Kubelet は、ノードのシャットダウン時に、ポッドが通常の[通常のポッド終了プロセス](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)に従うようにします。 +Kubelet は、ノードのシャットダウン時に、ポッドが通常の[通常のポッド終了プロセス](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)に従うようにします。 Graceful Node Shutdownはsystemdに依存しているため、[systemd inhibitor locks](https://www.freedesktop.org/wiki/Software/systemd/inhibit/)を 利用してノードのシャットダウンを一定時間遅らせることができます。 @@ -284,7 +284,7 @@ Reason: Shutdown Message: Node is shutting, evicting pods ``` -失敗したポッドオブジェクトは、明示的に削除されるか、[GCによってクリーンアップ](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)されるまで保存されます。 +失敗したポッドオブジェクトは、明示的に削除されるか、[GCによってクリーンアップ](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)されるまで保存されます。 これは、ノードが突然終了した場合とは異なった振る舞いです。 {{< /note >}} diff --git a/content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md index 11c7285609b80..cdded28f202b9 100644 --- a/content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md +++ b/content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md @@ -17,7 +17,7 @@ Kubernetesクラスターの計画、セットアップ、設定の例を知る ガイドを選択する前に、いくつかの考慮事項を挙げます。 - ユーザーのコンピューター上でKubernetesを試したいでしょうか、それとも高可用性のあるマルチノードクラスターを構築したいでしょうか？あなたのニーズにあったディストリビューションを選択してください。 - - **もしあなたが高可用性を求める場合**、 [複数ゾーンにまたがるクラスター](/docs/concepts/cluster-administration/federation/)の設定について学んでください。 + - **もしあなたが高可用性を求める場合**、 [複数ゾーンにまたがるクラスター](/ja/docs/concepts/cluster-administration/federation/)の設定について学んでください。 - [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/)のような**ホストされているKubernetesクラスター**を使用するのか、それとも**自分自身でクラスターをホストするのでしょうか**？ - 使用するクラスターは**オンプレミス**なのか、それとも**クラウド(IaaS)** でしょうか？Kubernetesはハイブリッドクラスターを直接サポートしていません。その代わりユーザーは複数のクラスターをセットアップできます。 - Kubernetesを **「ベアメタル」なハードウェア**上で稼働させますか？それとも**仮想マシン(VMs)** 上で稼働させますか？ @@ -39,25 +39,25 @@ Kubernetesクラスターの計画、セットアップ、設定の例を知る * [Kubernetes コンテナの環境](/ja/docs/concepts/containers/container-environment/)では、Kubernetesノード上でのKubeletが管理するコンテナの環境について説明します。 -* [Kubernetes APIへのアクセス制御](/docs/concepts/security/controlling-access)では、Kubernetesで自身のAPIに対するアクセスコントロールがどのように実装されているかを説明します。 +* [Kubernetes APIへのアクセス制御](/ja/docs/concepts/security/controlling-access)では、Kubernetesで自身のAPIに対するアクセスコントロールがどのように実装されているかを説明します。 -* [認証](/docs/reference/access-authn-authz/authentication/)では、様々な認証オプションを含むKubernetesでの認証について説明します。 +* [認証](/ja/docs/reference/access-authn-authz/authentication/)では、様々な認証オプションを含むKubernetesでの認証について説明します。 * [認可](/docs/reference/access-authn-authz/authorization/)では、認証とは別に、HTTPリクエストの処理方法を制御します。 * [アドミッションコントローラーの使用](/docs/reference/access-authn-authz/admission-controllers/)では、認証と認可の後にKubernetes APIに対するリクエストをインターセプトするプラグインについて説明します。 -* [Kubernetesクラスターでのsysctlの使用](/docs/concepts/cluster-administration/sysctl-cluster/)では、管理者向けにカーネルパラメーターを設定するため`sysctl`コマンドラインツールの使用方法について解説します。 +* [Kubernetesクラスターでのsysctlの使用](/ja/docs/concepts/cluster-administration/sysctl-cluster/)では、管理者向けにカーネルパラメーターを設定するため`sysctl`コマンドラインツールの使用方法について解説します。 * [クラスターの監査](/ja/docs/tasks/debug/debug-cluster/audit/)では、Kubernetesの監査ログの扱い方について解説します。 ### kubeletをセキュアにする * [マスターとノードのコミュニケーション](/ja/docs/concepts/architecture/master-node-communication/) - * [TLSのブートストラップ](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) - * [Kubeletの認証/認可](/docs/admin/kubelet-authentication-authorization/) + * [TLSのブートストラップ](/ja/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) + * [Kubeletの認証/認可](/ja/docs/admin/kubelet-authentication-authorization/) ## オプションのクラスターサービス * [DNSのインテグレーション](/ja/docs/concepts/services-networking/dns-pod-service/)では、DNS名をKubernetes Serviceに直接名前解決する方法を解説します。 -* [クラスターアクティビィのロギングと監視](/docs/concepts/cluster-administration/logging/)では、Kubernetesにおけるロギングがどのように行われ、どう実装されているかについて解説します。 +* [クラスターアクティビィのロギングと監視](/ja/docs/concepts/cluster-administration/logging/)では、Kubernetesにおけるロギングがどのように行われ、どう実装されているかについて解説します。 diff --git a/content/ja/docs/concepts/cluster-administration/manage-deployment.md b/content/ja/docs/concepts/cluster-administration/manage-deployment.md index 62d763be031de..3a85a77ff2da8 100644 --- a/content/ja/docs/concepts/cluster-administration/manage-deployment.md +++ b/content/ja/docs/concepts/cluster-administration/manage-deployment.md @@ -347,7 +347,7 @@ horizontalpodautoscaler.autoscaling/my-nginx autoscaled 実行すると、nginxのレプリカは必要に応じて自動でスケールアップ、スケールダウンします。 -さらなる情報は、[kubectl scale](/docs/reference/generated/kubectl/kubectl-commands/#scale)、[kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale) and [horizontal pod autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/)を参照してください。 +さらなる情報は、[kubectl scale](/docs/reference/generated/kubectl/kubectl-commands/#scale)、[kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale) and [horizontal pod autoscaler](/ja/docs/tasks/run-application/horizontal-pod-autoscale/)を参照してください。 ## リソースの直接的アップデート diff --git a/content/ja/docs/concepts/cluster-administration/system-logs.md b/content/ja/docs/concepts/cluster-administration/system-logs.md index a83c4c0c29604..099d4cde34b6e 100644 --- a/content/ja/docs/concepts/cluster-administration/system-logs.md +++ b/content/ja/docs/concepts/cluster-administration/system-logs.md @@ -14,7 +14,7 @@ weight: 80 klogは、Kubernetesのログライブラリです。[klog](https://github.com/kubernetes/klog)は、Kubernetesのシステムコンポーネント向けのログメッセージを生成します。 -klogの設定に関する詳しい情報については、[コマンドラインツールのリファレンス](/docs/reference/command-line-tools-reference/)を参照してください。 +klogの設定に関する詳しい情報については、[コマンドラインツールのリファレンス](/ja/docs/reference/command-line-tools-reference/)を参照してください。 klogネイティブ形式の例: @@ -52,7 +52,7 @@ I1025 00:15:15.525108 1 controller_utils.go:116] "Pod status updated" pod= {{< feature-state for_k8s_version="v1.19" state="alpha" >}} {{}} -JSONの出力は多数の標準のklogフラグをサポートしていません。非対応のklogフラグの一覧については、[コマンドラインツールリファレンス](/docs/reference/command-line-tools-reference/)を参照してください。 +JSONの出力は多数の標準のklogフラグをサポートしていません。非対応のklogフラグの一覧については、[コマンドラインツールリファレンス](/ja/docs/reference/command-line-tools-reference/)を参照してください。 すべてのログがJSON形式で書き込むことに対応しているわけではありません(たとえば、プロセスの開始時など)。ログのパースを行おうとしている場合、JSONではないログの行に対処できるようにしてください。 @@ -121,6 +121,6 @@ systemdを使用しているマシンでは、kubeletとコンテナランタイ ## {{% heading "whatsnext" %}} -* [Kubernetesのログのアーキテクチャ](/docs/concepts/cluster-administration/logging/)について読む。 +* [Kubernetesのログのアーキテクチャ](/ja/docs/concepts/cluster-administration/logging/)について読む。 * [構造化ログ](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1602-structured-logging)について読む。 * [ログの深刻度の慣習](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)について読む。 diff --git a/content/ja/docs/concepts/configuration/manage-resources-containers.md b/content/ja/docs/concepts/configuration/manage-resources-containers.md index 623b9e304186e..17098b8b43235 100644 --- a/content/ja/docs/concepts/configuration/manage-resources-containers.md +++ b/content/ja/docs/concepts/configuration/manage-resources-containers.md @@ -183,7 +183,7 @@ Nodeには、ローカルに接続された書き込み可能なデバイス、 Podは、スクラッチ領域、キャッシュ、ログ用にエフェメラルなローカルストレージを使用しています。 kubeletは、ローカルのエフェメラルストレージを使用して、Podにスクラッチ領域を提供し、[`emptyDir`](https://kubernetes.io/docs/concepts/storage/volumes/#emptydir) {{< glossary_tooltip term_id="volume" text="ボリューム" >}}をコンテナにマウントできます。 -また、kubeletはこの種類のストレージを使用して、[Nodeレベルのコンテナログ](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)、コンテナイメージ、実行中のコンテナの書き込み可能なレイヤーを保持します。 +また、kubeletはこの種類のストレージを使用して、[Nodeレベルのコンテナログ](/ja/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)、コンテナイメージ、実行中のコンテナの書き込み可能なレイヤーを保持します。 {{< caution >}} Nodeに障害が発生すると、そのエフェメラルストレージ内のデータが失われる可能性があります。 @@ -200,7 +200,7 @@ Kubernetesは、Node上のローカルエフェメラルストレージを構成 この構成では、さまざまな種類のローカルのエフェメラルデータ(`emptyDir`ボリュームや、書き込み可能なレイヤー、コンテナイメージ、ログなど)をすべて1つのファイルシステムに配置します。 kubeletを構成する最も効果的な方法は、このファイルシステムをKubernetes(kubelet)データ専用にすることです。 -kubeletは[Nodeレベルのコンテナログ](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)も書き込み、これらをエフェメラルなローカルストレージと同様に扱います。 +kubeletは[Nodeレベルのコンテナログ](/ja/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)も書き込み、これらをエフェメラルなローカルストレージと同様に扱います。 kubeletは、設定されたログディレクトリ(デフォルトでは`/var/log`)内のファイルにログを書き出し、ローカルに保存された他のデータのベースディレクトリ(デフォルトでは`/var/lib/kubelet`)を持ちます。 @@ -212,7 +212,7 @@ Nodeには、Kubernetesに使用されていない他のファイルシステム Node上にファイルシステムがありますが、このファイルシステムは、ログや`emptyDir`ボリュームなど、実行中のPodの一時的なデータに使用されます。 このファイルシステムは、例えばKubernetesに関連しないシステムログなどの他のデータに使用することができ、ルートファイルシステムとすることさえ可能です。 -また、kubeletは[ノードレベルのコンテナログ](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)を最初のファイルシステムに書き込み、これらをエフェメラルなローカルストレージと同様に扱います。 +また、kubeletは[ノードレベルのコンテナログ](/ja/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)を最初のファイルシステムに書き込み、これらをエフェメラルなローカルストレージと同様に扱います。 また、別の論理ストレージデバイスでバックアップされた別のファイルシステムを使用することもできます。 この設定では、コンテナイメージレイヤーと書き込み可能なレイヤーを配置するようにkubeletに指示するディレクトリは、この2番目のファイルシステム上にあります。 @@ -317,7 +317,7 @@ kubeletがローカルのエフェメラルストレージを測定していな ただし、書き込み可能なコンテナレイヤー、Nodeレベルのログ、または`emptyDir`ボリュームのファイルシステムスペースが少なくなると、Nodeはローカルストレージが不足していると汚染{{< glossary_tooltip text="taints" term_id="taint" >}}し、この汚染は、汚染を特に許容しないPodの排出をトリガーします。 -ローカルのエフェメラルストレージについては、サポートされている[設定](＃configurations-for-local-ephemeral-storage)をご覧ください。 +ローカルのエフェメラルストレージについては、サポートされている[設定](/ja＃configurations-for-local-ephemeral-storage)をご覧ください。 {{< /caution >}} kubeletはPodストレージの使用状況を測定するさまざまな方法をサポートしています @@ -559,7 +559,7 @@ Allocated resources: `allocatable`フィールド[NodeStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodestatus-v1-core)は、Podに利用可能なリソースの量を与えます。 詳細については、[ノード割り当て可能なリソース](https://git.k8s.io/design-proposals-archive/node/node-allocatable.md)を参照してください。 -[リソースクォータ](/docs/concepts/policy/resource-quotas/)機能は、消費できるリソースの総量を制限するように設定することができます。 +[リソースクォータ](/ja/docs/concepts/policy/resource-quotas/)機能は、消費できるリソースの総量を制限するように設定することができます。 名前空間と組み合わせて使用すると、1つのチームがすべてのリソースを占有するのを防ぐことができます。 ### コンテナが終了した {#my-container-is-terminated} diff --git a/content/ja/docs/concepts/configuration/overview.md b/content/ja/docs/concepts/configuration/overview.md index 678fdb0627fae..b86ade3fe8ca0 100644 --- a/content/ja/docs/concepts/configuration/overview.md +++ b/content/ja/docs/concepts/configuration/overview.md @@ -31,7 +31,7 @@ weight: 10 - 可能な限り、"真っ裸"のPod([ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)や[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)にバインドされていないPod)は使わないでください。Nodeに障害が発生した場合、これらのPodは再スケジュールされません。 - 明示的に[`restartPolicy: Never`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)を使いたいシーンを除いて、DeploymentはPodを直接作成するよりもほとんど常に望ましい方法です。Deploymentには、希望する数のPodが常に使用可能であることを確認するためにReplicaSetを作成したり、Podを置き換えるための戦略(RollingUpdateなど)を指定したりできます。[Job](/docs/concepts/workloads/controllers/job/)のほうが適切な場合もあるかもしれません。 + 明示的に[`restartPolicy: Never`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)を使いたいシーンを除いて、DeploymentはPodを直接作成するよりもほとんど常に望ましい方法です。Deploymentには、希望する数のPodが常に使用可能であることを確認するためにReplicaSetを作成したり、Podを置き換えるための戦略(RollingUpdateなど)を指定したりできます。[Job](/ja/docs/concepts/workloads/controllers/job/)のほうが適切な場合もあるかもしれません。 ## Service diff --git a/content/ja/docs/concepts/configuration/secret.md b/content/ja/docs/concepts/configuration/secret.md index 3a1c95afdb398..522dcbcac8729 100644 --- a/content/ja/docs/concepts/configuration/secret.md +++ b/content/ja/docs/concepts/configuration/secret.md @@ -588,7 +588,7 @@ Secretはwatch（デフォルト）、TTLベース、単に全てのリクエス キャッシュの遅延は、キャッシュの種別により、それぞれwatchの伝搬遅延、キャッシュのTTL、0になります。 {{< note >}} -Secretを[subPath](/docs/concepts/storage/volumes#using-subpath)を指定してボリュームにマウントしているコンテナには、Secretの更新が反映されません。 +Secretを[subPath](/ja/docs/concepts/storage/volumes#using-subpath)を指定してボリュームにマウントしているコンテナには、Secretの更新が反映されません。 {{< /note >}} ### Secretを環境変数として使用する {#using-secrets-as-environment-variables} @@ -696,7 +696,7 @@ kubeletはこの情報をPodのためにプライベートイメージをpullす ### 手動で作成されたSecretの自動的なマウント 手動で作成されたSecret（例えばGitHubアカウントへのアクセスに使うトークンを含む）はサービスアカウントを基に自動的にアタッチすることができます。 -詳細な説明は[PodPresetを使ったPodへの情報の注入](/docs/tasks/inject-data-application/podpreset/)を参照してください。 +詳細な説明は[PodPresetを使ったPodへの情報の注入](/ja/docs/tasks/inject-data-application/podpreset/)を参照してください。 ## 詳細 @@ -1035,7 +1035,7 @@ Secretは様々な種類の重要な値を保持することが多く、サー これらの理由により、ネームスペース内のSecretに対する`watch`や`list`リクエストはかなり強力な能力であり、避けるべきです。Secretのリストを取得することはクライアントにネームスペース内の全てのSecretの値を調べさせることを認めるからです。クラスター内の全てのSecretに対する`watch`、`list`権限は最も特権的な、システムレベルのコンポーネントに限って認めるべきです。 -Secret APIへのアクセスが必要なアプリケーションは、必要なSecretに対する`get`リクエストを発行すべきです。管理者は全てのSecretに対するアクセスは制限しつつ、アプリケーションが必要とする[個々のインスタンスに対するアクセス許可](/docs/reference/access-authn-authz/rbac/#referring-to-resources)を与えることができます。 +Secret APIへのアクセスが必要なアプリケーションは、必要なSecretに対する`get`リクエストを発行すべきです。管理者は全てのSecretに対するアクセスは制限しつつ、アプリケーションが必要とする[個々のインスタンスに対するアクセス許可](/ja/docs/reference/access-authn-authz/rbac/#referring-to-resources)を与えることができます。 `get`リクエストの繰り返しに対するパフォーマンスを向上するために、クライアントはSecretを参照するリソースを設計し、それを`watch`して、参照が変更されたときにSecretを再度リクエストすることができます。加えて、個々のリソースを`watch`することのできる["bulk watch" API](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/bulk_watch.md)が提案されており、将来のKubernetesリリースにて利用可能になる可能性があります。 @@ -1082,7 +1082,7 @@ Podに複数のコンテナが含まれることもあります。しかし、Po ## {{% heading "whatsnext" %}} -- [`kubectl`を使用してSecretを管理する](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)方法を学ぶ -- [config fileを使用してSecretを管理する](/docs/tasks/configmap-secret/managing-secret-using-config-file/)方法を学ぶ -- [kustomizeを使用してSecretを管理する](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)方法を学ぶ +- [`kubectl`を使用してSecretを管理する](/ja/docs/tasks/configmap-secret/managing-secret-using-kubectl/)方法を学ぶ +- [config fileを使用してSecretを管理する](/ja/docs/tasks/configmap-secret/managing-secret-using-config-file/)方法を学ぶ +- [kustomizeを使用してSecretを管理する](/ja/docs/tasks/configmap-secret/managing-secret-using-kustomize/)方法を学ぶ - [SecretのAPIリファレンス](/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/)を読む diff --git a/content/ja/docs/concepts/containers/_index.md b/content/ja/docs/concepts/containers/_index.md index 39944f6c30044..f11952d489cfb 100644 --- a/content/ja/docs/concepts/containers/_index.md +++ b/content/ja/docs/concepts/containers/_index.md @@ -29,5 +29,5 @@ no_list: true ## {{% heading "whatsnext" %}} -* [コンテナイメージ](/docs/concepts/containers/images/)についてお読みください。 +* [コンテナイメージ](/ja/docs/concepts/containers/images/)についてお読みください。 * [Pod](/ja/docs/concepts/workloads/pods/)についてお読みください。 diff --git a/content/ja/docs/concepts/containers/runtime-class.md b/content/ja/docs/concepts/containers/runtime-class.md index 87110cf13f3ca..67f5f4b474297 100644 --- a/content/ja/docs/concepts/containers/runtime-class.md +++ b/content/ja/docs/concepts/containers/runtime-class.md @@ -144,5 +144,5 @@ PodのオーバーヘッドはRuntimeClass内の`overhead`フィールドによ - [RuntimeClassデザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md) - [RuntimeClassスケジューリングデザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling) -- [Podオーバーヘッド](/docs/concepts/scheduling-eviction/pod-overhead/)のコンセプトを読む +- [Podオーバーヘッド](/ja/docs/concepts/scheduling-eviction/pod-overhead/)のコンセプトを読む - [PodOverhead機能デザイン](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead) diff --git a/content/ja/docs/concepts/extend-kubernetes/_index.md b/content/ja/docs/concepts/extend-kubernetes/_index.md index 67ccb50adf9a7..58bbe5a7a2f72 100644 --- a/content/ja/docs/concepts/extend-kubernetes/_index.md +++ b/content/ja/docs/concepts/extend-kubernetes/_index.md @@ -27,7 +27,7 @@ Kubernetesは柔軟な設定が可能で、高い拡張性を持っています ホスティングされたKubernetesサービスやマネージドなKubernetesでは、フラグと設定ファイルが常に変更できるとは限りません。変更可能な場合でも、通常はクラスターの管理者のみが変更できます。また、それらは将来のKubernetesバージョンで変更される可能性があり、設定変更にはプロセスの再起動が必要になるかもしれません。これらの理由により、この方法は他の選択肢が無いときにのみ利用するべきです。 -[ResourceQuota](/ja/docs/concepts/policy/resource-quotas/)、[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)、[NetworkPolicy](/ja/docs/concepts/services-networking/network-policies/)、そしてロールベースアクセス制御([RBAC](/ja/docs/reference/access-authn-authz/rbac/))といった *ビルトインポリシーAPI* は、ビルトインのKubernetes APIです。APIは通常、ホスティングされたKubernetesサービスやマネージドなKubernetesで利用されます。これらは宣言的で、Podのような他のKubernetesリソースと同じ慣例に従っています。そのため、新しいクラスターの設定は繰り返し再利用することができ、アプリケーションと同じように管理することが可能です。さらに、安定版(stable)を利用している場合、他のKubernetes APIのような[定義済みのサポートポリシー](/docs/reference/deprecation-policy/)を利用することができます。これらの理由により、この方法は、適切な用途の場合、 *設定ファイル* や *フラグ* よりも好まれます。 +[ResourceQuota](/ja/docs/concepts/policy/resource-quotas/)、[PodSecurityPolicy](/ja/docs/concepts/policy/pod-security-policy/)、[NetworkPolicy](/ja/docs/concepts/services-networking/network-policies/)、そしてロールベースアクセス制御([RBAC](/ja/docs/reference/access-authn-authz/rbac/))といった *ビルトインポリシーAPI* は、ビルトインのKubernetes APIです。APIは通常、ホスティングされたKubernetesサービスやマネージドなKubernetesで利用されます。これらは宣言的で、Podのような他のKubernetesリソースと同じ慣例に従っています。そのため、新しいクラスターの設定は繰り返し再利用することができ、アプリケーションと同じように管理することが可能です。さらに、安定版(stable)を利用している場合、他のKubernetes APIのような[定義済みのサポートポリシー](/ja/docs/reference/deprecation-policy/)を利用することができます。これらの理由により、この方法は、適切な用途の場合、 *設定ファイル* や *フラグ* よりも好まれます。 ## 拡張 @@ -53,7 +53,7 @@ Kubernetes上でうまく動くクライアントプログラムを書くため Webhookのモデルでは、Kubernetesは外部のサービスを呼び出します。 *バイナリプラグイン* モデルでは、Kubernetesはバイナリ(プログラム)を実行します。 -バイナリプラグインはkubelet(例、[FlexVolumeプラグイン](/docs/concepts/storage/volumes/#flexVolume)、[ネットワークプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))、またkubectlで利用されています。 +バイナリプラグインはkubelet(例、[FlexVolumeプラグイン](/ja/docs/concepts/storage/volumes/#flexVolume)、[ネットワークプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))、またkubectlで利用されています。 下図は、それぞれの拡張ポイントが、Kubernetesのコントロールプレーンとどのように関わっているかを示しています。 @@ -70,12 +70,12 @@ Webhookのモデルでは、Kubernetesは外部のサービスを呼び出しま 1. ユーザーは頻繁に`kubectl`を使って、Kubernetes APIとやり取りをします。[Kubectlプラグイン](/docs/tasks/extend-kubectl/kubectl-plugins/)は、kubectlのバイナリを拡張します。これは個別ユーザーのローカル環境のみに影響を及ぼすため、サイト全体にポリシーを強制することはできません。 -2. APIサーバーは全てのリクエストを処理します。APIサーバーのいくつかの拡張ポイントは、リクエストを認可する、コンテキストに基づいてブロックする、リクエストを編集する、そして削除を処理することを可能にします。これらは[APIアクセス拡張](/docs/concepts/extend-kubernetes/#api-access-extensions)セクションに記載されています。 -3. APIサーバーは様々な種類の *リソース* を扱います。`Pod`のような *ビルトインリソース* はKubernetesプロジェクトにより定義され、変更できません。ユーザーも、自身もしくは、他のプロジェクトで定義されたリソースを追加することができます。それは *カスタムリソース* と呼ばれ、[カスタムリソース](/docs/concepts/extend-kubernetes/#user-defined-types)セクションに記載されています。カスタムリソースは度々、APIアクセス拡張と一緒に使われます。 +2. APIサーバーは全てのリクエストを処理します。APIサーバーのいくつかの拡張ポイントは、リクエストを認可する、コンテキストに基づいてブロックする、リクエストを編集する、そして削除を処理することを可能にします。これらは[APIアクセス拡張](/ja/docs/concepts/extend-kubernetes/#api-access-extensions)セクションに記載されています。 +3. APIサーバーは様々な種類の *リソース* を扱います。`Pod`のような *ビルトインリソース* はKubernetesプロジェクトにより定義され、変更できません。ユーザーも、自身もしくは、他のプロジェクトで定義されたリソースを追加することができます。それは *カスタムリソース* と呼ばれ、[カスタムリソース](/ja/docs/concepts/extend-kubernetes/#user-defined-types)セクションに記載されています。カスタムリソースは度々、APIアクセス拡張と一緒に使われます。 4. KubernetesのスケジューラーはPodをどのノードに配置するかを決定します。スケジューリングを拡張するには、いくつかの方法があります。それらは[スケジューラー拡張](#scheduling-extensions)セクションに記載されています。 5. Kubernetesにおける多くの振る舞いは、APIサーバーのクライアントであるコントローラーと呼ばれるプログラムに実装されています。コントローラーは度々、カスタムリソースと共に使われます。 -6. kubeletはサーバー上で実行され、Podが仮想サーバーのようにクラスターネットワーク上にIPを持った状態で起動することをサポートします。[ネットワークプラグイン](/docs/concepts/extend-kubernetes/#network-plugins)がPodのネットワーキングにおける異なる実装を適用することを可能にします。 -7. kubeletはまた、コンテナのためにボリュームをマウント、アンマウントします。新しい種類のストレージは[ストレージプラグイン](/docs/concepts/extend-kubernetes/#storage-plugins)を通じてサポートされます。 +6. kubeletはサーバー上で実行され、Podが仮想サーバーのようにクラスターネットワーク上にIPを持った状態で起動することをサポートします。[ネットワークプラグイン](/ja/docs/concepts/extend-kubernetes/#network-plugins)がPodのネットワーキングにおける異なる実装を適用することを可能にします。 +7. kubeletはまた、コンテナのためにボリュームをマウント、アンマウントします。新しい種類のストレージは[ストレージプラグイン](/ja/docs/concepts/extend-kubernetes/#storage-plugins)を通じてサポートされます。 もしあなたがどこから始めるべきかわからない場合、このフローチャートが役立つでしょう。一部のソリューションは、いくつかの種類の拡張を含んでいることを留意してください。 @@ -102,7 +102,7 @@ Webhookのモデルでは、Kubernetesは外部のサービスを呼び出しま ### APIアクセス拡張 {#api-access-extensions} -リクエストがKubernetes APIサーバーに到達すると、まず最初に認証が行われ、次に認可、その後、様々なAdmission Controlの対象になります。このフローの詳細は[Kubernetes APIへのアクセスをコントロールする](/docs/concepts/security/controlling-access/)を参照して下さい。 +リクエストがKubernetes APIサーバーに到達すると、まず最初に認証が行われ、次に認可、その後、様々なAdmission Controlの対象になります。このフローの詳細は[Kubernetes APIへのアクセスをコントロールする](/ja/docs/concepts/security/controlling-access/)を参照して下さい。 これらの各ステップごとに拡張ポイントが用意されています。 @@ -129,7 +129,7 @@ Kubernetesはいくつかのビルトイン認証方式と、それらが要件 ### ストレージプラグイン -[Flex Volumes](/docs/concepts/storage/volumes/#flexVolume)は、Kubeletがバイナリプラグインを呼び出してボリュームをマウントすることにより、ユーザーはビルトインのサポートなしでボリュームタイプをマウントすることを可能にします。 +[Flex Volumes](/ja/docs/concepts/storage/volumes/#flexVolume)は、Kubeletがバイナリプラグインを呼び出してボリュームをマウントすることにより、ユーザーはビルトインのサポートなしでボリュームタイプをマウントすることを可能にします。 ### デバイスプラグイン diff --git a/content/ja/docs/concepts/extend-kubernetes/extend-cluster.md b/content/ja/docs/concepts/extend-kubernetes/extend-cluster.md index fd889ecfa216b..dc6dd80cb6f35 100644 --- a/content/ja/docs/concepts/extend-kubernetes/extend-cluster.md +++ b/content/ja/docs/concepts/extend-kubernetes/extend-cluster.md @@ -32,7 +32,7 @@ Kubernetesは柔軟な設定が可能で、高い拡張性を持っています ホスティングされたKubernetesサービスやマネージドなKubernetesでは、フラグと設定ファイルが常に変更できるとは限りません。変更可能な場合でも、通常はクラスターの管理者のみが変更できます。また、それらは将来のKubernetesバージョンで変更される可能性があり、設定変更にはプロセスの再起動が必要になるかもしれません。これらの理由により、この方法は他の選択肢が無いときにのみ利用するべきです。 -[ResourceQuota](/ja/docs/concepts/policy/resource-quotas/)、[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)、[NetworkPolicy](/docs/concepts/services-networking/network-policies/)、そしてロールベースアクセス制御([RBAC](/docs/reference/access-authn-authz/rbac/))といった *ビルトインポリシーAPI* は、ビルトインのKubernetes APIです。APIは通常、ホスティングされたKubernetesサービスやマネージドなKubernetesで利用されます。これらは宣言的で、Podのような他のKubernetesリソースと同じ慣例に従っています。そのため、新しいクラスターの設定は繰り返し再利用することができ、アプリケーションと同じように管理することが可能です。さらに、安定版(stable)を利用している場合、他のKubernetes APIのような[定義済みのサポートポリシー](/docs/reference/using-api/deprecation-policy/)を利用することができます。これらの理由により、この方法は、適切な用途の場合、 *設定ファイル* や *フラグ* よりも好まれます。 +[ResourceQuota](/ja/docs/concepts/policy/resource-quotas/)、[PodSecurityPolicy](/ja/docs/concepts/policy/pod-security-policy/)、[NetworkPolicy](/ja/docs/concepts/services-networking/network-policies/)、そしてロールベースアクセス制御([RBAC](/ja/docs/reference/access-authn-authz/rbac/))といった *ビルトインポリシーAPI* は、ビルトインのKubernetes APIです。APIは通常、ホスティングされたKubernetesサービスやマネージドなKubernetesで利用されます。これらは宣言的で、Podのような他のKubernetesリソースと同じ慣例に従っています。そのため、新しいクラスターの設定は繰り返し再利用することができ、アプリケーションと同じように管理することが可能です。さらに、安定版(stable)を利用している場合、他のKubernetes APIのような[定義済みのサポートポリシー](/docs/reference/using-api/deprecation-policy/)を利用することができます。これらの理由により、この方法は、適切な用途の場合、 *設定ファイル* や *フラグ* よりも好まれます。 ## エクステンション @@ -58,7 +58,7 @@ Kubernetes上でうまく動くクライアントプログラムを書くため Webhookのモデルでは、Kubernetesは外部のサービスを呼び出します。 *バイナリプラグイン* モデルでは、Kubernetesはバイナリ(プログラム)を実行します。 -バイナリプラグインはkubelet(例、[FlexVolumeプラグイン](/docs/concepts/storage/volumes/#flexvolume)、[ネットワークプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))、またkubectlで利用されています。 +バイナリプラグインはkubelet(例、[FlexVolumeプラグイン](/ja/docs/concepts/storage/volumes/#flexvolume)、[ネットワークプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))、またkubectlで利用されています。 下図は、それぞれの拡張ポイントが、Kubernetesのコントロールプレーンとどのように関わっているかを示しています。 @@ -107,7 +107,7 @@ Webhookのモデルでは、Kubernetesは外部のサービスを呼び出しま ### APIアクセスエクステンション -リクエストがKubernetes APIサーバーに到達すると、まず最初に認証が行われ、次に認可、その後、様々なAdmission Controlの対象になります。このフローの詳細は[Kubernetes APIへのアクセスをコントロールする](/docs/concepts/security/controlling-access/)を参照して下さい。 +リクエストがKubernetes APIサーバーに到達すると、まず最初に認証が行われ、次に認可、その後、様々なAdmission Controlの対象になります。このフローの詳細は[Kubernetes APIへのアクセスをコントロールする](/ja/docs/concepts/security/controlling-access/)を参照して下さい。 これらの各ステップごとに拡張ポイントが用意されています。 @@ -117,7 +117,7 @@ Kubdernetesはいくつかのビルトイン認証方式をサポートしてい [認証](/ja/docs/reference/access-authn-authz/authentication/)は、全てのリクエストのヘッダーまたは証明書情報を、リクエストを投げたクライアントのユーザー名にマッピングします。 -Kubernetesはいくつかのビルトイン認証方式と、それらが要件に合わない場合、[認証Webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)を提供します。 +Kubernetesはいくつかのビルトイン認証方式と、それらが要件に合わない場合、[認証Webhook](/ja/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)を提供します。 ### 認可 @@ -134,7 +134,7 @@ Kubernetesはいくつかのビルトイン認証方式と、それらが要件 ### ストレージプラグイン -[Flex Volumes](/docs/concepts/storage/volumes/#flexvolume)は、Kubeletがバイナリプラグインを呼び出してボリュームをマウントすることにより、ユーザーはビルトインのサポートなしでボリュームタイプをマウントすることを可能にします。 +[Flex Volumes](/ja/docs/concepts/storage/volumes/#flexvolume)は、Kubeletがバイナリプラグインを呼び出してボリュームをマウントすることにより、ユーザーはビルトインのサポートなしでボリュームタイプをマウントすることを可能にします。 ### デバイスプラグイン @@ -163,4 +163,4 @@ Kubernetesはいくつかのビルトイン認証方式と、それらが要件 * [ネットワークプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) * [デバイスプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) * [kubectlプラグイン](/docs/tasks/extend-kubectl/kubectl-plugins/)について学ぶ -* [オペレーターパターン](/docs/concepts/extend-kubernetes/operator/)について学ぶ +* [オペレーターパターン](/ja/docs/concepts/extend-kubernetes/operator/)について学ぶ diff --git a/content/ja/docs/concepts/overview/_index.md b/content/ja/docs/concepts/overview/_index.md index d4f4a91e4735b..e3bc9552173f1 100644 --- a/content/ja/docs/concepts/overview/_index.md +++ b/content/ja/docs/concepts/overview/_index.md @@ -20,7 +20,7 @@ Kubernetesは、宣言的な構成管理と自動化を促進し、コンテナ Kubernetesの名称は、ギリシャ語に由来し、操舵手やパイロットを意味しています。 "K"と"s"の間にある8つの文字を数えることから、K8sが略語として使われています。 Googleは2014年にKubernetesプロジェクトをオープンソース化しました。 -Kubernetesは、本番環境で大規模なワークロードを稼働させた[Googleの15年以上の経験](/blog/2015/04/borg-predecessor-to-kubernetes/)と、コミュニティからの最高のアイディアや実践を組み合わせています。 +Kubernetesは、本番環境で大規模なワークロードを稼働させた[Googleの15年以上の経験](/ja/blog/2015/04/borg-predecessor-to-kubernetes/)と、コミュニティからの最高のアイディアや実践を組み合わせています。 ## 過去を振り返ってみると diff --git a/content/ja/docs/concepts/overview/kubernetes-api.md b/content/ja/docs/concepts/overview/kubernetes-api.md index e662648ec46b9..b9a2da8198191 100644 --- a/content/ja/docs/concepts/overview/kubernetes-api.md +++ b/content/ja/docs/concepts/overview/kubernetes-api.md @@ -18,7 +18,7 @@ APIサーバーは、エンドユーザー、クラスターのさまざまな Kubernetes APIを使用すると、Kubernetes API内のオブジェクトの状態をクエリで操作できます（例：Pod、Namespace、ConfigMap、Events）。 -ほとんどの操作は、APIを使用している[kubectl](/ja/docs/reference/kubectl/)コマンドラインインターフェースもしくは[kubeadm](/docs/reference/setup-tools/kubeadm/)のような別のコマンドラインツールを通して実行できます。 +ほとんどの操作は、APIを使用している[kubectl](/ja/docs/reference/kubectl/)コマンドラインインターフェースもしくは[kubeadm](/ja/docs/reference/setup-tools/kubeadm/)のような別のコマンドラインツールを通して実行できます。 RESTコールを利用して直接APIにアクセスすることも可能です。 Kubernetes APIを利用してアプリケーションを書いているのであれば、[client libraries](/docs/reference/using-api/client-libraries/)の利用を考えてみてください。 @@ -73,7 +73,7 @@ Kubernetesは、他の手段として主にクラスター間の連携用途向 {{< feature-state state="beta" for_k8s_version="v1.24" >}} -Kubernetes {{< param "version" >}}では、OpenAPI v3によるAPI仕様をベータサポートとして提供しています。これは、デフォルトで有効化されているベータ機能です。kube-apiserverの`OpenAPIV3`という[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)を切ることにより、このベータ機能を無効化することができます。 +Kubernetes {{< param "version" >}}では、OpenAPI v3によるAPI仕様をベータサポートとして提供しています。これは、デフォルトで有効化されているベータ機能です。kube-apiserverの`OpenAPIV3`という[feature gate](/ja/docs/reference/command-line-tools-reference/feature-gates/)を切ることにより、このベータ機能を無効化することができます。 `/openapi/v3`が、全ての利用可能なグループやバージョンの一覧を閲覧するためのディスカバリーエンドポイントとして提供されています。このエンドポイントは、JSONのみを返却します。利用可能なグループやバージョンは、次のような形式で提供されます。 @@ -141,7 +141,7 @@ KubernetesはAPIリソースの観点からシリアル化された状態を{{< APIが、システムリソースと動作について明確かつ一貫したビューを提供し、サポート終了、実験的なAPIへのアクセス制御を有効にするために、リソースまたはフィールドレベルではなく、APIレベルでバージョンが行われます。 -APIの発展や拡張を簡易に行えるようにするため、Kubernetesは[有効もしくは無効](/docs/reference/using-api/#enabling-or-disabling)を行える[APIグループ](/docs/reference/using-api/#api-groups)を実装しました。 +APIの発展や拡張を簡易に行えるようにするため、Kubernetesは[有効もしくは無効](/ja/docs/reference/using-api/#enabling-or-disabling)を行える[APIグループ](/ja/docs/reference/using-api/#api-groups)を実装しました。 APIリソースは、APIグループ、リソースタイプ、ネームスペース（namespacedリソースのための）、名前によって区別されます。APIサーバーは、APIバージョン間の変換を透過的に処理します。すべてのバージョンの違いは、実際のところ同じ永続データとして表現されます。APIサーバーは、同じ基本的なデータを複数のAPIバージョンで提供することができます。 @@ -172,7 +172,7 @@ alpha APIバージョンを使っている場合、クラスターをアップ APIが互換性のない方法で変更された場合は、アップグレードをする前に既存のalphaオブジェクトをすべて削除する必要があります。 {{< /note >}} -APIバージョンレベルの定義に関する詳細は[APIバージョンのリファレンス](/docs/reference/using-api/#api-versioning)を参照してください。 +APIバージョンレベルの定義に関する詳細は[APIバージョンのリファレンス](/ja/docs/reference/using-api/#api-versioning)を参照してください。 ## APIの拡張 @@ -185,6 +185,6 @@ Kubernetes APIは2つの方法で拡張できます。 ## {{% heading "whatsnext" %}} - 自分自身で[カスタムリソース定義](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)を追加してKubernetes APIを拡張する方法について学んでください。 -- [Kubernetes APIのアクセス制御](/docs/concepts/security/controlling-access/)では、クラスターがAPIアクセスの認証と承認を管理する方法を説明しています。 +- [Kubernetes APIのアクセス制御](/ja/docs/concepts/security/controlling-access/)では、クラスターがAPIアクセスの認証と承認を管理する方法を説明しています。 - [APIリファレンス](/ja/docs/reference/kubernetes-api/)を読んで、APIエンドポイント、リソースタイプやサンプルについて学んでください。 - [APIの変更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)から、互換性のある変更とは何か, どのようにAPIを変更するかについて学んでください。 diff --git a/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md b/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md index b3f87105d9680..9ba0c3ae7a251 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md +++ b/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md @@ -43,7 +43,7 @@ kubectl get services --all-namespaces --field-selector metadata.namespace!=defa ``` ## 連結されたセレクター -[ラベル](/docs/concepts/overview/working-with-objects/labels)や他のセレクターと同様に、フィールドセレクターはコンマ区切りのリストとして連結することができます。 +[ラベル](/ja/docs/concepts/overview/working-with-objects/labels)や他のセレクターと同様に、フィールドセレクターはコンマ区切りのリストとして連結することができます。 下記の`kubectl`コマンドは、`status.phase`が`Runnning`でなく、かつ`spec.restartPolicy`フィールドが`Always`に等しいような全てのPodを選択します。 ```shell diff --git a/content/ja/docs/concepts/overview/working-with-objects/finalizers.md b/content/ja/docs/concepts/overview/working-with-objects/finalizers.md index 11338cfd819d2..869f369cd96ee 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/finalizers.md +++ b/content/ja/docs/concepts/overview/working-with-objects/finalizers.md @@ -36,7 +36,7 @@ Podが`PersistentVolume`の利用を停止するとKubernetesは`pv-protection` ## オーナーリファレンス、ラベル、ファイナライザー {#owners-labels-finalizers} {{}}のように、 -[オーナーリファレンス](/docs/concepts/overview/working-with-objects/owners-dependents/)はKubernetesのオブジェクト間の関係性を説明しますが、利用される目的が異なります。 +[オーナーリファレンス](/ja/docs/concepts/overview/working-with-objects/owners-dependents/)はKubernetesのオブジェクト間の関係性を説明しますが、利用される目的が異なります。 {{}} がPodのようなオブジェクトを管理するとき、関連するオブジェクトのグループの変更を追跡するためにラベルを利用します。 例えば、{{}}がいくつかのPodを作成するとき、JobコントローラーはそれらのPodにラベルを付け、クラスター内の同じラベルを持つPodの変更を追跡します。 @@ -56,4 +56,4 @@ Podが実行されているときにJobを削除すると、Kubernetesはオー ## {{% heading "whatsnext" %}} -* Kubernetesブログの[ファイナライザーを利用した削除の制御](/blog/2021/05/14/using-finalizers-to-control-deletion/)をお読みください。 +* Kubernetesブログの[ファイナライザーを利用した削除の制御](/ja/blog/2021/05/14/using-finalizers-to-control-deletion/)をお読みください。 diff --git a/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md index b33285d3691f3..0b4b53e490128 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -74,5 +74,5 @@ Kubernetesオブジェクトを`.yaml`ファイルに記載して作成する場 * 最も重要、かつ基本的なKubernetesオブジェクト群を学びましょう、例えば、[Pod](/ja/docs/concepts/workloads/pods/)です。 * Kubernetesの[コントローラー](/ja/docs/concepts/architecture/controller/)を学びましょう。 -* [Using the Kubernetes API](/docs/reference/using-api/)はこのページでは取り上げていない他のAPIについて説明します。 +* [Using the Kubernetes API](/ja/docs/reference/using-api/)はこのページでは取り上げていない他のAPIについて説明します。 diff --git a/content/ja/docs/concepts/overview/working-with-objects/labels.md b/content/ja/docs/concepts/overview/working-with-objects/labels.md index 0af7384a6add7..5961bad273f36 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/labels.md +++ b/content/ja/docs/concepts/overview/working-with-objects/labels.md @@ -223,7 +223,7 @@ selector: #### *集合ベース* の要件指定をサポートするリソース -[`Job`](/docs/concepts/workloads/controllers/job/)や[`Deployment`](/ja/docs/concepts/workloads/controllers/deployment/)、[`ReplicaSet`](/ja/docs/concepts/workloads/controllers/replicaset/)や[`DaemonSet`](/ja/docs/concepts/workloads/controllers/daemonset/)などの比較的新しいリソースは、*集合ベース* での要件指定もサポートしています。 +[`Job`](/ja/docs/concepts/workloads/controllers/job/)や[`Deployment`](/ja/docs/concepts/workloads/controllers/deployment/)、[`ReplicaSet`](/ja/docs/concepts/workloads/controllers/replicaset/)や[`DaemonSet`](/ja/docs/concepts/workloads/controllers/daemonset/)などの比較的新しいリソースは、*集合ベース* での要件指定もサポートしています。 ```yaml selector: matchLabels: diff --git a/content/ja/docs/concepts/overview/working-with-objects/namespaces.md b/content/ja/docs/concepts/overview/working-with-objects/namespaces.md index 3e063d03c7fdd..998f38dda1b40 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/ja/docs/concepts/overview/working-with-objects/namespaces.md @@ -22,7 +22,7 @@ Kubernetesが提供するNamespaceの機能が必要となった時に、Namespa Namespaceは名前空間のスコープを提供します。リソース名は単一のNamespace内ではユニークである必要がありますが、Namespace全体ではその必要はありません。Namespaceは相互にネストすることはできず、各Kubernetesリソースは1つのNamespaceにのみ存在できます。 -Namespaceは、複数のユーザーの間でクラスターリソースを分割する方法です。(これは[リソースクォータ](/docs/concepts/policy/resource-quotas/)を介して分割します。) +Namespaceは、複数のユーザーの間でクラスターリソースを分割する方法です。(これは[リソースクォータ](/ja/docs/concepts/policy/resource-quotas/)を介して分割します。) 同じアプリケーションの異なるバージョンなど、少し違うリソースをただ分割するだけに、複数のNamespaceを使う必要はありません。 同一のNamespace内でリソースを区別するためには[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を使用してください。 diff --git a/content/ja/docs/concepts/policy/limit-range.md b/content/ja/docs/concepts/policy/limit-range.md index 11a83f6e2ac91..974e00f8768f2 100644 --- a/content/ja/docs/concepts/policy/limit-range.md +++ b/content/ja/docs/concepts/policy/limit-range.md @@ -52,6 +52,6 @@ LimitRangeに対する競合や変更は、すでに作成済みのリソース - [名前空間ごとにCPUの最小値と最大値の制約を設定する方法](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)。 - [名前空間ごとにメモリーの最小値と最大値の制約を設定する方法](/ja/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)。 - [名前空間ごとにCPUのRequestとLimitのデフォルト値を設定する方法](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)。 -- [名前空間ごとにメモリーのRequestとLimitのデフォルト値を設定する方法](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)。 +- [名前空間ごとにメモリーのRequestとLimitのデフォルト値を設定する方法](/ja/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)。 - [名前空間ごとにストレージ消費量の最小値と最大値を設定する方法](/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage)。 - [名前空間ごとのクォータを設定する詳細な例](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)。 diff --git a/content/ja/docs/concepts/policy/resource-quotas.md b/content/ja/docs/concepts/policy/resource-quotas.md index 89e8b3f7b884b..9984898954912 100644 --- a/content/ja/docs/concepts/policy/resource-quotas.md +++ b/content/ja/docs/concepts/policy/resource-quotas.md @@ -66,7 +66,7 @@ ResourceQuotaのオブジェクト名は、有効な[DNSサブドメイン名](/ ### 拡張リソースのためのリソースクォータ -上記で取り上げたリソースに加えて、Kubernetes v1.10において、[拡張リソース](/docs/concepts/configuration/manage-resources-containers/#extended-resources)のためのリソースクォータのサポートが追加されました。 +上記で取り上げたリソースに加えて、Kubernetes v1.10において、[拡張リソース](/ja/docs/concepts/configuration/manage-resources-containers/#extended-resources)のためのリソースクォータのサポートが追加されました。 拡張リソースに対するオーバーコミットが禁止されているのと同様に、リソースクォータで拡張リソース用に`requests`と`limits`の両方を指定しても意味がありません。現在、拡張リソースに対しては`requests.`というプレフィックスのついたクォータアイテムのみ設定できます。 diff --git a/content/ja/docs/concepts/scheduling-eviction/api-eviction.md b/content/ja/docs/concepts/scheduling-eviction/api-eviction.md index 5834beae4bc17..201e6c6132776 100644 --- a/content/ja/docs/concepts/scheduling-eviction/api-eviction.md +++ b/content/ja/docs/concepts/scheduling-eviction/api-eviction.md @@ -89,4 +89,4 @@ APIサーバーが退去を許可した場合、以下の流れでPodが削除 ## {{% heading "whatsnext" %}} * [Pod Disruption Budget](/docs/tasks/run-application/configure-pdb/)でアプリケーションを保護する方法について学ぶ * [Node不足による退避](/docs/concepts/scheduling-eviction/node-pressure-eviction/)について学ぶ -* [Podの優先度とプリエンプション](/docs/concepts/scheduling-eviction/pod-priority-preemption/)について学ぶ +* [Podの優先度とプリエンプション](/ja/docs/concepts/scheduling-eviction/pod-priority-preemption/)について学ぶ diff --git a/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md index 0709be3982b00..c2bf25a5f14ba 100644 --- a/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -313,7 +313,7 @@ spec: 全体的な効果として、各キャッシュインスタンスは、同じNode上で実行している単一のクライアントによってアクセスされる可能性が高いです。この方法は、スキュー(負荷の偏り)とレイテンシーの両方を最小化することを目的としています。 Podアンチアフィニティを使用する理由は他にもあります。 -この例と同様の方法で、アンチアフィニティを用いて高可用性を実現したStatefulSetの使用例は[ZooKeeperチュートリアル](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)を参照してください。 +この例と同様の方法で、アンチアフィニティを用いて高可用性を実現したStatefulSetの使用例は[ZooKeeperチュートリアル](/ja/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)を参照してください。 ## nodeName {#nodename} diff --git a/content/ja/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/ja/docs/concepts/scheduling-eviction/kube-scheduler.md index 12a7971d88be8..9ccd610baec3f 100644 --- a/content/ja/docs/concepts/scheduling-eviction/kube-scheduler.md +++ b/content/ja/docs/concepts/scheduling-eviction/kube-scheduler.md @@ -52,19 +52,19 @@ _スコアリング_ ステップでは、Podを割り当てるのに最も適 スケジューラーのフィルタリングとスコアリングの動作に関する設定には2つのサポートされた手法があります。 -1. [スケジューリングポリシー](/docs/reference/scheduling/policies) は、フィルタリングのための _Predicates_ とスコアリングのための _Priorities_ の設定することができます。 -1. [スケジューリングプロファイル](/docs/reference/scheduling/config/#profiles)は、`QueueSort`、 `Filter`、 `Score`、 `Bind`、 `Reserve`、 `Permit`やその他を含む異なるスケジューリングの段階を実装するプラグインを設定することができます。kube-schedulerを異なるプロファイルを実行するように設定することもできます。 +1. [スケジューリングポリシー](/ja/docs/reference/scheduling/policies) は、フィルタリングのための _Predicates_ とスコアリングのための _Priorities_ の設定することができます。 +1. [スケジューリングプロファイル](/ja/docs/reference/scheduling/config/#profiles)は、`QueueSort`、 `Filter`、 `Score`、 `Bind`、 `Reserve`、 `Permit`やその他を含む異なるスケジューリングの段階を実装するプラグインを設定することができます。kube-schedulerを異なるプロファイルを実行するように設定することもできます。 ## {{% heading "whatsnext" %}} * [スケジューラーのパフォーマンスチューニング](/ja/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)を参照してください。 -* [Podトポロジーの分散制約](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)を参照してください。 +* [Podトポロジーの分散制約](/ja/docs/concepts/workloads/pods/pod-topology-spread-constraints/)を参照してください。 * kube-schedulerの[リファレンスドキュメント](/docs/reference/command-line-tools-reference/kube-scheduler/)を参照してください。 -* [複数のスケジューラーの設定](/docs/tasks/administer-cluster/configure-multiple-schedulers/)について学んでください。 +* [複数のスケジューラーの設定](/ja/docs/tasks/administer-cluster/configure-multiple-schedulers/)について学んでください。 * [トポロジーの管理ポリシー](/ja/docs/tasks/administer-cluster/topology-manager/)について学んでください。 * [Podのオーバーヘッド](/ja/docs/concepts/scheduling-eviction/pod-overhead/)について学んでください。 * ボリュームを使用するPodのスケジューリングについて以下で学んでください。 - * [Volume Topology Support](/docs/concepts/storage/storage-classes/#volume-binding-mode) + * [Volume Topology Support](/ja/docs/concepts/storage/storage-classes/#volume-binding-mode) * [ストレージ容量の追跡](/ja/docs/concepts/storage/storage-capacity/) * [Node-specific Volume Limits](/docs/concepts/storage/storage-limits/) diff --git a/content/ja/docs/concepts/scheduling-eviction/pod-overhead.md b/content/ja/docs/concepts/scheduling-eviction/pod-overhead.md index 916ecf94f2ce3..9a1a5f1f51b6c 100644 --- a/content/ja/docs/concepts/scheduling-eviction/pod-overhead.md +++ b/content/ja/docs/concepts/scheduling-eviction/pod-overhead.md @@ -16,7 +16,7 @@ PodをNode上で実行する時に、Pod自身は大量のシステムリソー -Kubernetesでは、Podの[RuntimeClass](/docs/concepts/containers/runtime-class/)に関連するオーバーヘッドに応じて、[アドミッション](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks)時にPodのオーバーヘッドが設定されます。 +Kubernetesでは、Podの[RuntimeClass](/ja/docs/concepts/containers/runtime-class/)に関連するオーバーヘッドに応じて、[アドミッション](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks)時にPodのオーバーヘッドが設定されます。 Podのオーバーヘッドを有効にした場合、Podのスケジューリング時にコンテナのリソース要求の合計に加えて、オーバーヘッドも考慮されます。同様に、Kubeletは、Podのcgroupのサイズ決定時およびPodの退役の順位付け時に、Podのオーバーヘッドを含めます。 diff --git a/content/ja/docs/concepts/scheduling-eviction/resource-bin-packing.md b/content/ja/docs/concepts/scheduling-eviction/resource-bin-packing.md index cc611761fcc2e..3289d59d79f79 100644 --- a/content/ja/docs/concepts/scheduling-eviction/resource-bin-packing.md +++ b/content/ja/docs/concepts/scheduling-eviction/resource-bin-packing.md @@ -194,4 +194,4 @@ NodeScore = ((5 * 5) + (7 * 1) + (10 * 3)) / (5 + 1 + 3) ## {{% heading "whatsnext" %}} - [スケジューリングフレームワーク](/ja/docs/concepts/scheduling-eviction/scheduling-framework/)について更に読む -- [スケジューラーの設定](/docs/reference/scheduling/config/)について更に読む +- [スケジューラーの設定](/ja/docs/reference/scheduling/config/)について更に読む diff --git a/content/ja/docs/concepts/scheduling-eviction/scheduling-framework.md b/content/ja/docs/concepts/scheduling-eviction/scheduling-framework.md index d748f38ed5db9..ff660784b073c 100644 --- a/content/ja/docs/concepts/scheduling-eviction/scheduling-framework.md +++ b/content/ja/docs/concepts/scheduling-eviction/scheduling-framework.md @@ -167,8 +167,8 @@ type PreFilterPlugin interface { ## プラグインの設定 -スケジューラーの設定でプラグインを有効化・無効化することができます。Kubernetes v1.18以降を使用しているなら、ほとんどのスケジューリング[プラグイン](/docs/reference/scheduling/config/#scheduling-plugins)は使用されており、デフォルトで有効になっています。 +スケジューラーの設定でプラグインを有効化・無効化することができます。Kubernetes v1.18以降を使用しているなら、ほとんどのスケジューリング[プラグイン](/ja/docs/reference/scheduling/config/#scheduling-plugins)は使用されており、デフォルトで有効になっています。 デフォルトのプラグインに加えて、独自のスケジューリングプラグインを実装し、デフォルトのプラグインと一緒に使用することも可能です。詳しくは[スケジューラープラグイン](https://github.com/kubernetes-sigs/scheduler-plugins)をご覧下さい。 -Kubernetes v1.18以降を使用しているなら、プラグインのセットをスケジューラープロファイルとして設定し、様々な種類のワークロードに適合するように複数のプロファイルを定義することが可能です。詳しくは[複数のプロファイル](/docs/reference/scheduling/config/#multiple-profiles)をご覧下さい。 +Kubernetes v1.18以降を使用しているなら、プラグインのセットをスケジューラープロファイルとして設定し、様々な種類のワークロードに適合するように複数のプロファイルを定義することが可能です。詳しくは[複数のプロファイル](/ja/docs/reference/scheduling/config/#multiple-profiles)をご覧下さい。 diff --git a/content/ja/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/ja/docs/concepts/scheduling-eviction/taint-and-toleration.md index 1e04e8be1eaf3..ba57b2d6a3feb 100644 --- a/content/ja/docs/concepts/scheduling-eviction/taint-and-toleration.md +++ b/content/ja/docs/concepts/scheduling-eviction/taint-and-toleration.md @@ -134,7 +134,7 @@ tolerationが設定されたPodはtaintの設定された（専有の）Nodeと `kubectl taint nodes nodename special=true:PreferNoSchedule`)して、ハードウェアを使用するPodに対応するtolerationを追加することで可能です。 専有Nodeのユースケースと同様に、tolerationを容易に適用する方法はカスタム [アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/)を使うことです。 -例えば、特殊なハードウェアを表すために[拡張リソース](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) +例えば、特殊なハードウェアを表すために[拡張リソース](/ja/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) を使い、ハードウェアを備えるNodeに拡張リソースの名称のtaintを追加して、 [拡張リソースtoleration](/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration) アドミッションコントローラーを実行することが推奨されます。Nodeにはtaintが付与されているため、tolerationのないPodはスケジューリングされません。しかし拡張リソースを要求するPodを作成しようとすると、`拡張リソースtoleration` アドミッションコントローラーはPodに自動的に適切なtolerationを設定し、Podはハードウェアを備えるNodeへスケジューリングされます。 @@ -217,5 +217,5 @@ DaemonSetのコントローラーは、DaemonSetが中断されるのを防ぐ ## {{% heading "whatsnext" %}} -* [リソース枯渇の対処](/docs/tasks/administer-cluster/out-of-resource/)とどのような設定ができるかについてを読む -* [Podの優先度](/docs/concepts/configuration/pod-priority-preemption/)を読む +* [リソース枯渇の対処](/ja/docs/tasks/administer-cluster/out-of-resource/)とどのような設定ができるかについてを読む +* [Podの優先度](/ja/docs/concepts/configuration/pod-priority-preemption/)を読む diff --git a/content/ja/docs/concepts/security/overview.md b/content/ja/docs/concepts/security/overview.md index b95d113a8e709..5ec2d7636d637 100644 --- a/content/ja/docs/concepts/security/overview.md +++ b/content/ja/docs/concepts/security/overview.md @@ -75,7 +75,7 @@ Kubernetesを保護する為には２つの懸念事項があります。 ### クラスターのコンポーネント {#cluster-components} -想定外または悪意のあるアクセスからクラスターを保護して適切なプラクティスを採用したい場合、[クラスターの保護](/docs/tasks/administer-cluster/securing-a-cluster/)に関するアドバイスを読み従ってください。 +想定外または悪意のあるアクセスからクラスターを保護して適切なプラクティスを採用したい場合、[クラスターの保護](/ja/docs/tasks/administer-cluster/securing-a-cluster/)に関するアドバイスを読み従ってください。 ### クラスター内のコンポーネント(アプリケーション) {#cluster-applications} @@ -127,8 +127,8 @@ TLS経由のアクセスのみ | コードがTCP通信を必要とする場合 * [Podセキュリティの標準](/ja/docs/concepts/security/pod-security-standards/) * [Podのネットワークポリシー](/ja/docs/concepts/services-networking/network-policies/) -* [Kubernetes APIへのアクセスを制御する](/docs/concepts/security/controlling-access) -* [クラスターの保護](/docs/tasks/administer-cluster/securing-a-cluster/) +* [Kubernetes APIへのアクセスを制御する](/ja/docs/concepts/security/controlling-access) +* [クラスターの保護](/ja/docs/tasks/administer-cluster/securing-a-cluster/) * コントロールプレーンとの[通信時のデータ暗号化](/docs/tasks/tls/managing-tls-in-a-cluster/) * [保存時のデータ暗号化](/docs/tasks/administer-cluster/encrypt-data/) * [Kubernetes Secret](/ja/docs/concepts/configuration/secret/) diff --git a/content/ja/docs/concepts/security/pod-security-admission.md b/content/ja/docs/concepts/security/pod-security-admission.md index 2b5703687731f..faa2a06133fbe 100644 --- a/content/ja/docs/concepts/security/pod-security-admission.md +++ b/content/ja/docs/concepts/security/pod-security-admission.md @@ -13,7 +13,7 @@ min-kubernetes-server-version: v1.22 Kubernetesの[Podセキュリティの標準](/ja/docs/concepts/security/pod-security-standards/)はPodに対して異なる分離レベルを定義します。 これらの標準によって、Podの動作をどのように制限したいかを、明確かつ一貫した方法で定義することができます。 -ベータ版機能として、Kubernetesは[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)の後継である組み込みの _Pod Security_ {{< glossary_tooltip text="アドミッションコントローラー" term_id="admission-controller" >}}を提供しています。 +ベータ版機能として、Kubernetesは[PodSecurityPolicy](/ja/docs/concepts/policy/pod-security-policy/)の後継である組み込みの _Pod Security_ {{< glossary_tooltip text="アドミッションコントローラー" term_id="admission-controller" >}}を提供しています。 Podセキュリティの制限は、Pod作成時に{{< glossary_tooltip text="名前空間" term_id="namespace" >}}レベルで適用されます。 {{< note >}} @@ -52,7 +52,7 @@ kubectl apply -k . ## Podのセキュリティレベル {#pod-security-levels} -Podのセキュリティアドミッションは、Podの[Security Context](/docs/tasks/configure-pod-container/security-context/)とその他の関連フィールドに、[Podセキュリティの標準](/ja/docs/concepts/security/pod-security-standards)で定義された3つのレベル、`privileged`、`baseline`、`restricted`に従って要件を設定するものです。 +Podのセキュリティアドミッションは、Podの[Security Context](/ja/docs/tasks/configure-pod-container/security-context/)とその他の関連フィールドに、[Podセキュリティの標準](/ja/docs/concepts/security/pod-security-standards)で定義された3つのレベル、`privileged`、`baseline`、`restricted`に従って要件を設定するものです。 これらの要件の詳細については、[Podセキュリティの標準](/ja/docs/concepts/security/pod-security-standards)のページを参照してください。 ## Podの名前空間に対するセキュリティアドミッションラベル {#pod-security-admission-labels-for-namespaces} diff --git a/content/ja/docs/concepts/security/pod-security-standards.md b/content/ja/docs/concepts/security/pod-security-standards.md index 0fcdc8109ac9b..1f5c04bf23246 100644 --- a/content/ja/docs/concepts/security/pod-security-standards.md +++ b/content/ja/docs/concepts/security/pod-security-standards.md @@ -6,9 +6,9 @@ weight: 10 -Podに対するセキュリティの設定は通常[Security Context](/docs/tasks/configure-pod-container/security-context/)を使用して適用されます。Security ContextはPod単位での特権やアクセスコントロールの定義を実現します。 +Podに対するセキュリティの設定は通常[Security Context](/ja/docs/tasks/configure-pod-container/security-context/)を使用して適用されます。Security ContextはPod単位での特権やアクセスコントロールの定義を実現します。 -クラスターにおけるSecurity Contextの強制やポリシーベースの定義は[Pod Security Policy](/docs/concepts/policy/pod-security-policy/)によって実現されてきました。 +クラスターにおけるSecurity Contextの強制やポリシーベースの定義は[Pod Security Policy](/ja/docs/concepts/policy/pod-security-policy/)によって実現されてきました。 _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義のセキュリティに関する設定を制御します。 しかし、PodSecurityPolicyを拡張したり代替する、ポリシーを強制するための多くの方法が生まれてきました。 @@ -356,7 +356,7 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義 機構が成熟してきたら、ポリシーごとに下記に定義されます。それぞれのポリシーを強制する方法についてはここでは定義しません。 -[**PodSecurityPolicy**](/docs/concepts/policy/pod-security-policy/) +[**PodSecurityPolicy**](/ja/docs/concepts/policy/pod-security-policy/) - [特権](https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/policy/privileged-psp.yaml) - [ベースライン](https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/policy/baseline-psp.yaml) @@ -374,12 +374,12 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義 ### セキュリティポリシーとセキュリティコンテキストの違いは何ですか? -[Security Context](/docs/tasks/configure-pod-container/security-context/)は実行時のコンテナやPodを設定するものです。 +[Security Context](/ja/docs/tasks/configure-pod-container/security-context/)は実行時のコンテナやPodを設定するものです。 Security ContextはPodのマニフェストの中でPodやコンテナの仕様の一部として定義され、コンテナランタイムへ渡されるパラメーターを示します。 セキュリティポリシーはコントロールプレーンの機構で、Security Contextとそれ以外も含め、特定の設定を強制するものです。 2020年2月時点では、ネイティブにサポートされているポリシー強制の機構は[Pod Security -Policy](/docs/concepts/policy/pod-security-policy/)です。これはクラスター全体にわたってセキュリティポリシーを中央集権的に強制するものです。 +Policy](/ja/docs/concepts/policy/pod-security-policy/)です。これはクラスター全体にわたってセキュリティポリシーを中央集権的に強制するものです。 セキュリティポリシーを強制する他の手段もKubernetesのエコシステムでは開発が進められています。例えば[OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper)があります。 diff --git a/content/ja/docs/concepts/services-networking/service-traffic-policy.md b/content/ja/docs/concepts/services-networking/service-traffic-policy.md index cfa2e71f81680..12e6d273c7018 100644 --- a/content/ja/docs/concepts/services-networking/service-traffic-policy.md +++ b/content/ja/docs/concepts/services-networking/service-traffic-policy.md @@ -52,6 +52,6 @@ kube-proxyは、`spec.internalTrafficPolicy`の設定に基づいて、ルーテ ## {{% heading "whatsnext" %}} -* [Topology Aware Hints](/docs/concepts/services-networking/topology-aware-hints)を読む +* [Topology Aware Hints](/ja/docs/concepts/services-networking/topology-aware-hints)を読む * [Service External Traffic Policy](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)を読む * [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を読む diff --git a/content/ja/docs/concepts/storage/dynamic-provisioning.md b/content/ja/docs/concepts/storage/dynamic-provisioning.md index 6ae7c8e469687..7c2f9ab62774a 100644 --- a/content/ja/docs/concepts/storage/dynamic-provisioning.md +++ b/content/ja/docs/concepts/storage/dynamic-provisioning.md @@ -20,7 +20,7 @@ weight: 50 ボリュームの動的プロビジョニングの実装は`storage.k8s.io`というAPIグループ内の`StorageClass`というAPIオブジェクトに基づいています。クラスター管理者は`StorageClass`オブジェクトを必要に応じていくつでも定義でき、各オブジェクトはボリュームをプロビジョンする*Volumeプラグイン* (別名*プロビジョナー*)と、プロビジョンされるときにプロビジョナーに渡されるパラメーターを指定します。 クラスター管理者はクラスター内で複数の種類のストレージ(同一または異なるストレージシステム)を定義し、さらには公開でき、それらのストレージはパラメーターのカスタムセットを持ちます。この仕組みにおいて、エンドユーザーはストレージがどのようにプロビジョンされるか心配する必要がなく、それでいて複数のストレージオプションから選択できることを保証します。 -StorageClassに関するさらなる情報は[Storage Class](/docs/concepts/storage/storage-classes/)を参照ください。 +StorageClassに関するさらなる情報は[Storage Class](/ja/docs/concepts/storage/storage-classes/)を参照ください。 ## 動的プロビジョニングを有効にする @@ -86,6 +86,6 @@ spec: ## トポロジーに関する注意 -[マルチゾーン](/docs/setup/multiple-zones)クラスター内では、Podは単一のリージョン内のゾーンをまたいでしか稼働できません。シングルゾーンのStorageバックエンドはPodがスケジュールされるゾーン内でプロビジョンされる必要があります。これは[Volume割り当てモード](/docs/concepts/storage/storage-classes/#volume-binding-mode)を設定することにより可能となります。 +[マルチゾーン](/ja/docs/setup/multiple-zones)クラスター内では、Podは単一のリージョン内のゾーンをまたいでしか稼働できません。シングルゾーンのStorageバックエンドはPodがスケジュールされるゾーン内でプロビジョンされる必要があります。これは[Volume割り当てモード](/ja/docs/concepts/storage/storage-classes/#volume-binding-mode)を設定することにより可能となります。 diff --git a/content/ja/docs/concepts/storage/ephemeral-volumes.md b/content/ja/docs/concepts/storage/ephemeral-volumes.md index 27159260a17b3..8b70554b98729 100644 --- a/content/ja/docs/concepts/storage/ephemeral-volumes.md +++ b/content/ja/docs/concepts/storage/ephemeral-volumes.md @@ -97,7 +97,7 @@ Pod仕様内でインラインボリュームとして使用できるCSIドラ - ストレージは、ローカルまたはネットワークに接続できます。 - ボリュームは、Podが超えることができない固定サイズを持つことができます。 - ボリュームには、ドライバーとパラメーターによっては、いくつかの初期データがある場合があります。 -- [スナップショット](/docs/concepts/storage/volume-snapshots/)、[クローン作成](/ja/docs/concepts/storage/volume-pvc-datasource/)、[サイズ変更](/ja/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims)、[ストレージ容量の追跡](/ja/docs/concepts/storage/storage-capacity/)などボリュームに対する一般的な操作は、ドライバーがそれらをサポートしていることを前提としてサポートされています。 +- [スナップショット](/ja/docs/concepts/storage/volume-snapshots/)、[クローン作成](/ja/docs/concepts/storage/volume-pvc-datasource/)、[サイズ変更](/ja/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims)、[ストレージ容量の追跡](/ja/docs/concepts/storage/storage-capacity/)などボリュームに対する一般的な操作は、ドライバーがそれらをサポートしていることを前提としてサポートされています。 例: diff --git a/content/ja/docs/concepts/storage/persistent-volumes.md b/content/ja/docs/concepts/storage/persistent-volumes.md index 7ae4802212538..f37327377fcd5 100644 --- a/content/ja/docs/concepts/storage/persistent-volumes.md +++ b/content/ja/docs/concepts/storage/persistent-volumes.md @@ -11,7 +11,7 @@ weight: 20 -このドキュメントではKubernetesの _PersistentVolume_ について説明します。[ボリューム](/docs/concepts/storage/volumes/)を一読することをおすすめします。 +このドキュメントではKubernetesの _PersistentVolume_ について説明します。[ボリューム](/ja/docs/concepts/storage/volumes/)を一読することをおすすめします。 @@ -22,7 +22,7 @@ weight: 20 ストレージを管理することはインスタンスを管理することとは全くの別物です。PersistentVolumeサブシステムは、ストレージが何から提供されているか、どのように消費されているかをユーザーと管理者から抽象化するAPIを提供します。これを実現するためのPersistentVolumeとPersistentVolumeClaimという2つの新しいAPIリソースを紹介します。 -_PersistentVolume_ (PV)は[ストレージクラス](/docs/concepts/storage/storage-classes/)を使って管理者もしくは動的にプロビジョニングされるクラスターのストレージの一部です。これはNodeと同じようにクラスターリソースの一部です。PVはVolumeのようなボリュームプラグインですが、PVを使う個別のPodとは独立したライフサイクルを持っています。このAPIオブジェクトはNFS、iSCSIやクラウドプロバイダー固有のストレージシステムの実装の詳細を捕捉します。 +_PersistentVolume_ (PV)は[ストレージクラス](/ja/docs/concepts/storage/storage-classes/)を使って管理者もしくは動的にプロビジョニングされるクラスターのストレージの一部です。これはNodeと同じようにクラスターリソースの一部です。PVはVolumeのようなボリュームプラグインですが、PVを使う個別のPodとは独立したライフサイクルを持っています。このAPIオブジェクトはNFS、iSCSIやクラウドプロバイダー固有のストレージシステムの実装の詳細を捕捉します。 _PersistentVolumeClaim_ (PVC)はユーザーによって要求されるストレージです。これはPodと似ています。PodはNodeリソースを消費し、PVCはPVリソースを消費します。Podは特定レベルのCPUとメモリーリソースを要求することができます。クレームは特定のサイズやアクセスモード(例えば、ReadWriteOnce、ReadOnlyMany、ReadWriteManyにマウントできます。詳しくは[アクセスモード](#access-modes)を参照してください)を要求することができます。 @@ -46,7 +46,7 @@ PVは静的か動的どちらかでプロビジョニングされます。 #### 動的 ユーザーのPersistentVolumeClaimが管理者の作成したいずれの静的PVにも一致しない場合、クラスターはPVC用にボリュームを動的にプロビジョニングしようとする場合があります。 -このプロビジョニングはStorageClassに基づいています。PVCは[ストレージクラス](/docs/concepts/storage/storage-classes/)の要求が必要であり、管理者は動的プロビジョニングを行うためにストレージクラスの作成・設定が必要です。ストレージクラスを""にしたストレージ要求は、自身の動的プロビジョニングを事実上無効にします。 +このプロビジョニングはStorageClassに基づいています。PVCは[ストレージクラス](/ja/docs/concepts/storage/storage-classes/)の要求が必要であり、管理者は動的プロビジョニングを行うためにストレージクラスの作成・設定が必要です。ストレージクラスを""にしたストレージ要求は、自身の動的プロビジョニングを事実上無効にします。 ストレージクラスに基づいたストレージの動的プロビジョニングを有効化するには、クラスター管理者が`DefaultStorageClass`[アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)をAPIサーバーで有効化する必要があります。 これは例えば、`DefaultStorageClass`がAPIサーバーコンポーネントの`--enable-admission-plugins`フラグのコンマ区切りの順序付きリストの中に含まれているかで確認できます。 @@ -171,7 +171,7 @@ spec: 永続ボリュームが存在し、その`claimRef`フィールドで永続ボリュームクレームを予約していない場合に永続ボリュームと永続ボリュームクレームがバインドされます。 バインディングは、ノードアフィニティを含むいくつかのボリュームの一致基準に関係なく発生します。 -コントロールプレーンは、依然として[ストレージクラス](/docs/concepts/storage/storage-classes/)、アクセスモード、および要求されたストレージサイズが有効であることをチェックします。 +コントロールプレーンは、依然として[ストレージクラス](/ja/docs/concepts/storage/storage-classes/)、アクセスモード、および要求されたストレージサイズが有効であることをチェックします。 ```yaml apiVersion: v1 @@ -261,7 +261,7 @@ FlexVolumeは、Podの再起動時にサイズ変更できます。 {{< feature-state for_k8s_version="v1.15" state="beta" >}} {{< note >}} -使用中のPVCの拡張は、Kubernetes 1.15以降のベータ版と、1.11以降のアルファ版として利用可能です。`ExpandInUsePersistentVolume`機能を有効化する必要があります。これはベータ機能のため多くのクラスターで自動的に行われます。詳細については、[フィーチャーゲート](/docs/reference/command-line-tools-reference/feature-gates/)のドキュメントを参照してください。 +使用中のPVCの拡張は、Kubernetes 1.15以降のベータ版と、1.11以降のアルファ版として利用可能です。`ExpandInUsePersistentVolume`機能を有効化する必要があります。これはベータ機能のため多くのクラスターで自動的に行われます。詳細については、[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)のドキュメントを参照してください。 {{< /note >}} この場合、既存のPVCを使用しているPodまたはDeploymentを削除して再作成する必要はありません。使用中のPVCは、ファイルシステムが拡張されるとすぐにPodで自動的に使用可能になります。この機能は、PodまたはDeploymentで使用されていないPVCには影響しません。拡張を完了する前に、PVCを使用するPodを作成する必要があります。 @@ -290,32 +290,32 @@ EBSの拡張は時間がかかる操作です。また変更は、ボリュー PersistentVolumeの種類はプラグインとして実装されます。Kubernetesは現在次のプラグインに対応しています。 -* [`awsElasticBlockStore`](/docs/concepts/storage/volumes/#awselasticblockstore) - AWS Elastic Block Store (EBS) -* [`azureDisk`](/docs/concepts/storage/volumes/#azuredisk) - Azure Disk -* [`azureFile`](/docs/concepts/storage/volumes/#azurefile) - Azure File -* [`cephfs`](/docs/concepts/storage/volumes/#cephfs) - CephFS volume -* [`cinder`](/docs/concepts/storage/volumes/#cinder) - Cinder (OpenStack block storage) +* [`awsElasticBlockStore`](/ja/docs/concepts/storage/volumes/#awselasticblockstore) - AWS Elastic Block Store (EBS) +* [`azureDisk`](/ja/docs/concepts/storage/volumes/#azuredisk) - Azure Disk +* [`azureFile`](/ja/docs/concepts/storage/volumes/#azurefile) - Azure File +* [`cephfs`](/ja/docs/concepts/storage/volumes/#cephfs) - CephFS volume +* [`cinder`](/ja/docs/concepts/storage/volumes/#cinder) - Cinder (OpenStack block storage) (**非推奨**) -* [`csi`](/docs/concepts/storage/volumes/#csi) - Container Storage Interface (CSI) -* [`fc`](/docs/concepts/storage/volumes/#fc) - Fibre Channel (FC) storage -* [`flexVolume`](/docs/concepts/storage/volumes/#flexVolume) - FlexVolume -* [`flocker`](/docs/concepts/storage/volumes/#flocker) - Flocker storage -* [`gcePersistentDisk`](/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE Persistent Disk -* [`glusterfs`](/docs/concepts/storage/volumes/#glusterfs) - Glusterfs volume -* [`hostPath`](/docs/concepts/storage/volumes/#hostpath) - HostPath volume +* [`csi`](/ja/docs/concepts/storage/volumes/#csi) - Container Storage Interface (CSI) +* [`fc`](/ja/docs/concepts/storage/volumes/#fc) - Fibre Channel (FC) storage +* [`flexVolume`](/ja/docs/concepts/storage/volumes/#flexVolume) - FlexVolume +* [`flocker`](/ja/docs/concepts/storage/volumes/#flocker) - Flocker storage +* [`gcePersistentDisk`](/ja/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE Persistent Disk +* [`glusterfs`](/ja/docs/concepts/storage/volumes/#glusterfs) - Glusterfs volume +* [`hostPath`](/ja/docs/concepts/storage/volumes/#hostpath) - HostPath volume (テスト用の単一ノードのみ。マルチノードクラスターでは動作しません。代わりに`local`ボリュームを利用することを検討してください。) -* [`iscsi`](/docs/concepts/storage/volumes/#iscsi) - iSCSI (SCSI over IP) storage -* [`local`](/docs/concepts/storage/volumes/#local) - ノードにマウントされたローカルストレージデバイス -* [`nfs`](/docs/concepts/storage/volumes/#nfs) - Network File System (NFS) storage +* [`iscsi`](/ja/docs/concepts/storage/volumes/#iscsi) - iSCSI (SCSI over IP) storage +* [`local`](/ja/docs/concepts/storage/volumes/#local) - ノードにマウントされたローカルストレージデバイス +* [`nfs`](/ja/docs/concepts/storage/volumes/#nfs) - Network File System (NFS) storage * `photonPersistentDisk` - Photon controller persistent disk (対応するクラウドプロバイダーが削除されたため、このボリュームタイプは機能しなくなりました。) -* [`portworxVolume`](/docs/concepts/storage/volumes/#portworxvolume) - Portworx volume -* [`quobyte`](/docs/concepts/storage/volumes/#quobyte) - Quobyte volume -* [`rbd`](/docs/concepts/storage/volumes/#rbd) - Rados Block Device (RBD) volume -* [`scaleIO`](/docs/concepts/storage/volumes/#scaleio) - ScaleIO volume +* [`portworxVolume`](/ja/docs/concepts/storage/volumes/#portworxvolume) - Portworx volume +* [`quobyte`](/ja/docs/concepts/storage/volumes/#quobyte) - Quobyte volume +* [`rbd`](/ja/docs/concepts/storage/volumes/#rbd) - Rados Block Device (RBD) volume +* [`scaleIO`](/ja/docs/concepts/storage/volumes/#scaleio) - ScaleIO volume (**非推奨**) -* [`storageos`](/docs/concepts/storage/volumes/#storageos) - StorageOS volume -* [`vsphereVolume`](/docs/concepts/storage/volumes/#vspherevolume) - vSphere VMDK volume +* [`storageos`](/ja/docs/concepts/storage/volumes/#storageos) - StorageOS volume +* [`vsphereVolume`](/ja/docs/concepts/storage/volumes/#vspherevolume) - vSphere VMDK volume ## 永続ボリューム @@ -388,7 +388,7 @@ PersistentVolumeは、リソースプロバイダーがサポートする方法 `ReadWriteOncePod` : ボリュームは、単一のPodで読み取り/書き込みとしてマウントできます。クラスター全体で1つのPodのみがそのPVCの読み取りまたは書き込みを行えるようにする場合は、ReadWriteOncePodアクセスモードを使用します。これは、CSIボリュームとKubernetesバージョン1.22以降でのみサポートされます。 -これについてはブログ[Introducing Single Pod Access Mode for PersistentVolumes](/blog/2021/09/13/read-write-once-pod-access-mode-alpha/)に詳細が記載されています。 +これについてはブログ[Introducing Single Pod Access Mode for PersistentVolumes](/ja/blog/2021/09/13/read-write-once-pod-access-mode-alpha/)に詳細が記載されています。 CLIではアクセスモードは次のように略されます。 @@ -425,7 +425,7 @@ CLIではアクセスモードは次のように略されます。 ### Class -PVはクラスを持つことができます。これは`storageClassName`属性を[ストレージクラス](/docs/concepts/storage/storage-classes/)の名前に設定することで指定されます。特定のクラスのPVは、そのクラスを要求するPVCにのみバインドできます。`storageClassName`にクラスがないPVは、特定のクラスを要求しないPVCにのみバインドできます。 +PVはクラスを持つことができます。これは`storageClassName`属性を[ストレージクラス](/ja/docs/concepts/storage/storage-classes/)の名前に設定することで指定されます。特定のクラスのPVは、そのクラスを要求するPVCにのみバインドできます。`storageClassName`にクラスがないPVは、特定のクラスを要求しないPVCにのみバインドできます。 以前`volume.beta.kubernetes.io/storage-class`アノテーションは、`storageClassName`属性の代わりに使用されていました。このアノテーションはまだ機能しています。ただし、将来のKubernetesリリースでは完全に非推奨です。 @@ -470,7 +470,7 @@ Kubernetes管理者は永続ボリュームがNodeにマウントされるとき ### ノードアフィニティ {{< note >}} -ほとんどのボリュームタイプはこのフィールドを設定する必要がありません。[AWS EBS](/docs/concepts/storage/volumes/#awselasticblockstore)、[GCE PD](/docs/concepts/storage/volumes/#gcepersistentdisk)、もしくは[Azure Disk](/docs/concepts/storage/volumes/#azuredisk)ボリュームブロックタイプの場合自動的に設定されます。[local](/docs/concepts/storage/volumes/#local)ボリュームは明示的に設定する必要があります。 +ほとんどのボリュームタイプはこのフィールドを設定する必要がありません。[AWS EBS](/ja/docs/concepts/storage/volumes/#awselasticblockstore)、[GCE PD](/ja/docs/concepts/storage/volumes/#gcepersistentdisk)、もしくは[Azure Disk](/ja/docs/concepts/storage/volumes/#azuredisk)ボリュームブロックタイプの場合自動的に設定されます。[local](/ja/docs/concepts/storage/volumes/#local)ボリュームは明示的に設定する必要があります。 {{< /note >}} PVは[ノードアフィニティ](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volumenodeaffinity-v1-core)を指定して、このボリュームにアクセスできるNodeを制限する制約を定義できます。PVを使用するPodは、ノードアフィニティによって選択されたNodeにのみスケジュールされます。 @@ -536,7 +536,7 @@ Podと同様に、クレームは特定の量のリソースを要求できま ### クラス -クレームは、`storageClassName`属性を使用して[ストレージクラス](/docs/concepts/storage/storage-classes/)の名前を指定することにより、特定のクラスを要求できます。PVCにバインドできるのは、PVCと同じ`storageClassName`を持つ、要求されたクラスのPVのみです。 +クレームは、`storageClassName`属性を使用して[ストレージクラス](/ja/docs/concepts/storage/storage-classes/)の名前を指定することにより、特定のクラスを要求できます。PVCにバインドできるのは、PVCと同じ`storageClassName`を持つ、要求されたクラスのPVのみです。 PVCは必ずしもクラスをリクエストする必要はありません。`storageClassName`が`""`に設定されているPVCは、クラスのないPVを要求していると常に解釈されるため、クラスのないPVにのみバインドできます（アノテーションがないか、`""`に等しい1つのセット）。`storageClassName`のないPVCはまったく同じではなく、[`DefaultStorageClass`アドミッションプラグイン](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)がオンになっているかどうかによって、クラスターによって異なる方法で処理されます。 @@ -682,7 +682,7 @@ Podにrawブロックデバイスを追加する場合は、マウントパス {{< feature-state for_k8s_version="v1.17" state="beta" >}} -ボリュームスナップショット機能は、CSIボリュームプラグインのみをサポートするために追加されました。詳細については、[ボリュームのスナップショット](/docs/concepts/storage/volume-snapshots/)を参照してください。 +ボリュームスナップショット機能は、CSIボリュームプラグインのみをサポートするために追加されました。詳細については、[ボリュームのスナップショット](/ja/docs/concepts/storage/volume-snapshots/)を参照してください。 ボリュームスナップショットのデータソースからボリュームを復元する機能を有効にするには、apiserverおよびcontroller-managerで`VolumeSnapshotDataSource`フィーチャーゲートを有効にします。 diff --git a/content/ja/docs/concepts/storage/projected-volumes.md b/content/ja/docs/concepts/storage/projected-volumes.md index 6cd6daad1f034..09f0130152cea 100644 --- a/content/ja/docs/concepts/storage/projected-volumes.md +++ b/content/ja/docs/concepts/storage/projected-volumes.md @@ -6,7 +6,7 @@ weight: 21 # just after persistent volumes -このドキュメントでは、Kubernetesの*投影ボリューム*について説明します。[ボリューム](/docs/concepts/storage/volumes/)に精通していることをお勧めします。 +このドキュメントでは、Kubernetesの*投影ボリューム*について説明します。[ボリューム](/ja/docs/concepts/storage/volumes/)に精通していることをお勧めします。 @@ -16,9 +16,9 @@ weight: 21 # just after persistent volumes 現在、次のタイプのボリュームソースを投影できます。 -* [`secret`](/docs/concepts/storage/volumes/#secret) -* [`downwardAPI`](/docs/concepts/storage/volumes/#downwardapi) -* [`configMap`](/docs/concepts/storage/volumes/#configmap) +* [`secret`](/ja/docs/concepts/storage/volumes/#secret) +* [`downwardAPI`](/ja/docs/concepts/storage/volumes/#downwardapi) +* [`configMap`](/ja/docs/concepts/storage/volumes/#configmap) * `serviceAccountToken` すべてのソースは、Podと同じnamespaceにある必要があります。詳細は[all-in-one volume](https://github.com/kubernetes/design-proposals-archive/blob/main/node/all-in-one-volume.md)デザインドキュメントを参照してください。 @@ -49,7 +49,7 @@ weight: 21 # just after persistent volumes {{< note >}} -投影ボリュームソースを[`subPath`](/docs/concepts/storage/volumes/#using-subpath)ボリュームマウントとして使用しているコンテナは、それらのボリュームソースの更新を受信しません。 +投影ボリュームソースを[`subPath`](/ja/docs/concepts/storage/volumes/#using-subpath)ボリュームマウントとして使用しているコンテナは、それらのボリュームソースの更新を受信しません。 {{< /note >}} ## SecurityContextの相互作用 diff --git a/content/ja/docs/concepts/storage/storage-capacity.md b/content/ja/docs/concepts/storage/storage-capacity.md index 2bce4dcb810db..045414c16b5ec 100644 --- a/content/ja/docs/concepts/storage/storage-capacity.md +++ b/content/ja/docs/concepts/storage/storage-capacity.md @@ -30,14 +30,14 @@ weight: 80 - `CSIStorageCapacity`フィーチャーゲートがtrueである - Podがまだ作成されていないボリュームを使用する時 -- そのボリュームが、CSIドライバーを参照し、[volume binding mode](/docs/concepts/storage/storage-classes/#volume-binding-mode)に`WaitForFirstConsumer`を使う{{< glossary_tooltip text="StorageClass" term_id="storage-class" >}}を使用している +- そのボリュームが、CSIドライバーを参照し、[volume binding mode](/ja/docs/concepts/storage/storage-classes/#volume-binding-mode)に`WaitForFirstConsumer`を使う{{< glossary_tooltip text="StorageClass" term_id="storage-class" >}}を使用している - ドライバーに対する`CSIDriver`オブジェクトの`StorageCapacity`がtrueに設定されている その場合、スケジューラーはPodに対して、十分なストレージ容量が利用できるノードだけを考慮するようになります。このチェックは非常に単純で、ボリュームのサイズと、`CSIStorageCapacity`オブジェクトに一覧された容量を、ノードを含むトポロジーで比較するだけです。 volume binding modeが`Immediate`のボリュームの場合、ストレージドライバーはボリュームを使用するPodとは関係なく、ボリュームを作成する場所を決定します。次に、スケジューラーはボリュームが作成された後、Podをボリュームが利用できるノードにスケジューリングします。 -[CSI ephemeral volumes](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volumes)の場合、スケジューリングは常にストレージ容量を考慮せずに行われます。このような動作になっているのは、このボリュームタイプはノードローカルな特別なCSIドライバーでのみ使用され、そこでは特に大きなリソースが必要になることはない、という想定に基づいています。 +[CSI ephemeral volumes](/ja/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volumes)の場合、スケジューリングは常にストレージ容量を考慮せずに行われます。このような動作になっているのは、このボリュームタイプはノードローカルな特別なCSIドライバーでのみ使用され、そこでは特に大きなリソースが必要になることはない、という想定に基づいています。 ## 再スケジューリング diff --git a/content/ja/docs/concepts/storage/storage-classes.md b/content/ja/docs/concepts/storage/storage-classes.md index e0df25f382ff4..3d2f7156cfcdd 100644 --- a/content/ja/docs/concepts/storage/storage-classes.md +++ b/content/ja/docs/concepts/storage/storage-classes.md @@ -337,7 +337,7 @@ vSphereストレージクラスのプロビジョナーには2つのタイプが - [CSIプロビジョナー](#vsphere-provisioner-csi):`csi.vsphere.vmware.com` - [vCPプロビジョナー](#vcp-provisioner):`kubernetes.io/vsphere-volume` -インツリープロビジョナーは[非推奨です](/blog/2019/12/09/kubernetes-1-17-feature-csi-migration-beta/#why-are-we-migrating-in-tree-plugins-to-csi)。CSIプロビジョナーの詳細については、[Kubernetes vSphere CSIドライバー](https://vsphere-csi-driver.sigs.k8s.io/)および[vSphereVolume CSI移行](/ja/docs/concepts/storage/volumes/#vsphere-csi-migration)を参照してください。 +インツリープロビジョナーは[非推奨です](/ja/blog/2019/12/09/kubernetes-1-17-feature-csi-migration-beta/#why-are-we-migrating-in-tree-plugins-to-csi)。CSIプロビジョナーの詳細については、[Kubernetes vSphere CSIドライバー](https://vsphere-csi-driver.sigs.k8s.io/)および[vSphereVolume CSI移行](/ja/docs/concepts/storage/volumes/#vsphere-csi-migration)を参照してください。 #### CSIプロビジョナー {#vsphere-provisioner-csi} diff --git a/content/ja/docs/concepts/storage/volume-health-monitoring.md b/content/ja/docs/concepts/storage/volume-health-monitoring.md index 825572faf9937..ff4bd24fc9049 100644 --- a/content/ja/docs/concepts/storage/volume-health-monitoring.md +++ b/content/ja/docs/concepts/storage/volume-health-monitoring.md @@ -22,7 +22,7 @@ CSIドライバーがコントローラー側からのボリュームヘルス CSIドライバーがノード側からのボリュームヘルスモニタリング機能をサポートしている場合、CSIボリュームで異常なボリューム状態が検出されると、PVCを使用するすべてのPodでイベントが報告されます。さらに、ボリュームヘルス情報はKubelet VolumeStatsメトリクスとして公開されます。新しいメトリックkubelet_volume_stats_health_status_abnormalが追加されました。このメトリックには`namespace`と`persistentvolumeclaim`の2つのラベルが含まれます。カウントは1または0です。1はボリュームが異常であることを示し、0はボリュームが正常であることを示します。詳細については、[KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1432-volume-health-monitor#kubelet-metrics-changes)を確認してください。 {{< note >}} -ノード側からこの機能を使用するには、`CSIVolumeHealth`[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)を有効にする必要があります。 +ノード側からこの機能を使用するには、`CSIVolumeHealth`[feature gate](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にする必要があります。 {{< /note >}} ## {{% heading "whatsnext" %}} diff --git a/content/ja/docs/concepts/storage/volume-pvc-datasource.md b/content/ja/docs/concepts/storage/volume-pvc-datasource.md index 8e0a9f7c7b86b..0232c3039dada 100644 --- a/content/ja/docs/concepts/storage/volume-pvc-datasource.md +++ b/content/ja/docs/concepts/storage/volume-pvc-datasource.md @@ -6,7 +6,7 @@ weight: 70 -このドキュメントではKubernetesで既存のCSIボリュームの複製についてのコンセプトを説明します。このページを読む前にあらかじめ[ボリューム](/docs/concepts/storage/volumes)についてよく理解していることが望ましいです。 +このドキュメントではKubernetesで既存のCSIボリュームの複製についてのコンセプトを説明します。このページを読む前にあらかじめ[ボリューム](/ja/docs/concepts/storage/volumes)についてよく理解していることが望ましいです。 diff --git a/content/ja/docs/concepts/storage/volume-snapshot-classes.md b/content/ja/docs/concepts/storage/volume-snapshot-classes.md index 414b70d8967b9..1717c4fa0b151 100644 --- a/content/ja/docs/concepts/storage/volume-snapshot-classes.md +++ b/content/ja/docs/concepts/storage/volume-snapshot-classes.md @@ -8,7 +8,7 @@ weight: 61 # just after volume snapshots このドキュメントでは、Kubernetesにおける`VolumeSnapshotClass`のコンセプトについて説明します。 -関連する項目として、[Volumeのスナップショット](/docs/concepts/storage/volume-snapshots/)と[ストレージクラス](/docs/concepts/storage/storage-classes)も参照してください。 +関連する項目として、[Volumeのスナップショット](/ja/docs/concepts/storage/volume-snapshots/)と[ストレージクラス](/ja/docs/concepts/storage/storage-classes)も参照してください。 diff --git a/content/ja/docs/concepts/storage/volumes.md b/content/ja/docs/concepts/storage/volumes.md index df385712b7a7b..5617e46ca8949 100644 --- a/content/ja/docs/concepts/storage/volumes.md +++ b/content/ja/docs/concepts/storage/volumes.md @@ -369,7 +369,7 @@ spec: #### リージョンPD PersistentVolumeを手動でプロビジョニングする -[GCE PDのStorageClass](/docs/concepts/storage/storage-classes/#gce-pd)を使用して動的プロビジョニングが可能です。 +[GCE PDのStorageClass](/ja/docs/concepts/storage/storage-classes/#gce-pd)を使用して動的プロビジョニングが可能です。 SPDPersistentVolumeを作成する前に、永続ディスクを作成する必要があります。 ```shell @@ -496,7 +496,7 @@ AdmissionPolicyによって特定のディレクトリへのHostPathアクセス * HostPath は、特権的なシステム認証情報(Kubeletなど)や特権的なAPI(コンテナランタイムソケットなど)を公開する可能性があり、コンテナのエスケープやクラスターの他の部分への攻撃に利用される可能性があります。 * 同一構成のPod(PodTemplateから作成されたものなど)は、ノード上のファイルが異なるため、ノードごとに動作が異なる場合があります。 -* ホスト上に作成されたファイルやディレクトリは、rootでしか書き込みができません。[特権コンテナ](/docs/tasks/configure-pod-container/security-context/)内でrootとしてプロセスを実行するか、ホスト上のファイルのパーミッションを変更して`hostPath`ボリュームに書き込みができるようにする必要があります。 +* ホスト上に作成されたファイルやディレクトリは、rootでしか書き込みができません。[特権コンテナ](/ja/docs/tasks/configure-pod-container/security-context/)内でrootとしてプロセスを実行するか、ホスト上のファイルのパーミッションを変更して`hostPath`ボリュームに書き込みができるようにする必要があります。 #### hostPathの設定例 @@ -523,7 +523,7 @@ spec: {{< caution >}} `FileOrCreate`モードでは、ファイルの親ディレクトリは作成されません。マウントされたファイルの親ディレクトリが存在しない場合、Podは起動に失敗します。 -このモードが確実に機能するようにするには、[`FileOrCreate`構成](＃hostpath-fileorcreate-example)に示すように、ディレクトリとファイルを別々にマウントしてみてください。 +このモードが確実に機能するようにするには、[`FileOrCreate`構成](/ja＃hostpath-fileorcreate-example)に示すように、ディレクトリとファイルを別々にマウントしてみてください。 {{< /caution >}} #### hostPath FileOrCreateの設定例 {#hostpath-fileorcreate-example} @@ -619,7 +619,7 @@ KubernetesのスケジューラはPersistentVolume `nodeAffinity`を使用して PersistentVolume `volumeMode`を(デフォルト値の「Filesystem」ではなく)「Block」に設定して、ローカルボリュームをrawブロックデバイスとして公開できます。 ローカルボリュームを使用する場合、`volumeBindingMode`を`WaitForFirstConsumer`に設定したStorageClassを作成することをお勧めします。 -詳細については、local [StorageClass](/docs/concepts/storage/storage-classes/#local)の例を参照してください。 +詳細については、local [StorageClass](/ja/docs/concepts/storage/storage-classes/#local)の例を参照してください。 ボリュームバインディングを遅延させると、PersistentVolumeClaimバインディングの決定が、ノードリソース要件、ノードセレクター、Podアフィニティ、Podアンチアフィニティなど、Podが持つ可能性のある他のノード制約も含めて評価されるようになります。 ローカルボリュームのライフサイクルの管理を改善するために、外部の静的プロビジョナーを個別に実行できます。 @@ -688,7 +688,7 @@ Podで使用する前に、`pxvol`という名前の既存のPortworxVolumeが ### 投影 投影ボリュームは、複数の既存のボリュームソースを同じディレクトリにマッピングします。 -詳細については[投影ボリューム](/docs/concepts/storage/projected-volumes/)を参照してください。 +詳細については[投影ボリューム](/ja/docs/concepts/storage/projected-volumes/)を参照してください。 ### quobyte(非推奨) {#quobyte} @@ -1018,8 +1018,8 @@ CSI互換のボリュームドライバーがKubernetesクラスター上に展 `csi`ボリュームはPodで3つの異なる方法によって使用することができます。 * [PersistentVolumeClaim](#persistentvolumeclaim)の参照を通して -* [一般的なエフェメラルボリューム](/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volumes)(alpha機能)で -* ドライバーがそれをサポートしている場合は、[CSIエフェメラルボリューム](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volumes)(beta機能)を使って +* [一般的なエフェメラルボリューム](/ja/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volumes)(alpha機能)で +* ドライバーがそれをサポートしている場合は、[CSIエフェメラルボリューム](/ja/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volumes)(beta機能)を使って ストレージ管理者は、CSI永続ボリュームを構成するために次のフィールドを使用できます。 @@ -1040,13 +1040,13 @@ CSI互換のボリュームドライバーがKubernetesクラスター上に展 外部のCSIドライバーを使用するベンダーは、Kubernetesワークロードでrawブロックボリュームサポートを実装できます。 -CSI固有の変更を行うことなく、通常どおり、[rawブロックボリュームをサポートするPersistentVolume/PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)を設定できます。 +CSI固有の変更を行うことなく、通常どおり、[rawブロックボリュームをサポートするPersistentVolume/PersistentVolumeClaim](/ja/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)を設定できます。 #### CSIエフェメラルボリューム {{< feature-state for_k8s_version="v1.16" state="beta" >}} -Pod仕様内でCSIボリュームを直接構成できます。この方法で指定されたボリュームは一時的なものであり、Podを再起動しても持続しません。詳細については[エフェメラルボリューム](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volumes)を参照してください。 +Pod仕様内でCSIボリュームを直接構成できます。この方法で指定されたボリュームは一時的なものであり、Podを再起動しても持続しません。詳細については[エフェメラルボリューム](/ja/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volumes)を参照してください。 CSIドライバーの開発方法の詳細については[kubernetes-csiドキュメント](https://kubernetes-csi.github.io/docs/)を参照してください。 @@ -1059,7 +1059,7 @@ CSIドライバーの開発方法の詳細については[kubernetes-csiドキ サポートされている操作と機能には、プロビジョニング/削除、アタッチ/デタッチ、マウント/アンマウント、およびボリュームのサイズ変更が含まれます。 -`CSIMigration`をサポートし、対応するCSIドライバーが実装されているツリー内プラグインは、[ボリュームのタイプ](＃volume-types)にリストされています。 +`CSIMigration`をサポートし、対応するCSIドライバーが実装されているツリー内プラグインは、[ボリュームのタイプ](/ja＃volume-types)にリストされています。 ### flexVolume @@ -1128,5 +1128,5 @@ sudo systemctl restart docker ## {{% heading "whatsnext" %}} -[永続ボリュームを使用してWordPressとMySQLをデプロイする例](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/)に従ってください。 +[永続ボリュームを使用してWordPressとMySQLをデプロイする例](/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/)に従ってください。 diff --git a/content/ja/docs/concepts/workloads/_index.md b/content/ja/docs/concepts/workloads/_index.md index 94631dc878d64..1076025475365 100644 --- a/content/ja/docs/concepts/workloads/_index.md +++ b/content/ja/docs/concepts/workloads/_index.md @@ -18,7 +18,7 @@ Podには定義されたライフサイクルがあります。たとえば、 * [Deployment](/ja/docs/concepts/workloads/controllers/deployment/)と[ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)(レガシーなリソース{{< glossary_tooltip text="ReplicationController" term_id="replication-controller" >}}を置き換えるものです) * [StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/) * [DaemonSet](/ja/docs/concepts/workloads/controllers/daemonset/)(ストレージドライバやネットワークプラグインなど、ノードローカルな機能を提供するためのPodを実行するために使われます) -* [Job](/docs/concepts/workloads/controllers/job/)と[CronJob](/ja/docs/concepts/workloads/controllers/cron-jobs/)(実行後に完了するようなタスクのために使われます) +* [Job](/ja/docs/concepts/workloads/controllers/job/)と[CronJob](/ja/docs/concepts/workloads/controllers/cron-jobs/)(実行後に完了するようなタスクのために使われます) 多少関連のある2種類の補助的な概念もあります。 * [ガベージコレクション](/ja/docs/concepts/workloads/controllers/garbage-collection/)は、オブジェクトが _所有するリソース_ が削除された後に、そのオブジェクトをクラスターからクリーンアップします。 diff --git a/content/ja/docs/concepts/workloads/controllers/cron-jobs.md b/content/ja/docs/concepts/workloads/controllers/cron-jobs.md index d03a8bf259b2a..fa6025f8866f1 100644 --- a/content/ja/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ja/docs/concepts/workloads/controllers/cron-jobs.md @@ -66,4 +66,4 @@ CronJobはスケジュールに一致するJobの作成にのみ関与するの [Cron表現形式](https://en.wikipedia.org/wiki/Cron)では、CronJobの`schedule`フィールドのフォーマットを説明しています。 -cronジョブの作成や動作の説明、CronJobマニフェストの例については、[Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs)を見てください。 +cronジョブの作成や動作の説明、CronJobマニフェストの例については、[Running automated tasks with cron jobs](/ja/docs/tasks/job/automated-tasks-with-cron-jobs)を見てください。 diff --git a/content/ja/docs/concepts/workloads/controllers/statefulset.md b/content/ja/docs/concepts/workloads/controllers/statefulset.md index 48aa86f68bc43..13e12e409a770 100644 --- a/content/ja/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ja/docs/concepts/workloads/controllers/statefulset.md @@ -142,7 +142,7 @@ Cluster Domain | Service (ns/name) | StatefulSet (ns/name) | StatefulSet Domain ### 安定したストレージ -Kubernetesは各VolumeClaimTemplateに対して、1つの[PersistentVolume](/docs/concepts/storage/persistent-volumes/)を作成します。上記のnginxの例において、各Podは`my-storage-class`というStorageClassをもち、1GiBのストレージ容量を持った単一のPersistentVolumeを受け取ります。もしStorageClassが指定されていない場合、デフォルトのStorageClassが使用されます。PodがNode上にスケジュール(もしくは再スケジュール)されたとき、その`volumeMounts`はPersistentVolume Claimに関連したPersistentVolumeをマウントします。 +Kubernetesは各VolumeClaimTemplateに対して、1つの[PersistentVolume](/ja/docs/concepts/storage/persistent-volumes/)を作成します。上記のnginxの例において、各Podは`my-storage-class`というStorageClassをもち、1GiBのストレージ容量を持った単一のPersistentVolumeを受け取ります。もしStorageClassが指定されていない場合、デフォルトのStorageClassが使用されます。PodがNode上にスケジュール(もしくは再スケジュール)されたとき、その`volumeMounts`はPersistentVolume Claimに関連したPersistentVolumeをマウントします。 注意点として、PodのPersistentVolume Claimと関連したPersistentVolumeは、PodやStatefulSetが削除されたときに削除されません。 削除する場合は手動で行わなければなりません。 diff --git a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md index 728e0346fea2b..9db98d0bf6791 100644 --- a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -12,7 +12,7 @@ weight: 70 TTLコントローラーは実行を終えたリソースオブジェクトのライフタイムを制御するためのTTL (time to live) メカニズムを提供します。 TTLコントローラーは現在{{< glossary_tooltip text="Job" term_id="job" >}}のみ扱っていて、将来的にPodやカスタムリソースなど、他のリソースの実行終了を扱えるように拡張される予定です。 -α版の免責事項: この機能は現在α版の機能で、kube-apiserverとkube-controller-managerの[Feature Gate](/docs/reference/command-line-tools-reference/feature-gates/)の`TTLAfterFinished`を有効にすることで使用可能です。 +α版の免責事項: この機能は現在α版の機能で、kube-apiserverとkube-controller-managerの[Feature Gate](/ja/docs/reference/command-line-tools-reference/feature-gates/)の`TTLAfterFinished`を有効にすることで使用可能です。 diff --git a/content/ja/docs/concepts/workloads/pods/_index.md b/content/ja/docs/concepts/workloads/pods/_index.md index 887854d6bb8cc..f588ee1d55bef 100644 --- a/content/ja/docs/concepts/workloads/pods/_index.md +++ b/content/ja/docs/concepts/workloads/pods/_index.md @@ -164,7 +164,7 @@ Pod内のコンテナは、システムのhostnameがPodに設定した`name`と ## コンテナの特権モード -Linuxでは、Pod内のどんなコンテナも、`privileged`フラグをコンテナのspecの[security context](/docs/tasks/configure-pod-container/security-context/)に設定することで、特権モード(privileged mode)を有効にできます。これは、ネットワークスタックの操作やハードウェアデバイスへのアクセスなど、オペレーティングシステムの管理者の権限が必要なコンテナの場合に役に立ちます。 +Linuxでは、Pod内のどんなコンテナも、`privileged`フラグをコンテナのspecの[security context](/ja/docs/tasks/configure-pod-container/security-context/)に設定することで、特権モード(privileged mode)を有効にできます。これは、ネットワークスタックの操作やハードウェアデバイスへのアクセスなど、オペレーティングシステムの管理者の権限が必要なコンテナの場合に役に立ちます。 `WindowsHostProcessContainers`機能を有効にしたクラスターの場合、Pod仕様のsecurityContextに`windowsOptions.hostProcess`フラグを設定することで、[Windows HostProcess Pod](/docs/tasks/configure-pod-container/create-hostprocess-pod)を作成することが可能です。これらのPod内のすべてのコンテナは、Windows HostProcessコンテナとして実行する必要があります。HostProcess Podはホスト上で直接実行され、Linuxの特権コンテナで行われるような管理作業を行うのにも使用できます。 diff --git a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md index a975102d76207..ee130370a84c6 100644 --- a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md @@ -12,7 +12,7 @@ Podの実行中、kubeletはコンテナを再起動して、ある種の障害 Kubernetes APIでは、Podには仕様と実際のステータスの両方があります。Podオブジェクトのステータスは、[PodのCondition](#pod-conditions)のセットで構成されます。[カスタムのReadiness情報](#pod-readiness-gate)をPodのConditionデータに挿入することもできます。 -Podはその生存期間に1回だけ[スケジューリング](/docs/concepts/scheduling-eviction/)されます。PodがNodeにスケジュール(割り当て)されると、Podは停止または[終了](#pod-termination)するまでそのNode上で実行されます。 +Podはその生存期間に1回だけ[スケジューリング](/ja/docs/concepts/scheduling-eviction/)されます。PodがNodeにスケジュール(割り当て)されると、Podは停止または[終了](#pod-termination)するまでそのNode上で実行されます。 diff --git a/content/ja/docs/contribute/_index.md b/content/ja/docs/contribute/_index.md index 24a1051db8d88..2baa69a751776 100644 --- a/content/ja/docs/contribute/_index.md +++ b/content/ja/docs/contribute/_index.md @@ -23,7 +23,7 @@ Kubernetesへの貢献について総合的に知りたい場合は、[contribut --- -このウェブサイトは[Kubernetes SIG Docs](/docs/contribute/#get-involved-with-sig-docs)が管理しています。 +このウェブサイトは[Kubernetes SIG Docs](/ja/docs/contribute/#get-involved-with-sig-docs)が管理しています。 Kubernetesドキュメントコントリビューターは @@ -133,9 +133,9 @@ class first,second white - 貢献のための複数の方法について学ぶために[貢献の概要](/ja/docs/contribute/new-content/)を読んでください。 - 良い開始地点を探すために[`kubernetes/website` issueリスト](https://github.com/kubernetes/website/issues/)を確認してください。 - 既存のドキュメントに対して[GitHubを使ってプルリクエストをオープン](/docs/contribute/new-content/open-a-pr/#changes-using-github)し、GitHubへのissueの登録について学んでください。 -- 正確さと言語の校正のため、他のKubernetesコミュニティメンバーから[プルリクエストのレビュー](/docs/contribute/review/reviewing-prs/)を受けてください。 +- 正確さと言語の校正のため、他のKubernetesコミュニティメンバーから[プルリクエストのレビュー](/ja/docs/contribute/review/reviewing-prs/)を受けてください。 - 見識のあるコメントを残せるようにするため、Kubernetesの[コンテンツ](/ja/docs/contribute/style/content-guide/)と[スタイルガイド](/docs/contribute/style/style-guide/)を読んでください。 -- [ページコンテンツの種類](/docs/contribute/style/page-content-types/)と[Hugoショートコード](/docs/contribute/style/hugo-shortcodes/)について勉強してください。 +- [ページコンテンツの種類](/docs/contribute/style/page-content-types/)と[Hugoショートコード](/ja/docs/contribute/style/hugo-shortcodes/)について勉強してください。 ## 貢献時の支援の受け方 @@ -160,7 +160,7 @@ SIG Docsは複数の方法でコミュニケーションをとっています。 ## その他の貢献方法 -- [Kubernetesコミュニティサイト](/community/)を訪問してください。TwitterやStack Overflowに参加したり、Kubernetesの集会やイベントについて学んだりしてください。 +- [Kubernetesコミュニティサイト](/ja/community/)を訪問してください。TwitterやStack Overflowに参加したり、Kubernetesの集会やイベントについて学んだりしてください。 - 機能開発に貢献したい方は、まずはじめに[Kubernetesコントリビューターチートシート](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet)を読んでください。 - [Kubernetesの貢献者](https://www.kubernetes.dev/)や[追加の貢献者向けリソース](https://www.kubernetes.dev/resources/)についてもっと学ぶために、貢献者サイトを読んでください。 - [ブログ記事やケーススタディ](/docs/contribute/new-content/blogs-case-studies/)を投稿してください。 diff --git a/content/ja/docs/contribute/localization.md b/content/ja/docs/contribute/localization.md index c97e48d52242c..401006e732ea2 100644 --- a/content/ja/docs/contribute/localization.md +++ b/content/ja/docs/contribute/localization.md @@ -139,4 +139,4 @@ cron「の」ジョブは、「の」が続く事による解釈の難から基 ## アップストリームのコントリビューター -SIG Docsでは、英語のソースに対する[アップストリームへのコントリビュートや誤りの訂正](/docs/contribute/intermediate#localize-content)を歓迎しています。 +SIG Docsでは、英語のソースに対する[アップストリームへのコントリビュートや誤りの訂正](/ja/docs/contribute/intermediate#localize-content)を歓迎しています。 diff --git a/content/ja/docs/contribute/new-content/_index.md b/content/ja/docs/contribute/new-content/_index.md index 8088f8ec861e4..6d681e80b78f0 100644 --- a/content/ja/docs/contribute/new-content/_index.md +++ b/content/ja/docs/contribute/new-content/_index.md @@ -52,10 +52,10 @@ class first,second white - Kubernetesのドキュメントは、Markdownのスタイルとして[CommonMark](https://commonmark.org)を使用しています。 - ソースは[GitHub](https://github.com/kubernetes/website)にあります。Kubernetesのドキュメントは`/content/en/docs/`にあります。リファレンスドキュメントの一部は、`update-imported-docs/`ディレクトリ内のスクリプトから自動的に生成されます。 - [Page content types](/docs/contribute/style/page-content-types/)にHugoによるドキュメントのコンテンツの見え方を記述しています。 -- Kubernetesのドキュメントに貢献するのに[Docsy shortcode](https://www.docsy.dev/docs/adding-content/shortcodes/)や[カスタムのHugo shortcode](/docs/contribute/style/hugo-shortcodes/)が使えます。 -- 標準のHugoのshortcodeに加えて、多数の[カスタムのHugo shortcode](/docs/contribute/style/hugo-shortcodes/)を使用してコンテンツの見え方をコントロールしています。 +- Kubernetesのドキュメントに貢献するのに[Docsy shortcode](https://www.docsy.dev/docs/adding-content/shortcodes/)や[カスタムのHugo shortcode](/ja/docs/contribute/style/hugo-shortcodes/)が使えます。 +- 標準のHugoのshortcodeに加えて、多数の[カスタムのHugo shortcode](/ja/docs/contribute/style/hugo-shortcodes/)を使用してコンテンツの見え方をコントロールしています。 - ドキュメントのソースは`/content/`内にある複数の言語で利用できます。各言語はそれぞれ[ISO 639-1標準](https://www.loc.gov/standards/iso639-2/php/code_list.php)で定義された2文字のコードの名前のフォルダを持ちます。たとえば、英語のドキュメントのソースは`/content/en/docs/`内に置かれています。 -- 複数言語でのドキュメントへの貢献や新しい翻訳の開始に関する情報については、[Kubernetesのドキュメントを翻訳する](/docs/contribute/localization)を参照してください。 +- 複数言語でのドキュメントへの貢献や新しい翻訳の開始に関する情報については、[Kubernetesのドキュメントを翻訳する](/ja/docs/contribute/localization)を参照してください。 ## 始める前に {#before-you-begin} @@ -73,7 +73,7 @@ pull requestをオープンするときは、どのブランチをベースに :---------|:------------ 現在のリリースに対する既存または新しい英語のコンテンツ | `main` 機能変更のリリースに対するコンテンツ | 機能変更が含まれるメジャーおよびマイナーバージョンに対応する、`dev-`というパターンのブランチを使います。たとえば、機能変更が`v{{< skew nextMinorVersion >}}`に含まれる場合、ドキュメントの変更は``dev-{{< skew nextMinorVersion >}}``ブランチに追加します。 -他の言語内のコンテンツ(翻訳) | 各翻訳対象の言語のルールに従います。詳しい情報は、[翻訳のブランチ戦略](/docs/contribute/localization/#branching-strategy)を読んでください。 +他の言語内のコンテンツ(翻訳) | 各翻訳対象の言語のルールに従います。詳しい情報は、[翻訳のブランチ戦略](/ja/docs/contribute/localization/#branching-strategy)を読んでください。 それでも選ぶべきブランチがわからないときは、Slack上の`#sig-docs`チャンネルで質問してください。 diff --git a/content/ja/docs/contribute/participate/_index.md b/content/ja/docs/contribute/participate/_index.md index a6ee9c8eeb8fe..b72df745a0e21 100644 --- a/content/ja/docs/contribute/participate/_index.md +++ b/content/ja/docs/contribute/participate/_index.md @@ -97,6 +97,6 @@ Pull Requestがコンテンツの公開に使用されるブランチにマー Kubernetesドキュメントへの貢献の詳細については、以下を参照してください： -- [Contributing new content](/docs/contribute/new-content/overview/) -- [Reviewing content](/docs/contribute/review/reviewing-prs) +- [Contributing new content](/ja/docs/contribute/new-content/overview/) +- [Reviewing content](/ja/docs/contribute/review/reviewing-prs) - [ドキュメントスタイルの概要](/ja/docs/contribute/style/) diff --git a/content/ja/docs/contribute/review/for-approvers.md b/content/ja/docs/contribute/review/for-approvers.md index 822396fbf67ea..9f72fa3ff8341 100644 --- a/content/ja/docs/contribute/review/for-approvers.md +++ b/content/ja/docs/contribute/review/for-approvers.md @@ -141,7 +141,7 @@ SIG Docsでは、対処方法をドキュメントに書いても良いくらい ### Blogに関するissue -[Kubernetes Blog](/blog/)のエントリーは時間が経つと情報が古くなるものだと考えています。そのため、ブログのエントリーは1年以内のものだけをメンテナンスします。1年以上前のブログエントリーに関するissueは修正せずにcloseします。 +[Kubernetes Blog](/ja/blog/)のエントリーは時間が経つと情報が古くなるものだと考えています。そのため、ブログのエントリーは1年以内のものだけをメンテナンスします。1年以上前のブログエントリーに関するissueは修正せずにcloseします。 ### サポートリクエストまたはコードのバグレポート {#support-requests-or-code-bug-reports} diff --git a/content/ja/docs/contribute/review/reviewing-prs.md b/content/ja/docs/contribute/review/reviewing-prs.md index a77ce8930b121..d6cbebabc4ac0 100644 --- a/content/ja/docs/contribute/review/reviewing-prs.md +++ b/content/ja/docs/contribute/review/reviewing-prs.md @@ -13,7 +13,7 @@ weight: 10 レビューを行う前には、以下のことを理解しておくとよいでしょう。 -- [コンテンツガイド](/docs/contribute/style/content-guide/)と[スタイルガイド](/docs/contribute/style/style-guide/)を読んで、有益なコメントを残せるようにする。 +- [コンテンツガイド](/ja/docs/contribute/style/content-guide/)と[スタイルガイド](/docs/contribute/style/style-guide/)を読んで、有益なコメントを残せるようにする。 - Kubernetesのドキュメントコミュニティにおける[役割と責任](/docs/contribute/participate/roles-and-responsibilities/)の違いを理解する。 @@ -70,7 +70,7 @@ class third,fourth white 2. open状態のPRに、以下に示すラベルを1つ以上使って絞り込みます。 - - `cncf-cla: yes` (推奨): CLAにサインしていないコントリビューターが提出したPRはマージできません。詳しい情報は、[CLAの署名](/docs/contribute/new-content/#sign-the-cla)を読んでください。 + - `cncf-cla: yes` (推奨): CLAにサインしていないコントリビューターが提出したPRはマージできません。詳しい情報は、[CLAの署名](/ja/docs/contribute/new-content/#sign-the-cla)を読んでください。 - `language/en` (推奨): 英語のPRだけに絞り込みます。 - `size/`: 特定の大きさのPRだけに絞り込みます。レビューを始めたばかりの人は、小さなPRから始めてください。 @@ -119,7 +119,7 @@ class third,fourth white - PRは新しいページを作成するものですか？ その場合、次の点に注意してください。 - ページは正しい[page content type](/docs/contribute/style/page-content-types/)と関係するHugoのshortcodeを使用していますか？ - セクションの横のナビゲーションにページは正しく表示されますか(または表示されませんか)？ - - ページは[Docs Home](/docs/home/)に一覧されますか？ + - ページは[Docs Home](/ja/docs/home/)に一覧されますか？ - Netlifyのプレビューで変更は確認できますか？ 特にリスト、コードブロック、テーブル、備考、画像などに注意してください。 ### その他 diff --git a/content/ja/docs/contribute/style/content-guide.md b/content/ja/docs/contribute/style/content-guide.md index 4161d1c489044..ad204b9f6afdd 100644 --- a/content/ja/docs/contribute/style/content-guide.md +++ b/content/ja/docs/contribute/style/content-guide.md @@ -37,7 +37,7 @@ Kubernetesのドキュメントには、Kubernetesプロジェクト([kubernetes Kubernetesプロジェクト内のアクティブなコンテンツへのリンクは常に許可されます。 -Kubernetesを機能させるためには、一部サードパーティーのコンテンツが必要です。たとえば、コンテナランタイム(containerd、CRI-O、Docker)、[ネットワークポリシー](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)(CNI plugin)、[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers/)、[ロギング](/docs/concepts/cluster-administration/logging/)などです。 +Kubernetesを機能させるためには、一部サードパーティーのコンテンツが必要です。たとえば、コンテナランタイム(containerd、CRI-O、Docker)、[ネットワークポリシー](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)(CNI plugin)、[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers/)、[ロギング](/ja/docs/concepts/cluster-administration/logging/)などです。 ドキュメント内で、Kubernetesプロジェクト外のサードパーティーのオープンソースソフトウェア(OSS)にリンクすることができるのは、Kubernetesを機能させるために必要な場合のみです。 diff --git a/content/ja/docs/contribute/style/content-organization.md b/content/ja/docs/contribute/style/content-organization.md index c69b66404ef45..f327472506c4b 100644 --- a/content/ja/docs/contribute/style/content-organization.md +++ b/content/ja/docs/contribute/style/content-organization.md @@ -83,7 +83,7 @@ toc_hide: true スタンドアローンのコンテンツページ(Markdownファイル)に加えて、Hugoでは、[Page Bundles](https://gohugo.io/content-management/page-bundles/)がサポートされています。 -Page Bundleの1つの例は、[カスタムのHugo Shortcode](/docs/contribute/style/hugo-shortcodes/)です。これは、`leaf bundle`であると見做されます。ディレクトリ内のすべてのファイルは、`index.md`を含めてバンドルの一部となります。これには、ページからの相対リンク、処理可能な画像なども含まれます。 +Page Bundleの1つの例は、[カスタムのHugo Shortcode](/ja/docs/contribute/style/hugo-shortcodes/)です。これは、`leaf bundle`であると見做されます。ディレクトリ内のすべてのファイルは、`index.md`を含めてバンドルの一部となります。これには、ページからの相対リンク、処理可能な画像なども含まれます。 ```bash en/docs/home/contribute/includes @@ -118,6 +118,6 @@ en/includes ## {{% heading "whatsnext" %}} -* [カスタムのHugo shortcode](/docs/contribute/style/hugo-shortcodes/)について学ぶ +* [カスタムのHugo shortcode](/ja/docs/contribute/style/hugo-shortcodes/)について学ぶ * [スタイルガイド](/docs/contribute/style/style-guide)について学ぶ -* [コンテンツガイド](/docs/contribute/style/content-guide)について学ぶ +* [コンテンツガイド](/ja/docs/contribute/style/content-guide)について学ぶ diff --git a/content/ja/docs/home/supported-doc-versions.md b/content/ja/docs/home/supported-doc-versions.md index 2ed4821b3a767..4cbe56e1cd5b0 100644 --- a/content/ja/docs/home/supported-doc-versions.md +++ b/content/ja/docs/home/supported-doc-versions.md @@ -11,4 +11,4 @@ card: 本ウェブサイトには、現行版とその直前4バージョンのKubernetesドキュメントがあります。 Kubernetesバージョンのドキュメントの入手性は、そのリリースが現在サポートされているかどうかで分かれます。 -どのKubernetesバージョンが公式にどのくらいの期間サポートされるかについて知るには、[サポート期間](/releases/patch-releases/#support-period)を参照してください。 +どのKubernetesバージョンが公式にどのくらいの期間サポートされるかについて知るには、[サポート期間](/ja/releases/patch-releases/#support-period)を参照してください。 diff --git a/content/ja/docs/reference/_index.md b/content/ja/docs/reference/_index.md index 798a5166bcd6a..21d398640ad91 100644 --- a/content/ja/docs/reference/_index.md +++ b/content/ja/docs/reference/_index.md @@ -17,7 +17,7 @@ no_list: true * [標準化用語集](/ja/docs/reference/glossary) - Kubernetesの用語の包括的で標準化されたリストです。 -* [Kubernetes APIリファレンス](/docs/reference/using-api/) +* [Kubernetes APIリファレンス](/ja/docs/reference/using-api/) * [Kubernetes {{< param "version" >}}の単一ページのAPIリファレンス](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) * [Kubernetes APIの使用](/ja/docs/reference/using-api/) - KubernetesのAPIの概要です。 * [API アクセスコントロール](/docs/reference/access-authn-authz/) - KubernetesがAPIアクセスをどのように制御するかの詳細です。 diff --git a/content/ja/docs/reference/command-line-tools-reference/feature-gates/index.md b/content/ja/docs/reference/command-line-tools-reference/feature-gates/index.md index d833d8def5e7c..c067e3cca098a 100644 --- a/content/ja/docs/reference/command-line-tools-reference/feature-gates/index.md +++ b/content/ja/docs/reference/command-line-tools-reference/feature-gates/index.md @@ -356,12 +356,12 @@ GAになってからさらなる変更を加えることは現実的ではない - `ContainerCheckpoint`: kubeletチェックポイントAPIを有効にします。詳細は[KubeletチェックポイントAPI](/ja/docs/reference/node/kubelet-checkpoint-api/)で確認できます。 - `AttachVolumeLimit`: ボリュームプラグインを有効にすることでノードにアタッチできるボリューム数の制限を設定できます。 - `BalanceAttachedNodeVolumes`: スケジューリング中にバランスのとれたリソース割り当てを考慮するノードのボリュームカウントを含めます。判断を行う際に、CPU、メモリー使用率、およびボリュームカウントが近いノードがスケジューラーによって優先されます。 -- `BlockVolume`: PodでRawブロックデバイスの定義と使用を有効にします。詳細は[Rawブロックボリュームのサポート](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)で確認できます。 +- `BlockVolume`: PodでRawブロックデバイスの定義と使用を有効にします。詳細は[Rawブロックボリュームのサポート](/ja/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)で確認できます。 - `BoundServiceAccountTokenVolume`: ServiceAccountTokenVolumeProjectionによって構成される計画ボリュームを使用するにはServiceAccountボリュームを移行します。詳細は[Service Account Token Volumes](https://git.k8s.io/community/contributors/design-proposals/storage/svcacct-token-volume-source.md)で確認できます。 -- `ConfigurableFSGroupPolicy`: Podにボリュームをマウントするときに、ユーザーがfsGroupsのボリューム権限変更ポリシーを設定できるようにします。詳細については、[Podのボリューム権限と所有権変更ポリシーの設定](/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods)をご覧ください。 +- `ConfigurableFSGroupPolicy`: Podにボリュームをマウントするときに、ユーザーがfsGroupsのボリューム権限変更ポリシーを設定できるようにします。詳細については、[Podのボリューム権限と所有権変更ポリシーの設定](/ja/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods)をご覧ください。 - `CPUManager`: コンテナレベルのCPUアフィニティサポートを有効します。[CPUマネジメントポリシー](/docs/tasks/administer-cluster/cpu-management-policies/)を見てください。 - `CRIContainerLogRotation`: criコンテナランタイムのコンテナログローテーションを有効にします。 -- `CSIBlockVolume`: 外部CSIボリュームドライバーを有効にしてブロックストレージをサポートします。詳細は[`csi`Rawブロックボリュームのサポート](/docs/concepts/storage/volumes/#csi-raw-block-volume-support)で確認できます。 +- `CSIBlockVolume`: 外部CSIボリュームドライバーを有効にしてブロックストレージをサポートします。詳細は[`csi`Rawブロックボリュームのサポート](/ja/docs/concepts/storage/volumes/#csi-raw-block-volume-support)で確認できます。 - `CSIDriverRegistry`: csi.storage.k8s.ioのCSIDriver APIオブジェクトに関連するすべてのロジックを有効にします。 - `CSIInlineVolume`: PodのCSIインラインボリュームサポートを有効にします。 - `CSIMigration`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のプラグインから対応した事前インストール済みのCSIプラグインにルーティングします。 @@ -377,59 +377,59 @@ GAになってからさらなる変更を加えることは現実的ではない - `CSIMigrationOpenStackComplete`: Cinderのツリー内プラグインのkubeletおよびボリュームコントローラーへの登録を停止し、シムと変換ロジックがCinderのツリー内プラグインからCinder CSIプラグインにボリューム操作をルーティングできるようにします。CSIMigrationおよびCSIMigrationOpenStack機能フラグを有効にし、クラスター内のすべてのノードにCinder CSIプラグインをインストールおよび設定する必要があります。 - `CSINodeInfo`: csi.storage.k8s.ioのCSINodeInfo APIオブジェクトに関連するすべてのロジックを有効にします。 - `CSIPersistentVolume`: [CSI(Container Storage Interface)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)互換のボリュームプラグインを通してプロビジョニングされたボリュームの検出とマウントを有効にします。 - 詳細については[`csi`ボリュームタイプ](/docs/concepts/storage/volumes/#csi)ドキュメントを確認してください。 + 詳細については[`csi`ボリュームタイプ](/ja/docs/concepts/storage/volumes/#csi)ドキュメントを確認してください。 - `CustomCPUCFSQuotaPeriod`: ノードがCPUCFSQuotaPeriodを変更できるようにします。 - `CustomPodDNS`: `dnsConfig`プロパティを使用したPodのDNS設定のカスタマイズを有効にします。詳細は[PodのDNS構成](/ja/docs/concepts/services-networking/dns-pod-service/#pods-dns-config)で確認できます。 - `CustomResourceDefaulting`: OpenAPI v3バリデーションスキーマにおいて、デフォルト値のCRDサポートを有効にします。 - `CustomResourcePublishOpenAPI`: CRDのOpenAPI仕様での公開を有効にします。 -- `CustomResourceSubresources`: [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)から作成されたリソースの`/status`および`/scale`サブリソースを有効にします。 -- `CustomResourceValidation`: [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)から作成されたリソースのスキーマによる検証を有効にします。 -- `CustomResourceWebhookConversion`: [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)から作成されたリソースのWebhookベースの変換を有効にします。 +- `CustomResourceSubresources`: [CustomResourceDefinition](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)から作成されたリソースの`/status`および`/scale`サブリソースを有効にします。 +- `CustomResourceValidation`: [CustomResourceDefinition](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)から作成されたリソースのスキーマによる検証を有効にします。 +- `CustomResourceWebhookConversion`: [CustomResourceDefinition](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)から作成されたリソースのWebhookベースの変換を有効にします。 - `DevicePlugins`: [device-plugins](/docs/concepts/cluster-administration/device-plugins/)によるノードでのリソースプロビジョニングを有効にします。 - `DryRun`: サーバーサイドでの[dry run](/docs/reference/using-api/api-concepts/#dry-run)リクエストを有効にします。 -- `DynamicKubeletConfig`: kubeletの動的構成を有効にします。[kubeletの再設定](/docs/tasks/administer-cluster/reconfigure-kubelet/)を参照してください。 +- `DynamicKubeletConfig`: kubeletの動的構成を有効にします。[kubeletの再設定](/ja/docs/tasks/administer-cluster/reconfigure-kubelet/)を参照してください。 - `DynamicProvisioningScheduling`: デフォルトのスケジューラーを拡張してボリュームトポロジーを認識しPVプロビジョニングを処理します。この機能は、v1.12の`VolumeScheduling`機能に完全に置き換えられました。 - `DynamicVolumeProvisioning`(*非推奨*): Podへの永続ボリュームの[動的プロビジョニング](/ja/docs/concepts/storage/dynamic-provisioning/)を有効にします。 - `EnableAggregatedDiscoveryTimeout` (*非推奨*): 集約されたディスカバリーコールで5秒のタイムアウトを有効にします。 - `EnableEquivalenceClassCache`: Podをスケジュールするときにスケジューラーがノードの同等をキャッシュできるようにします。 - `EphemeralContainers`: 稼働するPodに{{< glossary_tooltip text="ephemeral containers" term_id="ephemeral-container" >}}を追加する機能を有効にします。 -- `EvenPodsSpread`: Podをトポロジードメイン全体で均等にスケジュールできるようにします。[Even Pods Spread](/docs/concepts/configuration/even-pods-spread)をご覧ください。 -- `ExpandInUsePersistentVolumes`: 使用中のPVCのボリューム拡張を有効にします。[使用中のPersistentVolumeClaimのサイズ変更](/docs/concepts/storage/persistent-volumes/#resizing-an-in-use-persistentvolumeclaim)を参照してください。 -- `ExpandPersistentVolumes`: 永続ボリュームの拡張を有効にします。[永続ボリューム要求の拡張](/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims)を参照してください。 +- `EvenPodsSpread`: Podをトポロジードメイン全体で均等にスケジュールできるようにします。[Even Pods Spread](/ja/docs/concepts/configuration/even-pods-spread)をご覧ください。 +- `ExpandInUsePersistentVolumes`: 使用中のPVCのボリューム拡張を有効にします。[使用中のPersistentVolumeClaimのサイズ変更](/ja/docs/concepts/storage/persistent-volumes/#resizing-an-in-use-persistentvolumeclaim)を参照してください。 +- `ExpandPersistentVolumes`: 永続ボリュームの拡張を有効にします。[永続ボリューム要求の拡張](/ja/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims)を参照してください。 - `ExperimentalCriticalPodAnnotation`: [スケジューリングが保証されるよう](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)に特定のPodへの *クリティカル* の注釈を加える設定を有効にします。 - `ExperimentalHostUserNamespaceDefaultingGate`: ホストするデフォルトのユーザー名前空間を有効にします。これは他のホストの名前空間やホストのマウントを使用しているコンテナ、特権を持つコンテナ、または名前空間のない特定の機能（たとえば`MKNODE`、`SYS_MODULE`など）を使用しているコンテナ用です。これはDockerデーモンでユーザー名前空間の再マッピングが有効になっている場合にのみ有効にすべきです。 -- `EndpointSlice`: よりスケーラブルで拡張可能なネットワークエンドポイントのエンドポイントスライスを有効にします。[Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpointslices/)をご覧ください。 -- `EndpointSliceProxying`: このフィーチャーゲートを有効にすると、kube-proxyはエンドポイントの代わりにエンドポイントスライスをプライマリデータソースとして使用し、スケーラビリティとパフォーマンスの向上を実現します。[Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpointslices/).をご覧ください。 +- `EndpointSlice`: よりスケーラブルで拡張可能なネットワークエンドポイントのエンドポイントスライスを有効にします。[Enabling Endpoint Slices](/ja/docs/tasks/administer-cluster/enabling-endpointslices/)をご覧ください。 +- `EndpointSliceProxying`: このフィーチャーゲートを有効にすると、kube-proxyはエンドポイントの代わりにエンドポイントスライスをプライマリデータソースとして使用し、スケーラビリティとパフォーマンスの向上を実現します。[Enabling Endpoint Slices](/ja/docs/tasks/administer-cluster/enabling-endpointslices/).をご覧ください。 - `GCERegionalPersistentDisk`: GCEでリージョナルPD機能を有効にします。 - `HugePages`: 事前に割り当てられた[huge pages](/ja/docs/tasks/manage-hugepages/scheduling-hugepages/)の割り当てと消費を有効にします。 -- `HugePageStorageMediumSize`: 事前に割り当てられた複数のサイズの[huge pages](/docs/tasks/manage-hugepages/scheduling-hugepages/)のサポートを有効にします。 +- `HugePageStorageMediumSize`: 事前に割り当てられた複数のサイズの[huge pages](/ja/docs/tasks/manage-hugepages/scheduling-hugepages/)のサポートを有効にします。 - `HyperVContainer`: Windowsコンテナの[Hyper-Vによる分離](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container)を有効にします。 - `HPAScaleToZero`: カスタムメトリクスまたは外部メトリクスを使用するときに、`HorizontalPodAutoscaler`リソースの`minReplicas`を0に設定できるようにします。 - `ImmutableEphemeralVolumes`: 安全性とパフォーマンスを向上させるために、個々のSecretとConfigMapが不変となるように指定できるようにします。 - `KubeletConfigFile`: 設定ファイルを使用して指定されたファイルからのkubelet設定の読み込みを有効にします。詳細は[設定ファイルによるkubeletパラメーターの設定](/docs/tasks/administer-cluster/kubelet-config-file/)で確認できます。 -- `KubeletPluginsWatcher`: 調査ベースのプラグイン監視ユーティリティを有効にしてkubeletが[CSIボリュームドライバー](/docs/concepts/storage/volumes/#csi)などのプラグインを検出できるようにします。 +- `KubeletPluginsWatcher`: 調査ベースのプラグイン監視ユーティリティを有効にしてkubeletが[CSIボリュームドライバー](/ja/docs/concepts/storage/volumes/#csi)などのプラグインを検出できるようにします。 - `KubeletPodResources`: kubeletのPodのリソースgrpcエンドポイントを有効にします。詳細は[デバイスモニタリングのサポート](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/compute-device-assignment.md)で確認できます。 - `LegacyNodeRoleBehavior`: 無効にすると、サービスロードバランサーの従来の動作とノードの中断により機能固有のラベルが優先され、`node-role.kubernetes.io/master`ラベルが無視されます。 -- `LocalStorageCapacityIsolation`: [ローカルの一時ストレージ](/docs/concepts/configuration/manage-resources-containers/)の消費を有効にして、[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)の`sizeLimit`プロパティも有効にします。 -- `LocalStorageCapacityIsolationFSQuotaMonitoring`: `LocalStorageCapacityIsolation`が[ローカルの一時ストレージ](/docs/concepts/configuration/manage-resources-containers/)で有効になっていて、[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)のbacking filesystemがプロジェクトクォータをサポートし有効になっている場合、プロジェクトクォータを使用して、パフォーマンスと精度を向上させるために、ファイルシステムへのアクセスではなく[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)ストレージ消費を監視します。 +- `LocalStorageCapacityIsolation`: [ローカルの一時ストレージ](/ja/docs/concepts/configuration/manage-resources-containers/)の消費を有効にして、[emptyDirボリューム](/ja/docs/concepts/storage/volumes/#emptydir)の`sizeLimit`プロパティも有効にします。 +- `LocalStorageCapacityIsolationFSQuotaMonitoring`: `LocalStorageCapacityIsolation`が[ローカルの一時ストレージ](/ja/docs/concepts/configuration/manage-resources-containers/)で有効になっていて、[emptyDirボリューム](/ja/docs/concepts/storage/volumes/#emptydir)のbacking filesystemがプロジェクトクォータをサポートし有効になっている場合、プロジェクトクォータを使用して、パフォーマンスと精度を向上させるために、ファイルシステムへのアクセスではなく[emptyDirボリューム](/ja/docs/concepts/storage/volumes/#emptydir)ストレージ消費を監視します。 - `MountContainers`: ホスト上のユーティリティコンテナをボリュームマウンターとして使用できるようにします。 -- `MountPropagation`: あるコンテナによってマウントされたボリュームを他のコンテナまたはPodに共有できるようにします。詳細は[マウントの伝播](/docs/concepts/storage/volumes/#mount-propagation)で確認できます。 +- `MountPropagation`: あるコンテナによってマウントされたボリュームを他のコンテナまたはPodに共有できるようにします。詳細は[マウントの伝播](/ja/docs/concepts/storage/volumes/#mount-propagation)で確認できます。 - `NodeDisruptionExclusion`: ノードラベル`node.kubernetes.io/exclude-disruption`の使用を有効にします。これにより、ゾーン障害時にノードが退避するのを防ぎます。 - `NodeLease`: 新しいLease APIを有効にしてノードヘルスシグナルとして使用できるノードのハートビートをレポートします。 - `NonPreemptingPriority`: PriorityClassとPodのNonPreemptingオプションを有効にします。 - `PersistentLocalVolumes`: Podで`local`ボリュームタイプの使用を有効にします。`local`ボリュームを要求する場合、Podアフィニティを指定する必要があります。 -- `PodOverhead`: [PodOverhead](/docs/concepts/configuration/pod-overhead/)機能を有効にして、Podのオーバーヘッドを考慮するようにします。 +- `PodOverhead`: [PodOverhead](/ja/docs/concepts/configuration/pod-overhead/)機能を有効にして、Podのオーバーヘッドを考慮するようにします。 - `PodDisruptionBudget`: [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/)機能を有効にします。 -- `PodPriority`: [優先度](/docs/concepts/configuration/pod-priority-preemption/)に基づいてPodの再スケジューリングとプリエンプションを有効にします。 +- `PodPriority`: [優先度](/ja/docs/concepts/configuration/pod-priority-preemption/)に基づいてPodの再スケジューリングとプリエンプションを有効にします。 - `PodReadinessGates`: Podのreadinessの評価を拡張するために`PodReadinessGate`フィールドの設定を有効にします。詳細は[Pod readiness gate](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)で確認できます。 - `PodShareProcessNamespace`: Podで実行されているコンテナ間で単一のプロセス名前空間を共有するには、Podで`shareProcessNamespace`の設定を有効にします。詳細については、[Pod内のコンテナ間でプロセス名前空間を共有する](/ja/docs/tasks/configure-pod-container/share-process-namespace/)をご覧ください。 - `ProcMountType`: コンテナのProcMountTypeの制御を有効にします。 -- `PVCProtection`: 永続ボリューム要求（PVC）がPodでまだ使用されているときに削除されないようにします。詳細は[ここ](/docs/tasks/administer-cluster/storage-object-in-use-protection/)で確認できます。 +- `PVCProtection`: 永続ボリューム要求（PVC）がPodでまだ使用されているときに削除されないようにします。詳細は[ここ](/ja/docs/tasks/administer-cluster/storage-object-in-use-protection/)で確認できます。 - `QOSReserved`: QoSレベルでのリソース予約を許可して、低いQoSレベルのポッドが高いQoSレベルで要求されたリソースにバーストするのを防ぎます（現時点ではメモリのみ）。 - `ResourceLimitsPriorityFunction`: 入力したPodのCPU制限とメモリ制限の少なくとも1つを満たすノードに対して最低スコアを1に割り当てるスケジューラー優先機能を有効にします。その目的は同じスコアを持つノード間の関係を断つことです。 - `ResourceQuotaScopeSelectors`: リソース割当のスコープセレクターを有効にします。 -- `RotateKubeletClientCertificate`: kubeletでクライアントTLS証明書のローテーションを有効にします。詳細は[kubeletの設定](/docs/tasks/administer-cluster/storage-object-in-use-protection/)で確認できます。 -- `RotateKubeletServerCertificate`: kubeletでサーバーTLS証明書のローテーションを有効にします。詳細は[kubeletの設定](/docs/tasks/administer-cluster/storage-object-in-use-protection/)で確認できます。 +- `RotateKubeletClientCertificate`: kubeletでクライアントTLS証明書のローテーションを有効にします。詳細は[kubeletの設定](/ja/docs/tasks/administer-cluster/storage-object-in-use-protection/)で確認できます。 +- `RotateKubeletServerCertificate`: kubeletでサーバーTLS証明書のローテーションを有効にします。詳細は[kubeletの設定](/ja/docs/tasks/administer-cluster/storage-object-in-use-protection/)で確認できます。 - `RunAsGroup`: コンテナの初期化プロセスで設定されたプライマリグループIDの制御を有効にします。 - `RuntimeClass`: コンテナのランタイム構成を選択するには[RuntimeClass](/ja/docs/concepts/containers/runtime-class/)機能を有効にします。 - `ScheduleDaemonSetPods`: DaemonSetのPodをDaemonSetコントローラーではなく、デフォルトのスケジューラーによってスケジュールされるようにします。 @@ -447,13 +447,13 @@ GAになってからさらなる変更を加えることは現実的ではない - `SupportIPVSProxyMode`: IPVSを使用したクラスター内サービスの負荷分散の提供を有効にします。詳細は[サービスプロキシー](/ja/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)で確認できます。 - `SupportPodPidsLimit`: PodのPID制限のサポートを有効にします。 - `Sysctls`: 各Podに設定できる名前空間付きのカーネルパラメーター(sysctl)のサポートを有効にします。詳細は[sysctls](/docs/tasks/administer-cluster/sysctl-cluster/)で確認できます。 -- `TaintBasedEvictions`: ノードのTaintとPodのTolerationに基づいてノードからPodを排除できるようにします。。詳細は[TaintとToleration](/docs/concepts/scheduling-eviction/taint-and-toleration/)で確認できます。 +- `TaintBasedEvictions`: ノードのTaintとPodのTolerationに基づいてノードからPodを排除できるようにします。。詳細は[TaintとToleration](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)で確認できます。 - `TaintNodesByCondition`: [ノードの条件](/ja/docs/concepts/architecture/nodes/#condition)に基づいてノードの自動Taintを有効にします。 - `TokenRequest`: サービスアカウントリソースで`TokenRequest`エンドポイントを有効にします。 -- `TokenRequestProjection`: [Projectedボリューム](/docs/concepts/storage/volumes/#projected)を使用したPodへのサービスアカウントのトークンの注入を有効にします。 +- `TokenRequestProjection`: [Projectedボリューム](/ja/docs/concepts/storage/volumes/#projected)を使用したPodへのサービスアカウントのトークンの注入を有効にします。 - `TTLAfterFinished`: [TTLコントローラー](/ja/docs/concepts/workloads/controllers/ttlafterfinished/)が実行終了後にリソースをクリーンアップできるようにします。 - `VolumePVCDataSource`: 既存のPVCをデータソースとして指定するサポートを有効にします。 -- `VolumeScheduling`: ボリュームトポロジー対応のスケジューリングを有効にし、PersistentVolumeClaim（PVC）バインディングにスケジューリングの決定を認識させます。また`PersistentLocalVolumes`フィーチャーゲートと一緒に使用すると[`local`](/docs/concepts/storage/volumes/#local)ボリュームタイプの使用が可能になります。 +- `VolumeScheduling`: ボリュームトポロジー対応のスケジューリングを有効にし、PersistentVolumeClaim（PVC）バインディングにスケジューリングの決定を認識させます。また`PersistentLocalVolumes`フィーチャーゲートと一緒に使用すると[`local`](/ja/docs/concepts/storage/volumes/#local)ボリュームタイプの使用が可能になります。 - `VolumeSnapshotDataSource`: ボリュームスナップショットのデータソースサポートを有効にします。 - `VolumeSubpathEnvExpansion`: 環境変数を`subPath`に展開するための`subPathExpr`フィールドを有効にします。 - `WatchBookmark`: ブックマークイベントの監視サポートを有効にします。 diff --git a/content/ja/docs/reference/glossary/csi.md b/content/ja/docs/reference/glossary/csi.md index f3dfd24442752..ef723d30f5c43 100644 --- a/content/ja/docs/reference/glossary/csi.md +++ b/content/ja/docs/reference/glossary/csi.md @@ -17,5 +17,5 @@ tags: CSIはベンダーがKubernetesリポジトリにコードを追加することなく(Kubernetesリポジトリツリー外のプラグインとして)独自のストレージプラグインを作成することを可能にします。CSIドライバをストレージプロバイダから利用するには、はじめに[クラスターにCSIプラグインをデプロイする](https://kubernetes-csi.github.io/docs/deploying.html)必要があります。その後のCSIドライバーを使用するための{{< glossary_tooltip text="StorageClass" term_id="storage-class" >}}を作成することができます。 -* [KubernetesにおけるCSIのドキュメント](/docs/concepts/storage/volumes/#csi) +* [KubernetesにおけるCSIのドキュメント](/ja/docs/concepts/storage/volumes/#csi) * [利用可能なCSIドライバの一覧](https://kubernetes-csi.github.io/docs/drivers.html) diff --git a/content/ja/docs/reference/kubectl/cheatsheet.md b/content/ja/docs/reference/kubectl/cheatsheet.md index c9bbb56ba4de2..2ab826f309559 100644 --- a/content/ja/docs/reference/kubectl/cheatsheet.md +++ b/content/ja/docs/reference/kubectl/cheatsheet.md @@ -349,7 +349,7 @@ kubectl api-resources --api-group=extensions # "extensions" APIグループの `-o=custom-columns-file=` | ``ファイル内のカスタムカラムテンプレートを使用してテーブルを表示します `-o=json` | JSON形式のAPIオブジェクトを出力します `-o=jsonpath=