Term "interface" variations fix

Author: tamilselvan1102

content/ja/blog/_posts/2022-02-17-updated-dockershim-faq.md

@@ -36,7 +36,7 @@ Kubernetesの初期のバージョンは、特定のコンテナランタイム
 Docker Engineです。その後、Kubernetesは他のコンテナランタイムと連携するためのサポートを追加しました。
 オーケストレーター(Kubernetesなど)と多くの異なるコンテナランタイムの間の相互運用を可能にするため、
 CRI標準が[作成](/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)されました。
-Docker Engineはそのインターフェイス(CRI)を実装していないため、Kubernetesプロジェクトは移行を支援する特別なコードを作成し、
+Docker Engineはそのインターフェース(CRI)を実装していないため、Kubernetesプロジェクトは移行を支援する特別なコードを作成し、
 その _dockershim_ コードをKubernetes自身の一部としました。
 
 dockershimコードは常に一時的な解決策であることを意図されていました(このためshimと名付けられています)。

content/ja/docs/concepts/_index.md

@@ -15,7 +15,7 @@ weight: 40
 
 ## 概要
 
-Kubernetesを機能させるには、*Kubernetes API オブジェクト* を使用して、実行したいアプリケーションやその他のワークロード、使用するコンテナイメージ、レプリカ(複製)の数、どんなネットワークやディスクリソースを利用可能にするかなど、クラスターの *desired state* (望ましい状態)を記述します。desired state (望ましい状態)をセットするには、Kubernetes APIを使用してオブジェクトを作成します。通常はコマンドラインインターフェイス `kubectl` を用いてKubernetes APIを操作しますが、Kubernetes APIを直接使用してクラスターと対話し、desired state (望ましい状態)を設定、または変更することもできます。
+Kubernetesを機能させるには、*Kubernetes API オブジェクト* を使用して、実行したいアプリケーションやその他のワークロード、使用するコンテナイメージ、レプリカ(複製)の数、どんなネットワークやディスクリソースを利用可能にするかなど、クラスターの *desired state* (望ましい状態)を記述します。desired state (望ましい状態)をセットするには、Kubernetes APIを使用してオブジェクトを作成します。通常はコマンドラインインターフェース `kubectl` を用いてKubernetes APIを操作しますが、Kubernetes APIを直接使用してクラスターと対話し、desired state (望ましい状態)を設定、または変更することもできます。
 
 一旦desired state (望ましい状態)を設定すると、Pod Lifecycle Event Generator([PLEG](https://.com/kubernetes/design-proposals-archive/blob/main/node/pod-lifecycle-event-generator.md))を使用した*Kubernetes コントロールプレーン*が機能し、クラスターの現在の状態をdesired state (望ましい状態)に一致させます。そのためにKubernetesはさまざまなタスク(たとえば、コンテナの起動または再起動、特定アプリケーションのレプリカ数のスケーリング等)を自動的に実行します。Kubernetesコントロールプレーンは、クラスターで実行されている以下のプロセスで構成されています。
 
@@ -51,7 +51,7 @@ Kubernetesマスターや kubeletプロセスといったKubernetesコントロ
 
 ### Kubernetesマスター
 
-Kubernetesのマスターは、クラスターの望ましい状態を維持する責務を持ちます。`kubectl` コマンドラインインターフェイスを使用するなどしてKubernetesとやり取りするとき、ユーザーは実際にはクラスターにあるKubernetesのマスターと通信しています。
+Kubernetesのマスターは、クラスターの望ましい状態を維持する責務を持ちます。`kubectl` コマンドラインインターフェースを使用するなどしてKubernetesとやり取りするとき、ユーザーは実際にはクラスターにあるKubernetesのマスターと通信しています。
 
 「マスター」とは、クラスター状態を管理するプロセスの集合を指します。通常これらのプロセスは、すべてクラスター内の単一ノードで実行されます。このノードはマスターとも呼ばれます。マスターは、可用性と冗長性のために複製することもできます。
 

content/ja/docs/concepts/architecture/cri.md

@@ -1,12 +1,12 @@
 ---
-title: コンテナランタイムインターフェイス(CRI)
+title: コンテナランタイムインターフェース(CRI)
 content_type: concept
 weight: 60
 ---
 
 <!-- overview -->
 
-CRIは、クラスターコンポーネントを再コンパイルすることなく、kubeletがさまざまなコンテナランタイムを使用できるようにするプラグインインターフェイスです。
+CRIは、クラスターコンポーネントを再コンパイルすることなく、kubeletがさまざまなコンテナランタイムを使用できるようにするプラグインインターフェースです。
 
 {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}が{{< glossary_tooltip text="Pod" term_id="pod" >}}とそのコンテナを起動できるように、クラスター内の各ノードで動作する{{<glossary_tooltip text="container runtime" term_id="container-runtime">}}が必要です。
 

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

@@ -25,7 +25,7 @@ weight: 120
 * [Contiv](https://contivpp.io/)は、さまざまなユースケースと豊富なポリシーフレームワーク向けに設定可能なネットワーク(BGPを使用したネイティブのL3、vxlanを使用したオーバーレイ、古典的なL2、Cisco-SDN/ACI)を提供します。Contivプロジェクトは完全に[オープンソース](https://.com/contiv)です。[インストーラー](https://.com/contiv/install)はkubeadmとkubeadm以外の両方をベースとしたインストールオプションがあります。
 * [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)は、[Tungsten Fabric](https://tungsten.io)をベースにしている、オープンソースでマルチクラウドに対応したネットワーク仮想化およびポリシー管理プラットフォームです。ContrailおよびTungsten Fabricは、Kubernetes、OpenShift、OpenStack、Mesosなどのオーケストレーションシステムと統合されており、仮想マシン、コンテナ/Pod、ベアメタルのワークロードに隔離モードを提供します。
 * [Flannel](https://.com/flannel-io/flannel#deploying-flannel-manually)は、Kubernetesで使用できるオーバーレイネットワークプロバイダーです。
-* [Knitter](https://.com/ZTE/Knitter/)は、1つのKubernetes Podで複数のネットワークインターフェイスをサポートするためのプラグインです。
+* [Knitter](https://.com/ZTE/Knitter/)は、1つのKubernetes Podで複数のネットワークインターフェースをサポートするためのプラグインです。
 * [Multus](https://.com/k8snetworkplumbingwg/multus-cni)は、すべてのCNIプラグイン(たとえば、Calico、Cilium、Contiv、Flannel)に加えて、SRIOV、DPDK、OVS-DPDK、VPPをベースとするKubernetes上のワークロードをサポートする、複数のネットワークサポートのためのマルチプラグインです。
 * [OVN-Kubernetes](https://.com/ovn-org/ovn-kubernetes/)は、Open vSwitch(OVS)プロジェクトから生まれた仮想ネットワーク実装である[OVN(Open Virtual Network)](https://.com/ovn-org/ovn/)をベースとする、Kubernetesのためのネットワークプロバイダーです。OVN-Kubernetesは、OVSベースのロードバランサーおよびネットワークポリシーの実装を含む、Kubernetes向けのオーバーレイベースのネットワーク実装を提供します。
 * [Nodus](https://.com/akraino-edge-stack/icn-nodus)は、OVNベースのCNIコントローラープラグインで、クラウドネイティブベースのService function chaining(SFC)を提供します。
@@ -40,7 +40,7 @@ weight: 120
 
 ## 可視化と制御 {#visualization-amp-control}
 
-* [Dasard](https://.com/kubernetes/dasard#kubernetes-dasard)はKubernetes向けのダッシュボードを提供するウェブインターフェイスです。
+* [Dasard](https://.com/kubernetes/dasard#kubernetes-dasard)はKubernetes向けのダッシュボードを提供するウェブインターフェースです。
 * [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s)は、コンテナ、Pod、Serviceなどをグラフィカルに可視化するツールです。[Weave Cloud account](https://cloud.weave.works/)と組み合わせて使うか、UIを自分でホストして使います。
 
 ## インフラストラクチャ {#infrastructure}

content/ja/docs/concepts/overview/components.md

@@ -106,7 +106,7 @@ Kubernetesによって開始されたコンテナは、DNS検索にこのDNSサ
 
 ### クラスターレベルのロギング
 
-[クラスターレベルのロギング](/ja/docs/concepts/cluster-administration/logging/)メカニズムは、コンテナのログを、検索／参照インターフェイスを備えた中央ログストアに保存します。
+[クラスターレベルのロギング](/ja/docs/concepts/cluster-administration/logging/)メカニズムは、コンテナのログを、検索／参照インターフェースを備えた中央ログストアに保存します。
 
 
 ## {{% heading "whatsnext" %}}

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

@@ -60,7 +60,7 @@ kubectl get pods -l run=my-nginx -o yaml | grep podIP
 コンテナはノードでポート80を使用**していない**ことに注意してください。
 また、Podにトラフィックをルーティングする特別なNATルールもありません。
 つまり、同じcontainerPortを使用して同じノードで複数のnginx Podを実行し、IPを使用してクラスター内の他のPodやノードからそれらにアクセスできます。
-Dockerと同様に、ポートは引き続きホストノードのインターフェイスに公開できますが、ネットワークモデルにより、この必要性は根本的に減少します。
+Dockerと同様に、ポートは引き続きホストノードのインターフェースに公開できますが、ネットワークモデルにより、この必要性は根本的に減少します。
 
 興味があれば、これを[どのように達成するか](/ja/docs/concepts/cluster-administration/networking/#how-to-achieve-this)について詳しく読むことができます。
 

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

@@ -24,14 +24,14 @@ KubernetesクラスターでIPv4/IPv6デュアルスタックを有効にする
 
 * デュアルスタックのPodネットワーク(PodごとにIPv4とIPv6のアドレスが1つずつ割り当てられます)
 * IPv4およびIPv6が有効化されたService(各Serviceは1つのアドレスファミリーでなければなりません)
-* IPv4およびIPv6インターフェイスを経由したPodのクラスター外向きの(たとえば、インターネットへの)ルーティング
+* IPv4およびIPv6インターフェースを経由したPodのクラスター外向きの(たとえば、インターネットへの)ルーティング
 
 ## 前提条件
 
 IPv4/IPv6デュアルスタックのKubernetesクラスターを利用するには、以下の前提条件を満たす必要があります。
 
 * Kubernetesのバージョンが1.16以降である
-* プロバイダーがデュアルスタックのネットワークをサポートしている(クラウドプロバイダーなどが、ルーティング可能なIPv4/IPv6ネットワークインターフェイスが搭載されたKubernetesを提供可能である)
+* プロバイダーがデュアルスタックのネットワークをサポートしている(クラウドプロバイダーなどが、ルーティング可能なIPv4/IPv6ネットワークインターフェースが搭載されたKubernetesを提供可能である)
 * ネットワークプラグインがデュアルスタックに対応している(KubenetやCalicoなど)
 
 ## IPv4/IPv6デュアルスタックを有効にする

content/ja/docs/concepts/storage/volumes.md

@@ -1001,7 +1001,7 @@ CSIとFlexVolumeはどちらも、ボリュームプラグインをKubernetesコ
 
 ### csi
 
-[Container Storage Interface](https://.com/container-storage-interface/spec/blob/master/spec.md)(CSI)は、コンテナオーケストレーションシステム(Kubernetesなど)の標準インターフェイスを定義して、任意のストレージシステムをコンテナワークロードに公開します。
+[Container Storage Interface](https://.com/container-storage-interface/spec/blob/master/spec.md)(CSI)は、コンテナオーケストレーションシステム(Kubernetesなど)の標準インターフェースを定義して、任意のストレージシステムをコンテナワークロードに公開します。
 
 詳細については[CSI design proposal](https://.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)を参照してください。
 

content/ja/docs/reference/glossary/control-plane.md

@@ -4,13 +4,13 @@ id: control-plane
 date: 2019-05-12
 full_link:
 short_description: >
-コンテナのライフサイクルを定義、展開、管理するためのAPIとインターフェイスを公開するコンテナオーケストレーションレイヤーです。
+コンテナのライフサイクルを定義、展開、管理するためのAPIとインターフェースを公開するコンテナオーケストレーションレイヤーです。
 
 aka:
 tags:
 - fundamental
 ---
-コンテナのライフサイクルを定義、展開、管理するためのAPIとインターフェイスを公開するコンテナオーケストレーションレイヤーです。
+コンテナのライフサイクルを定義、展開、管理するためのAPIとインターフェースを公開するコンテナオーケストレーションレイヤーです。
 
 <!--more-->
 

content/ja/docs/reference/glossary/csi.md

@@ -1,17 +1,17 @@
 ---
-title: コンテナストレージインターフェイス(CSI)
+title: コンテナストレージインターフェース(CSI)
 id: csi
 date: 2018-06-25
 full_link: /docs/concepts/storage/volumes/#csi
 short_description: >
-コンテナストレージインターフェイス(CSI)はストレージシステムをコンテナに公開するための標準インターフェイスを定義します。
+コンテナストレージインターフェース(CSI)はストレージシステムをコンテナに公開するための標準インターフェースを定義します。
 
 
 aka:
 tags:
 - storage
 ---
-コンテナストレージインターフェイス(CSI)はストレージシステムをコンテナに公開するための標準インターフェイスを定義します。
+コンテナストレージインターフェース(CSI)はストレージシステムをコンテナに公開するための標準インターフェースを定義します。
 
 <!--more-->
 

content/ja/docs/reference/node/kubelet-checkpoint-api.md

@@ -26,7 +26,7 @@ weight: 10
 
 指定したPodから指定したコンテナのチェックポイントを作成するようにkubeletに指示します。
 
-kubeletチェックポイントインターフェイスへのアクセスの制御方法についての詳細な情報は、[Kubelet authentication/authorization reference](/docs/reference/access-authn-authz/kubelet-authn-authz)を参照してください。
+kubeletチェックポイントインターフェースへのアクセスの制御方法についての詳細な情報は、[Kubelet authentication/authorization reference](/docs/reference/access-authn-authz/kubelet-authn-authz)を参照してください。
 
 kubeletは基礎となる{{<glossary_tooltip term_id="cri" text="CRI">}}実装にチェックポイントをリクエストします。
 チェックポイントリクエストでは、kubeletが`checkpoint-<podFullName>-<containerName>-<timestamp>.tar`のようなチェックポイントアーカイブの名前を指定します。

content/ja/docs/reference/tools.md

@@ -17,7 +17,7 @@ Kubernetesには、Kubernetesシステムの操作に役立ついくつかの組
 [`minikube`](https://minikube.sigs.k8s.io/docs/)は、開発やテストのためにワークステーション上でシングルノードのKubernetesクラスターをローカルで実行するツールです。
 
 ## Dasard
-[`Dasard`](/ja/docs/tasks/access-application-cluster/web-ui-dasard/)は、KubernetesのWebベースのユーザインタフェースで、コンテナ化されたアプリケーションをKubernetesクラスターにデプロイしたり、トラブルシューティングしたり、クラスターとそのリソース自体を管理したりすることが出来ます。
+[`Dasard`](/ja/docs/tasks/access-application-cluster/web-ui-dasard/)は、KubernetesのWebベースのユーザインターフェースで、コンテナ化されたアプリケーションをKubernetesクラスターにデプロイしたり、トラブルシューティングしたり、クラスターとそのリソース自体を管理したりすることが出来ます。
 
 ## Helm
 [`Kubernetes Helm`](https://.com/helm/helm)は、事前に設定されたKubernetesリソースのパッケージ、別名Kubernetes chartsを管理するためのツールです。

content/ja/docs/setup/production-environment/container-runtimes.md

@@ -93,7 +93,7 @@ cgroupとインターフェースするために、kubeletおよびコンテナ
 ### cgroupfsドライバー {#cgroupfs-cgroup-driver}
 
 `cgroupfs`ドライバーは、kubeletのデフォルトのcgroupドライバーです。
-`cgroupfs`ドライバーを使用すると、kubeletとコンテナランタイムはcgroupファイルシステムと直接インターフェイスし、cgroupを設定します。
+`cgroupfs`ドライバーを使用すると、kubeletとコンテナランタイムはcgroupファイルシステムと直接インターフェースし、cgroupを設定します。
 
 [systemd](https://www.freedesktop.org/wiki/Software/systemd/)がinitシステムである場合、`cgroupfs`ドライバーは推奨**されません**。
 なぜなら、systemdはシステム上のcgroupマネージャーが単一であると想定しているからです。