commit first work from 1.19 milestone

2021-05-26 10:10:10 +00:00
parent 6866260642
commit 73b3cf8784
134 changed files with 4305 additions and 2983 deletions
@@ -122,6 +122,29 @@ spec:
 A(AAAA)レコードはPodの名前に対して作成されないため、`hostname`はPodのA(AAAA)レコードが作成されるために必須となります。`hostname`を持たないが`subdomain`を持つようなPodは、そのPodのIPアドレスを指し示すHeadless Service(`default-subdomain.my-namespace.svc.cluster.local`)に対するA(AAAA)レコードのみ作成します。
 {{< /note >}}

+### PodのsetHostnameAsFQDNフィールド
+
+{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
+
+**前提条件**: {{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}に対して`SetHostnameAsFQDN`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にする必要があります。
+
+Podが完全修飾ドメイン名(FQDN)を持つように構成されている場合、そのホスト名は短いホスト名です。
+例えば、FQDNが`busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example`のPodがある場合、
+デフォルトではそのPod内の`hostname`コマンドは`busybox-1`を返し、`hostname --fqdn`コマンドはFQDNを返します。
+
+Podのspecで`setHostnameAsFQDN: true`を設定した場合、そのPodの名前空間に対してkubeletはPodのFQDNをホスト名に書き込みます。
+この場合、`hostname`と`hostname --fqdn`の両方がPodのFQDNを返します。
+
+{{< note >}}
+Linuxでは、カーネルのホスト名のフィールド(`struct utsname`の`nodename`フィールド)は64文字に制限されています。
+
+Podがこの機能を有効にしていて、そのFQDNが64文字より長い場合、Podは起動に失敗します。
+Podは`Pending`ステータス(`kubectl`でみられる`ContainerCreating`)のままになり、「Podのホスト名とクラスタードメインからFQDNを作成できなかった」や、「FQDN`long-FQDN`が長すぎる(64文字が最大, 70文字が要求された)」などのエラーイベントが生成されます。
+
+このシナリオのユーザー体験を向上させる1つの方法は、[admission webhook controller](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)を作成して、ユーザーがDeploymentなどのトップレベルのオブジェクトを作成するときにFQDNのサイズを制御することです。
+{{< /note >}}
+
+
 ### PodのDNSポリシー

 DNSポリシーはPod毎に設定できます。現在のKubernetesでは次のようなPod固有のDNSポリシーをサポートしています。これらのポリシーはPod Specの`dnsPolicy`フィールドで指定されます。
@@ -40,6 +40,7 @@ IPv4/IPv6デュアルスタックを有効にするには、クラスターの

   * kube-apiserver:
      * `--feature-gates="IPv6DualStack=true"`
+      * `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>
   * kube-controller-manager:
      * `--feature-gates="IPv6DualStack=true"`
      * `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
@@ -89,7 +90,7 @@ IPv6が有効になった外部ロードバランサーをサポートしてい

 ## 外向きのトラフィック {#egress-traffic}

-パブリックおよび非パブリックでのルーティングが可能なIPv6アドレスのブロックを利用するためには、クラスターがベースにしている{{< glossary_tooltip text="CNI" term_id="cni" >}}プロバイダーがIPv6の転送を実装している必要があります。もし非パブリックでのルーティングが可能なIPv6アドレスを使用するPodがあり、そのPodをクラスター外の送信先(例:パブリックインターネット)に到達させたい場合、外向きのトラフィックと応答の受信のためにIPマスカレードを設定する必要があります。[ip-masq-agent](https://github.com/kubernetes-incubator/ip-masq-agent)はデュアルスタックに対応しているため、デュアルスタックのクラスター上でのIPマスカレードにはip-masq-agentが利用できます。
+パブリックおよび非パブリックでのルーティングが可能なIPv6アドレスのブロックを利用するためには、クラスターがベースにしている{{< glossary_tooltip text="CNI" term_id="cni" >}}プロバイダーがIPv6の転送を実装している必要があります。もし非パブリックでのルーティングが可能なIPv6アドレスを使用するPodがあり、そのPodをクラスター外の送信先(例:パブリックインターネット)に到達させたい場合、外向きのトラフィックと応答の受信のためにIPマスカレードを設定する必要があります。[ip-masq-agent](https://github.com/kubernetes-sigs/ip-masq-agent)はデュアルスタックに対応しているため、デュアルスタックのクラスター上でのIPマスカレードにはip-masq-agentが利用できます。

 ## 既知の問題

@@ -1,7 +1,7 @@
 ---
 title: EndpointSlice
 content_type: concept
-weight: 15
+weight: 35
 ---

 <!-- overview -->
@@ -14,13 +14,19 @@ weight: 15

 ## 動機

-Endpoints APIはKubernetes内のネットワークエンドポイントを追跡する単純で直観的な手段を提供してきました。残念ながら、KubernetesクラスターやServiceが大規模になるにつれて、Endpoints APIの限界が明らかになってきました。最も顕著な問題の1つに、ネットワークエンドポイントの数が大きくなったときのスケーリングの問題があります。
+Endpoint APIはKubernetes内のネットワークエンドポイントを追跡する単純で直観的な手段を提供してきました。
+残念ながら、Kubernetesクラスターや{{< glossary_tooltip text="Service" term_id="service" >}}が大規模になり、より多くのトラフィックを処理し、より多くのバックエンドPodに送信するようになるにしたがって、Endpoint APIの限界が明らかになってきました。
+最も顕著な問題の1つに、ネットワークエンドポイントの数が大きくなったときのスケーリングの問題があります。

-Serviceのすべてのネットワークエンドポイントが単一のEndpointsリソースに格納されていたため、リソースのサイズが非常に大きくなる場合がありました。これがKubernetesのコンポーネント(特に、マスターコントロールプレーン)の性能に悪影響を与え、結果として、Endpointsに変更があるたびに、大量のネットワークトラフィックと処理が発生するようになってしまいました。EndpointSliceは、この問題を緩和するとともに、トポロジカルルーティングなどの追加機能のための拡張可能なプラットフォームを提供します。
+Serviceのすべてのネットワークエンドポイントが単一のEndpointリソースに格納されていたため、リソースのサイズが非常に大きくなる場合がありました。これがKubernetesのコンポーネント(特に、マスターコントロールプレーン)の性能に悪影響を与え、結果として、Endpointに変更があるたびに、大量のネットワークトラフィックと処理が発生するようになってしまいました。EndpointSliceは、この問題を緩和するとともに、トポロジカルルーティングなどの追加機能のための拡張可能なプラットフォームを提供します。

 ## EndpointSliceリソース {#endpointslice-resource}

-Kubernetes内ではEndpointSliceにはネットワークエンドポイントの集合へのリファレンスが含まれます。EndpointSliceコントローラーは、{{< glossary_tooltip text="セレクター" term_id="selector" >}}が指定されると、Kubernetes Serviceに対するEndpointSliceを自動的に作成します。これらのEndpointSliceにはServiceセレクターに一致する任意のPodへのリファレクンスが含まれます。EndpointSliceはネットワークエンドポイントをユニークなServiceとPortの組み合わせでグループ化します。EndpointSliceオブジェクトの名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。
+Kubernetes内ではEndpointSliceにはネットワークエンドポイントの集合へのリファレンスが含まれます。
+コントロールプレーンは、{{< glossary_tooltip text = "セレクター" term_id = "selector" >}}が指定されているKubernetes ServiceのEndpointSliceを自動的に作成します。
+これらのEndpointSliceには、Serviceセレクターに一致するすべてのPodへのリファレンスが含まれています。
+EndpointSliceは、プロトコル、ポート番号、およびサービス名の一意の組み合わせによってネットワークエンドポイントをグループ化します。
+EndpointSliceオブジェクトの名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。

 一例として、以下に`example`というKubernetes Serviceに対するサンプルのEndpointSliceリソースを示します。

@@ -47,9 +53,9 @@ endpoints:
      topology.kubernetes.io/zone: us-west2-a
 ```

-デフォルトではEndpointSliceコントローラーが管理するEndpointSliceには、1つにつき最大で100個のエンドポイントしか所属しません。この規模以下であれば、EndpointSliceはEndpointとServiceが1対1対応になり、性能は変わらないはずです。
+デフォルトでは、コントロールプレーンはEndpointSliceを作成・管理し、それぞれのエンドポイント数が100以下になるようにします。`--max-endpoints-per-slice`{{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}フラグを設定することで、最大1000個まで設定可能です。

-EndpointSliceは内部トラフィックのルーティング方法に関して、kube-proxyに対する唯一のソース(source of truth)として振る舞うことができます。EndpointSliceを有効にすれば、非常に多数のエンドポイントを持つServiceに対して性能向上が得られるはずです。
+EndpointSliceは内部トラフィックのルーティング方法に関して、{{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}に対する唯一のソース(source of truth)として振る舞うことができます。EndpointSliceを有効にすれば、非常に多数のエンドポイントを持つServiceに対して性能向上が得られるはずです。

 ### アドレスの種類

@@ -59,9 +65,10 @@ EndpointSliceは次の3種類のアドレスをサポートします。
 * IPv6
 * FQDN (Fully Qualified Domain Name、完全修飾ドメイン名)

-### トポロジー
+### トポロジー {#topology}

-EndpointSliceに属する各エンドポイントは、関連するトポロジーの情報を持つことができます。この情報は、エンドポイントの場所を示すために使われ、対応するNode、ゾーン、リージョンに関する情報が含まれます。値が利用できる場合にはEndpointSliceコントローラーによって次のようなTopologyラベルが設定されます。
+EndpointSliceに属する各エンドポイントは、関連するトポロジーの情報を持つことができます。この情報は、エンドポイントの場所を示すために使われ、対応するNode、ゾーン、リージョンに関する情報が含まれます。
+値が利用できる場合には、コントロールプレーンはEndpointSliceコントローラーに次のようなTopologyラベルを設定します。

 * `kubernetes.io/hostname` - このエンドポイントが存在するNodeの名前。
 * `topology.kubernetes.io/zone` - このエンドポイントが存在するゾーン。
@@ -71,25 +78,34 @@ EndpointSliceに属する各エンドポイントは、関連するトポロジ

 ### 管理

-EndpointSliceはデフォルトではEndpointSliceコントローラーによって作成・管理されます。EndpointSliceには他にもサービスメッシュの実装などのさまざまなユースケースがあるため、他のエンティティやコントローラーがEndpointSliceの追加の集合を管理する場合もあります。複数のエンティティが互いに干渉せずにEndpointSliceを管理できるようにするために、EndpointSliceを管理しているエンティティを表す`endpointslice.kubernetes.io/managed-by`ラベルが使用されます。EndpointSliceコントローラーの場合、管理対象のすべてのEndpointSliceに対して、このラベルの値として`endpointslice-controller.k8s.io`を設定します。EndpointSliceを管理するその他のエンティティも同様に、このラベルにユニークな値を設定する必要があります。
+ほとんどの場合、コントロールプレーン（具体的には、EndpointSlice {{< glossary_tooltip text = "コントローラー" term_id = "controller" >}}）は、EndpointSliceオブジェクトを作成および管理します。EndpointSliceには、サービスメッシュの実装など、他のさまざまなユースケースがあり、他のエンティティまたはコントローラーがEndpointSliceの追加セットを管理する可能性があります。
+
+複数のエンティティが互いに干渉することなくEndpointSliceを管理できるようにするために、KubernetesはEndpointSliceを管理するエンティティを示す`endpointslice.kubernetes.io/managed-by`という{{< glossary_tooltip term_id="label" text="ラベル" >}}を定義します。
+EndpointSliceを管理するその他のエンティティも同様に、このラベルにユニークな値を設定する必要があります。

 ### 所有権

-ほとんどのユースケースでは、EndpointSliceは対象のエンドポイントが追跡しているServiceによって所有されます。これは、各EndpointSlice上のownerリファレンスと`kubernetes.io/service-name`ラベルによって示されます。これにより、Serviceに属するすべてのEndpointSliceを簡単に検索できるようになっています。
+ほとんどのユースケースでは、EndpointSliceはエンドポイントスライスオブジェクトがエンドポイントを追跡するServiceによって所有されます。
+これは、各EndpointSlice上のownerリファレンスと`kubernetes.io/service-name`ラベルによって示されます。これにより、Serviceに属するすべてのEndpointSliceを簡単に検索できるようになっています。

-## EndpointSliceコントローラー
+### EndpointSliceのミラーリング

-EndpointSliceコントローラーは対応するEndpointSliceが最新の状態であることを保証するために、ServiceとPodを監視します。このコントローラーはセレクターが指定した各Serviceに対応するEndpointSliceを管理します。EndpointSliceはServiceセレクターに一致するPodのIPを表します。
+場合によっては、アプリケーションはカスタムEndpointリソースを作成します。これらのアプリケーションがEndpointリソースとEndpointSliceリソースの両方に同時に書き込む必要がないようにするために、クラスターのコントロールプレーンは、ほとんどのEndpointリソースを対応するEndpointSliceにミラーリングします。

-### EndpointSliceのサイズ
+コントロールプレーンは、次の場合を除いて、Endpointリソースをミラーリングします。

-デフォルトでは、それぞれのEndpointSliceのサイズの上限は100個のEndpointsに制限されています。この制限は{{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}に`--max-endpoints-per-slice`フラグを使用することで、最大で1000まで設定できます。
+* Endpointリソースの`endpointslice.kubernetes.io/skip-mirror`ラベルが`true`に設定されています。
+* Endpointリソースが`control-plane.alpha.kubernetes.io/leader`アノテーションを持っています。
+* 対応するServiceリソースが存在しません。
+* 対応するServiceリソースには、nil以外のセレクターがあります。
+
+個々のEndpointリソースは、複数のEndpointSliceに変換される場合があります。これは、Endpointリソースに複数のサブセットがある場合、または複数のIPファミリ（IPv4およびIPv6）を持つエンドポイントが含まれている場合に発生します。サブセットごとに最大1000個のアドレスがEndpointSliceにミラーリングされます。

 ### EndpointSliceの分散

-それぞれのEndpointSliceにはポートの集合があり、リソース内のすべてのエンドポイントに適用されます。サービスが名前付きポートを使用した場合、Podが同じ名前のポートに対して、結果的に異なるターゲットポート番号が使用されて、異なるEndpointSliceが必要になる場合があります。これはサービスの部分集合がEndpointsにグループ化される場合と同様です。
+それぞれのEndpointSliceにはポートの集合があり、リソース内のすべてのエンドポイントに適用されます。サービスが名前付きポートを使用した場合、Podが同じ名前のポートに対して、結果的に異なるターゲットポート番号が使用されて、異なるEndpointSliceが必要になる場合があります。これはサービスの部分集合がEndpointにグループ化される場合と同様です。

-コントローラーはEndpointSliceをできる限り充填しようとしますが、積極的にリバランスを行うことはありません。コントローラーのロジックは極めて単純で、以下のようになっています。
+コントロールプレーンはEndpointSliceをできる限り充填しようとしますが、積極的にリバランスを行うことはありません。コントローラーのロジックは極めて単純で、以下のようになっています。

 1. 既存のEndpointSliceをイテレートし、もう必要のないエンドポイントを削除し、変更があったエンドポイントを更新する。
 2. 前のステップで変更されたEndpointSliceをイテレートし、追加する必要がある新しいエンドポイントで充填する。
@@ -101,8 +117,16 @@ EndpointSliceコントローラーは対応するEndpointSliceが最新の状態

 現実的には、こうしたあまり理想的ではない分散が発生することは稀です。EndpointSliceコントローラーによって処理されるほとんどの変更は、既存のEndpointSliceに収まるほど十分小さくなるためです。そうでなかったとしても、すぐに新しいEndpointSliceが必要になる可能性が高いです。また、Deploymentのローリングアップデートが行われれば、自然な再充填が行われます。Podとそれに対応するエンドポイントがすべて置換されるためです。

+### エンドポイントの重複
+
+EndpointSliceの変更の性質上、エンドポイントは同時に複数のEndpointSliceで表される場合があります。
+これは、さまざまなEndpointSliceオブジェクトへの変更が、さまざまな時間にKubernetesクライアントのウォッチ/キャッシュに到達する可能性があるために自然に発生します。
+EndpointSliceを使用する実装では、エンドポイントを複数のスライスに表示できる必要があります。
+エンドポイント重複排除を実行する方法のリファレンス実装は、`kube-proxy`の`EndpointSliceCache`実装にあります。
+
+
 ## {{% heading "whatsnext" %}}

-* [EndpointSliceを有効にする](/docs/tasks/administer-cluster/enabling-endpointslices)
+* [EndpointSliceの有効化](/docs/tasks/administer-cluster/enabling-endpointslices)について学ぶ
 * [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を読む

@@ -11,47 +11,42 @@ Ingressリソースが動作するためには、クラスターでIngressコン

 `kube-controller-manager`バイナリの一部として実行される他のタイプのコントローラーとは異なり、Ingressコントローラーはクラスターで自動的に起動されません。このページを使用して、クラスターに最適なIngressコントローラーの実装を選択してください。

-プロジェクトとしてのKubernetesは現在、[GCE](https://git.k8s.io/ingress-gce/README.md)と[nginx](https://git.k8s.io/ingress-nginx/README.md)のコントローラーをサポートし、保守しています。
-
-
+プロジェクトとしてのKubernetesは現在、[AWS](https://github.com/kubernetes-sigs/aws-load-balancer-controller#readme)、[GCE](https://git.k8s.io/ingress-gce/README.md#readme)、および[nginx](https://git.k8s.io/ingress-nginx/README.md#readme)のIngressコントローラーをサポート・保守しています。

 <!-- body -->

 ## 追加のコントローラー {#additional-controllers}

-* [AKS Application Gateway Ingress Controller](https://github.com/Azure/application-gateway-kubernetes-ingress)は[Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview)を利用して[AKSクラスター](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal)でIngressを実行可能にするIngressコントローラーです。
-* [Ambassador](https://www.getambassador.io/) API Gatewayは[Envoy](https://www.envoyproxy.io)ベースのIngressコントローラーで、[Datawire](https://www.datawire.io/)による[コミュニティ版](https://www.getambassador.io/docs)または[商用版](https://www.getambassador.io/pro/)のサポートがあります。
-* [AppsCode Inc.](https://appscode.com)では、最も広く使用されている[HAProxy](https://www.haproxy.org/)ベースのIngressコントローラーである[Voyager](https://appscode.com/products/voyager)のサポートと保守を提供しています。
-* [AWS ALB Ingress Controller](https://github.com/kubernetes-sigs/aws-alb-ingress-controller)は[AWS Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/)を使用したIngressを有効にします。
-* [Contour](https://projectcontour.io/)は、VMwareが提供し、サポートしている[Envoy](https://www.envoyproxy.io/)ベースのIngressコントローラーです。
-* Citrixは、[ベアメタル](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal)と[クラウド](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment)のデプロイ用に、ハードウェア(MPX）、仮想化(VPX)、[フリーコンテナ化(CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html)用の[Ingressコントローラー](https://github.com/citrix/citrix-k8s-ingress-controller)を提供しています。
-* F5 Networksは[F5 BIG-IP Container Ingress Services for Kubernetes](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/)の[サポートと保守](https://support.f5.com/csp/article/K86859508)を提供しています。
-* [Gloo](https://gloo.solo.io)は[Envoy](https://www.envoyproxy.io)をベースにしたオープンソースのIngressコントローラーで、[solo.io](https://www.solo.io)からのエンタープライズサポートでAPI Gateway機能を提供しています。
-* [HAProxy Ingress](https://haproxy-ingress.github.io)は、HAProxy用の高度にカスタマイズ可能なコミュニティ主導のIngressコントローラーです。
-* [HAProxy Technologies](https://www.haproxy.com/)は[HAProxy Ingress Controller for Kubernetes](https://github.com/haproxytech/kubernetes-ingress)のサポートと保守を提供しています。[公式ドキュメント](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/)を参照してください。
-* [Istio](https://istio.io/)ベースのIngressコントローラー[Control Ingress Traffic](https://istio.io/docs/tasks/traffic-management/ingress/)。
-* [Kong](https://konghq.com/)は、[Kong Ingress Controller for Kubernetes](https://github.com/Kong/kubernetes-ingress-controller)の[コミュニティ版](https://discuss.konghq.com/c/kubernetes)と[商用版]](https://konghq.com/kong-enterprise/)のサポートと保守を提供しています。
-* [NGINX, Inc.](https://www.nginx.com/)は[NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)のサポートと保守を提供しています。
+{{% thirdparty-content %}}
+
+* [AKS Application Gateway Ingress Controller](https://github.com/Azure/application-gateway-kubernetes-ingress)は、[Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview)を設定するIngressコントローラーです。
+* [Ambassador](https://www.getambassador.io/) API Gatewayは[Envoy](https://www.envoyproxy.io)ベースのIngressコントローラーです。
+* [Citrix ingress controller](https://github.com/citrix/citrix-k8s-ingress-controller#readme)は、Citrix Application Delivery Controllerで動作します。
+* [Contour](https://projectcontour.io/)は、[Envoy](https://www.envoyproxy.io/)ベースのIngressコントローラーです。
+* F5 BIG-IPの[Container Ingress Services for Kubernetes](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/)はF5 BIG-IPの仮想サーバー上でIngressの設定を可能にします。
+* [Gloo](https://gloo.solo.io)は[Envoy](https://www.envoyproxy.io)をベースにしたオープンソースのIngressコントローラーで、API Gateway機能を提供しています。
+* [HAProxy Ingress](https://haproxy-ingress.github.io)は、[HAProxy](http://www.haproxy.org/#desc)用のIngressコントローラーです。
+* [HAProxy Ingress Controller for Kubernetes](https://github.com/haproxytech/kubernetes-ingress)も、[HAProxy](http://www.haproxy.org/#desc)用のIngressコントローラーです。
+* [Istio Ingress](https://istio.io/latest/docs/tasks/traffic-management/ingress/kubernetes-ingress/)は、[Istio](https://istio.io/)ベースのIngressコントローラーです。
+* [Kong Ingress Controller for Kubernetes](https://github.com/Kong/kubernetes-ingress-controller#readme)は、[Kong Gateway](https://konghq.com/kong/)向けのIngressコントローラーです。
+* [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)は、[NGINX](https://www.nginx.com/resources/glossary/nginx/)ウェブサーバーで(プロキシとして)動作します。
 * [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)は、カスタムプロキシーを構築するためのライブラリーとして設計された、Kubernetes Ingressなどのユースケースを含む、サービス構成用のHTTPルーターとリバースプロキシーです。
-* [Traefik](https://github.com/containous/traefik)はフル機能([Let's Encrypt](https://letsencrypt.org), secrets, http2, websocket)のIngressコントローラーで、[Containous](https://containo.us/services)による商用サポートもあります。
+* [Traefik Kubernetes Ingress provider](https://doc.traefik.io/traefik/providers/kubernetes-ingress/)は、[Traefik](https://github.com/containous/traefik) proxy向けのIngressコントローラーです。
+* [Voyager](https://appscode.com/products/voyager)は、[HAProxy](http://www.haproxy.org/#desc)向けのIngressコントローラーです。

 ## 複数のIngressコントローラーの使用 {#using-multiple-ingress-controllers}

-[Ingressコントローラーは、好きな数だけ](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers))クラスターにデプロイすることができます。Ingressを作成する際には、クラスター内に複数のIngressコントローラーが存在する場合にどのIngressコントローラーを使用するかを示すために適切な[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster)のアノテーションを指定します。
+[Ingressコントローラーは、好きな数だけ](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)クラスターにデプロイすることができます。Ingressを作成する際には、クラスター内に複数のIngressコントローラーが存在する場合にどのIngressコントローラーを使用するかを示すために適切な[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster)のアノテーションを指定する必要があります。

 クラスを定義しない場合、クラウドプロバイダーはデフォルトのIngressコントローラーを使用する場合があります。

 理想的には、すべてのIngressコントローラーはこの仕様を満たすべきですが、いくつかのIngressコントローラーはわずかに異なる動作をします。

-
 {{< note >}}
 Ingressコントローラーのドキュメントを確認して、選択する際の注意点を理解してください。
 {{< /note >}}

-
-
 ## {{% heading "whatsnext" %}}

-
-* [Ingress](/ja/docs/concepts/services-networking/ingress/)の詳細
-* [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube)
+* [Ingress](/ja/docs/concepts/services-networking/ingress/)についてさらに学ぶ。
+* [Minikube上でNGINX Ingressコントローラーを使用してIngressをセットアップする](/ja/docs/tasks/access-application-cluster/ingress-minikube)。
@@ -5,7 +5,7 @@ weight: 40
 ---

 <!-- overview -->
-{{< feature-state for_k8s_version="v1.1" state="beta" >}}
+{{< feature-state for_k8s_version="v1.19" state="stable" >}}
 {{< glossary_definition term_id="ingress" length="all" >}}


@@ -23,17 +23,28 @@ weight: 40

 ## Ingressとは何か

-[Ingress](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)はクラスター外からクラスター内{{< link text="Service" url="/ja/docs/concepts/services-networking/service/" >}}へのHTTPとHTTPSのルートを公開します。トラフィックのルーティングはIngressリソース上で定義されるルールによって制御されます。
+[Ingress](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1-networking-k8s-io)はクラスター外からクラスター内{{< link text="Service" url="/ja/docs/concepts/services-networking/service/" >}}へのHTTPとHTTPSのルートを公開します。トラフィックのルーティングはIngressリソース上で定義されるルールによって制御されます。

-```none
-    internet
-        |
-   [ Ingress ]
-   --|-----|--
-   [ Services ]
-```
+全てのトラフィックを単一のServiceに送る単純なIngressの例を示します。

-IngressはServiceに対して、外部疎通できるURL、負荷分散トラフィック、SSL/TLS終端の機能や、名前ベースの仮想ホスティングを提供するように設定できます。[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)は通常はロードバランサーを使用してIngressの機能を実現しますが、エッジルーターや、追加のフロントエンドを構成してトラフィックの処理を支援することもできます。
+{{< mermaid >}}
+graph LR;
+  client([クライアント])-. Ingress管理下の <br> ロードバランサー .->ingress[Ingress];
+  ingress-->|ルーティングルール|service[Service];
+  subgraph cluster[クラスター]
+  ingress;
+  service-->pod1[Pod];
+  service-->pod2[Pod];
+  end
+  classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+  classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+  classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+  class ingress,service,pod1,pod2 k8s;
+  class client plain;
+  class cluster cluster;
+{{</ mermaid >}}
+
+IngressはServiceに対して、外部疎通できるURL、負荷分散トラフィック、SSL/TLS終端の機能や、名前ベースの仮想ホスティングを提供するように設定できます。[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers/)は通常はロードバランサーを使用してIngressの機能を実現しますが、エッジルーターや、追加のフロントエンドを構成してトラフィックの処理を支援することもできます。

 Ingressは任意のポートやプロトコルを公開しません。HTTPやHTTPS以外のServiceをインターネットに公開する場合、[Service.Type=NodePort](/ja/docs/concepts/services-networking/service/#nodeport)や[Service.Type=LoadBalancer](/ja/docs/concepts/services-networking/service/#loadbalancer)のServiceタイプを一般的には使用します。

@@ -53,23 +64,7 @@ Ingressコントローラーのドキュメントを確認して、選択する

 Ingressリソースの最小構成の例は以下のとおりです。

-```yaml
-apiVersion: networking.k8s.io/v1beta1
-kind: Ingress
-metadata:
-  name: test-ingress
-  annotations:
-    nginx.ingress.kubernetes.io/rewrite-target: /
-spec:
-  rules:
-  - http:
-      paths:
-      - path: /testpath
-        pathType: Prefix
-        backend:
-          serviceName: test
-          servicePort: 80
-```
+{{< codenew file="service/networking/minimal-ingress.yaml" >}}

 他の全てのKubernetesリソースと同様に、Ingressには`apiVersion`、`kind`や`metadata`フィールドが必要です。Ingressオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。設定ファイルに関する一般的な情報は、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/docs/tasks/configure-pod-container/configure-pod-configmap/)、[リソースの管理](/docs/concepts/cluster-administration/manage-deployment/)を参照してください。Ingressでは、Ingressコントローラーに依存しているいくつかのオプションの設定をするためにアノテーションを一般的に使用します。例としては、[rewrite-targetアノテーション](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)などがあります。[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)の種類が異なれば、サポートするアノテーションも異なります。サポートされているアノテーションについて学ぶためには、使用するIngressコントローラーのドキュメントを確認してください。

@@ -80,52 +75,106 @@ Ingress [Spec](https://git.k8s.io/community/contributors/devel/sig-architecture/
 各HTTPルールは以下の情報を含みます。

 * オプションで設定可能なホスト名。上記のリソースの例では、ホスト名が指定されていないと、そのルールは指定されたIPアドレスを経由する全てのインバウンドHTTPトラフィックに適用されます。ホスト名が指定されていると(例: foo.bar.com)、そのルールはホストに対して適用されます。
-* パスのリスト(例: `/testpath`)。各パスには`serviceName`と`servicePort`で定義されるバックエンドが関連づけられます。ロードバランサーがトラフィックを関連づけられたServiceに転送するために、外部からくるリクエストのホスト名とパスが条件と一致させる必要があります。
-* [Serviceドキュメント](/ja/docs/concepts/services-networking/service/)に書かれているように、バックエンドはServiceとポート名の組み合わせとなります。Ingressで設定されたホスト名とパスのルールに一致するHTTP(とHTTPS)のリクエストは、リスト内のバックエンドに対して送信されます。
+* パスのリスト(例: `/testpath`)。各パスには`service.name`と`service.port.name`または`service.port.number`で定義されるバックエンドが関連づけられます。ロードバランサーがトラフィックを関連づけられたServiceに転送するために、外部からくるリクエストのホスト名とパスが条件と一致させる必要があります。
+* バックエンドは[Serviceドキュメント](/ja/docs/concepts/services-networking/service/)に書かれているようなService名とポート名の組み合わせ、または{{< glossary_tooltip term_id="CustomResourceDefinition" text="CRD" >}}による[カスタムリソースバックエンド](#resource-backend)です。Ingressで設定されたホスト名とパスのルールに一致するHTTP(とHTTPS)のリクエストは、リスト内のバックエンドに対して送信されます。

-Ingressコントローラーでは、デフォルトのバックエンドが設定されていることがあります。これはSpec内で指定されているパスに一致しないようなリクエストのためのバックエンドです。
+Ingressコントローラーでは、`defaultBackend`が設定されていることがあります。これはSpec内で指定されているパスに一致しないようなリクエストのためのバックエンドです。

-### デフォルトのバックエンド
+### デフォルトのバックエンド {#default-backend}

-ルールが設定されていないIngressは、全てのトラフィックをデフォルトのバックエンドに転送します。このデフォルトのバックエンドは、[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)のオプション設定であり、Ingressリソースでは指定されていません。
+ルールが設定されていないIngressは、全てのトラフィックをデフォルトのバックエンドに転送します。`defaultBackend`は、[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)のオプション設定であり、Ingressリソースでは指定されていません。

-IngressオブジェクトでHTTPリクエストが1つもホスト名とパスの条件に一致しない時、そのトラフィックはデフォルトのバックエンドに転送されます。
+HTTPリクエストがIngressオブジェクトのホスト名とパスの条件に1つも一致しない時、そのトラフィックはデフォルトのバックエンドに転送されます。
+
+### リソースバックエンド {#resource-backend}
+
+`Resource`バックエンドはIngressオブジェクトと同じnamespaceにある他のKubernetesリソースを指すObjectRefです。
+`Resource`はServiceの設定とは排他であるため、両方を指定するとバリデーションに失敗します。
+`Resource`バックエンドのよくある用途は、静的なアセットが入ったオブジェクトストレージを設定することです。
+
+{{< codenew file="service/networking/ingress-resource-backend.yaml" >}}
+
+上記のIngressを作成した後に、次のコマンドで参照することができます。
+
+```bash
+kubectl describe ingress ingress-resource-backend
+```
+
+```
+Name:             ingress-resource-backend
+Namespace:        default
+Address:
+Default backend:  APIGroup: k8s.example.com, Kind: StorageBucket, Name: static-assets
+Rules:
+  Host        Path  Backends
+  ----        ----  --------
+  *
+              /icons   APIGroup: k8s.example.com, Kind: StorageBucket, Name: icon-assets
+Annotations:  <none>
+Events:       <none>
+```

 ### パスのタイプ

-Ingressのそれぞれのパスは対応するパスのタイプを持ちます。サポートされているパスのタイプは3種類あります。
+Ingressのそれぞれのパスは対応するパスのタイプを持ちます。`pathType`が明示的に指定されていないパスはバリデーションに通らないでしょう。サポートされているパスのタイプは3種類あります。

-* _`ImplementationSpecific`_ (デフォルト): このパスタイプでは、パスとの一致はIngressClassに依存します。Ingressの実装はこれを独立した`pathType`と扱うことも、`Prefix`や`Exact`と同一のパスタイプと扱うこともできます。
+* `ImplementationSpecific`（実装に特有）: このパスタイプでは、パスとの一致はIngressClassに依存します。Ingressの実装はこれを独立した`pathType`と扱うことも、`Prefix`や`Exact`と同一のパスタイプと扱うこともできます。

-* _`Exact`_: 大文字小文字を区別して完全に一致するURLパスと一致します。
+* `Exact`: 大文字小文字を区別して完全に一致するURLパスと一致します。

-* _`Prefix`_: `/`で分割されたURLと前方一致で一致します。大文字小文字は区別され、パスの要素対要素で比較されます。パス要素は`/`で分割されたパスの中のラベルのリストを参照します。リクエストがパス _p_ に一致するのは、Ingressのパス _p_ がリクエストパス _p_ と要素単位で前方一致する場合です。
+* `Prefix`: `/`で分割されたURLと前方一致で一致します。大文字小文字は区別され、パスの要素対要素で比較されます。パス要素は`/`で分割されたパスの中のラベルのリストを参照します。リクエストがパス _p_ に一致するのは、Ingressのパス _p_ がリクエストパス _p_ と要素単位で前方一致する場合です。
  
  {{< note >}}
  パスの最後の要素がリクエストパスの最後の要素の部分文字列である場合、これは一致しません（例えば、`/foo/bar`は`/foo/bar/baz`と一致しますが、`/foo/barbaz`とは一致しません）。
  {{< /note >}}

+### 例
+
+| タイプ | パス                            | リクエストパス                | 一致するか                           |
+|--------|---------------------------------|-------------------------------|--------------------------------------|
+| Prefix | `/`                             | （全てのパス）                | はい                                 |
+| Exact  | `/foo`                          | `/foo`                        | はい                                 |
+| Exact  | `/foo`                          | `/bar`                        | いいえ                               |
+| Exact  | `/foo`                          | `/foo/`                       | いいえ                               |
+| Exact  | `/foo/`                         | `/foo`                        | いいえ                               |
+| Prefix | `/foo`                          | `/foo`, `/foo/`               | はい                                 |
+| Prefix | `/foo/`                         | `/foo`, `/foo/`               | はい                                 |
+| Prefix | `/aaa/bb`                       | `/aaa/bbb`                    | いいえ                               |
+| Prefix | `/aaa/bbb`                      | `/aaa/bbb`                    | はい                                 |
+| Prefix | `/aaa/bbb/`                     | `/aaa/bbb`                    | はい、末尾のスラッシュは無視         |
+| Prefix | `/aaa/bbb`                      | `/aaa/bbb/`                   | はい、末尾のスラッシュと一致         |
+| Prefix | `/aaa/bbb`                      | `/aaa/bbb/ccc`                | はい、パスの一部と一致               |
+| Prefix | `/aaa/bbb`                      | `/aaa/bbbxyz`                 | いいえ、接頭辞と一致しない           |
+| Prefix | `/`, `/aaa`                     | `/aaa/ccc`                    | はい、接頭辞`/aaa`と一致             |
+| Prefix | `/`, `/aaa`, `/aaa/bbb`         | `/aaa/bbb`                    | はい、接頭辞`/aaa/bbb`と一致         |
+| Prefix | `/`, `/aaa`, `/aaa/bbb`         | `/ccc`                        | はい、接頭辞`/`と一致                |
+| Prefix | `/aaa`                          | `/ccc`                        | いいえ、デフォルトバックエンドを使用 |
+| Mixed  | `/foo` (Prefix), `/foo` (Exact) | `/foo`                        | はい、Exactが優先                    |
+
 #### 複数のパスとの一致

 リクエストがIngressの複数のパスと一致することがあります。そのような場合は、最も長くパスが一致したものが優先されます。2つのパスが同等に一致した場合は、完全一致が前方一致よりも優先されます。

+## ホスト名のワイルドカード
+
+ホストは正確に一致する（例えば`foo.bar.com`）かワイルドカード（例えば`*.foo.com`）とすることができます。
+正確な一致ではHTTPヘッダーの`host`が`host`フィールドと一致することが必要です。
+ワイルドカードによる一致では、HTTPヘッダーの`host`がワイルドカードルールに沿って後方一致することが必要です。
+
+| Host        | Hostヘッダー      | 一致するか                                                  |
+| ----------- |-------------------| ------------------------------------------------------------|
+| `*.foo.com` | `bar.foo.com`     | 共通の接尾辞により一致                                      |
+| `*.foo.com` | `baz.bar.foo.com` | 一致しない。ワイルドカードは単一のDNSラベルのみを対象とする |
+| `*.foo.com` | `foo.com`         | 一致しない。ワイルドカードは単一のDNSラベルのみを対象とする |
+
+{{< codenew file="service/networking/ingress-wildcard-host.yaml" >}}
+
 ## Ingress Class

 Ingressは異なったコントローラーで実装されうるため、しばしば異なった設定を必要とします。
 IngressClassリソースは、この種別のIngressを実装すべきコントローラーの名称を含む追加の設定情報を含みます。各IngressはIngressClassリソースへの参照によって種別を指定すべきです。

-```yaml
-apiVersion: networking.k8s.io/v1beta1
-kind: IngressClass
-metadata:
-  name: external-lb
-spec:
-  controller: example.com/ingress-controller
-  parameters:
-    apiGroup: k8s.example.com/v1alpha
-    kind: IngressParameters
-    name: external-lb
-```
+{{< codenew file="service/networking/external-lb.yaml" >}}

 IngressClassリソースは任意のパラメータフィールドを含むことができます。これは追加の設定情報を参照するために利用することができます。

@@ -137,7 +186,7 @@ Kubernetes 1.18でIngressClassリソースと`ingressClassName`フィールド
 Ingressの新しい`ingressClassName`フィールドはこのアノテーションを置き換えるものですが、完全に等価ではありません。
 アノテーションは一般にIngressを実装すべきIngressのコントローラーの名称を示していましたが、フィールドはIngressClassリソースを示しており、これはIngressのコントローラーの名称を含む追加のIngressの設定情報を持ちます。

-### デフォルトのIngress Class
+### デフォルトのIngressClass {#default-ingress-class}

 特定のIngressClassをクラスターでのデフォルトとすることができます。
 IngressClassリソースの`ingressclass.kubernetes.io/is-default-class`アノテーションを`true`に設定すると、`ingressClassName`フィールドが指定されないIngressにはこのデフォルトIngressClassが割り当てられるようになります。
@@ -148,20 +197,21 @@ IngressClassリソースの`ingressclass.kubernetes.io/is-default-class`アノ

 ## Ingressのタイプ

-### 単一ServiceのIngress
+### 単一ServiceのIngress {#single-service-ingress}
+
 Kubernetesには、単一のServiceを公開できるようにする既存の概念があります（[Ingressの代替案](#alternatives)を参照してください）。ルールなしで*デフォルトのバックエンド* を指定することにより、Ingressでこれを実現することもできます。

-{{< codenew file="service/networking/ingress.yaml" >}}
+{{< codenew file="service/networking/test-ingress.yaml" >}}

 `kubectl apply -f`を実行してIngressを作成すると、その作成したIngressの状態を確認することができます。

-```shell
+```bash
 kubectl get ingress test-ingress
 ```

 ```
-NAME           HOSTS     ADDRESS           PORTS     AGE
-test-ingress   *         203.0.113.123     80        59s
+NAME           CLASS         HOSTS   ADDRESS         PORTS   AGE
+test-ingress   external-lb   *       203.0.113.123   80      59s
 ```

 `203.0.113.123`はIngressコントローラーによって割り当てられたIPで、作成したIngressを利用するためのものです。
@@ -174,34 +224,29 @@ IngressコントローラーとロードバランサーがIPアドレス割り

 ファンアウト設定では単一のIPアドレスのトラフィックを、リクエストされたHTTP URIに基づいて1つ以上のServiceに転送します。Ingressによってロードバランサーの数を少なくすることができます。例えば、以下のように設定します。

-```none
-foo.bar.com -> 178.91.123.132 -> / foo    service1:4200
-                                 / bar    service2:8080
-```
+{{< mermaid >}}
+graph LR;
+  client([クライアント])-. Ingress管理下の <br> ロードバランサー .->ingress[Ingress, 178.91.123.132];
+  ingress-->|/foo|service1[Service service1:4200];
+  ingress-->|/bar|service2[Service service2:8080];
+  subgraph cluster[クラスター]
+  ingress;
+  service1-->pod1[Pod];
+  service1-->pod2[Pod];
+  service2-->pod3[Pod];
+  service2-->pod4[Pod];
+  end
+  classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+  classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+  classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+  class ingress,service1,service2,pod1,pod2,pod3,pod4 k8s;
+  class client plain;
+  class cluster cluster;
+{{</ mermaid >}}

 Ingressを以下のように設定します。

-```yaml
-apiVersion: networking.k8s.io/v1beta1
-kind: Ingress
-metadata:
-  name: simple-fanout-example
-  annotations:
-    nginx.ingress.kubernetes.io/rewrite-target: /
-spec:
-  rules:
-  - host: foo.bar.com
-    http:
-      paths:
-      - path: /foo
-        backend:
-          serviceName: service1
-          servicePort: 4200
-      - path: /bar
-        backend:
-          serviceName: service2
-          servicePort: 8080
-```
+{{< codenew file="service/networking/simple-fanout-example.yaml" >}}

 Ingressを`kubectl apply -f`によって作成したとき:

@@ -220,8 +265,6 @@ Rules:
  foo.bar.com
               /foo   service1:4200 (10.8.0.90:4200)
               /bar   service2:8080 (10.8.0.91:8080)
-Annotations:
-  nginx.ingress.kubernetes.io/rewrite-target:  /
 Events:
  Type     Reason  Age                From                     Message
  ----     ------  ----               ----                     -------
@@ -232,75 +275,46 @@ IngressコントローラーはService(`service1`、`service2`)が存在する
 構築が完了すると、ADDRESSフィールドでロードバランサーのアドレスを確認できます。

 {{< note >}}
-使用する[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)に依存しますが、default-http-backend[Service](/ja/docs/concepts/services-networking/service/)の作成が必要な場合があります。
+使用する[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers/)に依存しますが、default-http-backend[Service](/ja/docs/concepts/services-networking/service/)の作成が必要な場合があります。
 {{< /note >}}

 ### 名前ベースのバーチャルホスティング

 名前ベースのバーチャルホストは、HTTPトラフィックを同一のIPアドレスの複数のホスト名に転送することをサポートしています。

-```none
-foo.bar.com --|                 |-> foo.bar.com service1:80
-              | 178.91.123.132  |
-bar.foo.com --|                 |-> bar.foo.com service2:80
-```
+{{< mermaid >}}
+graph LR;
+  client([クライアント])-. Ingress管理下の <br> ロードバランサー .->ingress[Ingress, 178.91.123.132];
+  ingress-->|Host: foo.bar.com|service1[Service service1:80];
+  ingress-->|Host: bar.foo.com|service2[Service service2:80];
+  subgraph cluster[クラスター]
+  ingress;
+  service1-->pod1[Pod];
+  service1-->pod2[Pod];
+  service2-->pod3[Pod];
+  service2-->pod4[Pod];
+  end
+  classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+  classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+  classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+  class ingress,service1,service2,pod1,pod2,pod3,pod4 k8s;
+  class client plain;
+  class cluster cluster;
+{{</ mermaid >}}

 以下のIngress設定は、ロードバランサーに対して、[Hostヘッダー](https://tools.ietf.org/html/rfc7230#section-5.4)に基づいてリクエストを転送するように指示するものです。

-```yaml
-apiVersion: networking.k8s.io/v1beta1
-kind: Ingress
-metadata:
-  name: name-virtual-host-ingress
-spec:
-  rules:
-  - host: foo.bar.com
-    http:
-      paths:
-      - backend:
-          serviceName: service1
-          servicePort: 80
-  - host: bar.foo.com
-    http:
-      paths:
-      - backend:
-          serviceName: service2
-          servicePort: 80
-```
+{{< codenew file="service/networking/name-virtual-host-ingress.yaml" >}}

 rules項目でのホストの設定がないIngressを作成すると、IngressコントローラーのIPアドレスに対するwebトラフィックは、要求されている名前ベースのバーチャルホストなしにマッチさせることができます。

-例えば、以下のIngressリソースは`first.bar.com`に対するトラフィックを`service1`へ、`second.foo.com`に対するトラフィックを`service2`へ、リクエストにおいてホスト名が指定されていない(リクエストヘッダーがないことを意味します)トラフィックは`service3`へ転送します。
+例えば、以下のIngressは`first.bar.com`に対するトラフィックを`service1`へ、`second.foo.com`に対するトラフィックを`service2`へ、リクエストにおいてホスト名が指定されていない(リクエストヘッダーがないことを意味します)トラフィックは`service3`へ転送します。

-```yaml
-apiVersion: networking.k8s.io/v1beta1
-kind: Ingress
-metadata:
-  name: name-virtual-host-ingress
-spec:
-  rules:
-  - host: first.bar.com
-    http:
-      paths:
-      - backend:
-          serviceName: service1
-          servicePort: 80
-  - host: second.foo.com
-    http:
-      paths:
-      - backend:
-          serviceName: service2
-          servicePort: 80
-  - http:
-      paths:
-      - backend:
-          serviceName: service3
-          servicePort: 80
-```
+{{< codenew file="service/networking/name-virtual-host-ingress-no-third-host.yaml" >}}

 ### TLS

-TLSの秘密鍵と証明書を含んだ{{< glossary_tooltip term_id="secret" >}}を指定することにより、Ingressをセキュアにできます。現在Ingressは単一のTLSポートである443番ポートのみサポートし、TLS終端を行うことを想定しています。IngressのTLS設定のセクションで異なるホストを指定すると、それらのホストはSNI TLSエクステンション(IngressコントローラーがSNIをサポートしている場合)を介して指定されたホスト名に対し、同じポート上で多重化されます。TLSのSecretは`tls.crt`と`tls.key`というキーを含む必要があり、TLSを使用するための証明書と秘密鍵を含む値となります。以下がその例です。
+TLSの秘密鍵と証明書を含んだ{{< glossary_tooltip term_id="secret" >}}を指定することにより、Ingressをセキュアにできます。Ingressは単一のTLSポートである443番ポートのみサポートし、IngressでTLS終端を行うことを想定しています。IngressからServiceやPodへのトラフィックは平文です。IngressのTLS設定のセクションで異なるホストを指定すると、それらのホストはSNI TLSエクステンション(IngressコントローラーがSNIをサポートしている場合)を介して指定されたホスト名に対し、同じポート上で多重化されます。TLSのSecretは`tls.crt`と`tls.key`というキーを含む必要があり、TLSを使用するための証明書と秘密鍵を含む値となります。以下がその例です。

 ```yaml
 apiVersion: v1
@@ -314,37 +328,25 @@ data:
 type: kubernetes.io/tls
 ```

-IngressでこのSecretを参照すると、クライアントとロードバランサー間の通信にTLSを使用するようIngressコントローラーに指示することになります。作成したTLS Secretは、`sslexample.foo.com`の完全修飾ドメイン名(FQDN)とも呼ばれる共通名(CN)を含む証明書から作成したものであることを確認する必要があります。
+IngressでこのSecretを参照すると、クライアントとロードバランサー間の通信にTLSを使用するようIngressコントローラーに指示することになります。作成したTLS Secretは、`https-example.foo.com`の完全修飾ドメイン名(FQDN)とも呼ばれる共通名(CN)を含む証明書から作成したものであることを確認する必要があります。

-```yaml
-apiVersion: networking.k8s.io/v1beta1
-kind: Ingress
-metadata:
-  name: tls-example-ingress
-spec:
-  tls:
-  - hosts:
-      - sslexample.foo.com
-    secretName: testsecret-tls
-  rules:
-  - host: sslexample.foo.com
-    http:
-      paths:
-      - path: /
-        backend:
-          serviceName: service1
-          servicePort: 80
-```
+{{< note >}}
+デフォルトルールではTLSが機能しない可能性があることに注意してください。
+これは取り得る全てのサブドメインに対する証明書を発行する必要があるからです。
+そのため、`tls`セクションの`hosts`は`rules`セクションの`host`と明示的に一致する必要があります。
+{{< /note >}}
+
+{{< codenew file="service/networking/tls-example-ingress.yaml" >}}

 {{< note >}}
 サポートされるTLSの機能はIngressコントローラーによって違いがあります。利用する環境でTLSがどのように動作するかを理解するためには、[nginx](https://kubernetes.github.io/ingress-nginx/user-guide/tls/)や、[GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https)、他のプラットフォーム固有のIngressコントローラーのドキュメントを確認してください。
 {{< /note >}}

-### 負荷分散
+### 負荷分散 {#load-balancing}

 Ingressコントローラーは、負荷分散アルゴリズムやバックエンドの重みスキームなど、すべてのIngressに適用されるいくつかの負荷分散ポリシーの設定とともにブートストラップされます。発展した負荷分散のコンセプト(例: セッションの永続化、動的重み付けなど)はIngressによってサポートされていません。代わりに、それらの機能はService用のロードバランサーを介して利用できます。

-Ingressによってヘルスチェックの機能が直接に公開されていない場合でも、Kubernetesにおいて、同等の機能を提供する[Readiness Probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)のようなコンセプトが存在することは注目に値します。コントローラーがどのようにヘルスチェックを行うかについては、コントローラーのドキュメントを参照してください([nginx](https://git.k8s.io/ingress-nginx/README.md)、[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks))。
+Ingressによってヘルスチェックの機能が直接に公開されていない場合でも、Kubernetesにおいて、同等の機能を提供する[Readiness Probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)のようなコンセプトが存在することは注目に値します。コントローラーがどのようにヘルスチェックを行うかについては、コントローラーのドキュメントを参照してください(例えば[nginx](https://git.k8s.io/ingress-nginx/README.md)、または[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks))。

 ## Ingressの更新

@@ -385,16 +387,22 @@ spec:
    http:
      paths:
      - backend:
-          serviceName: service1
-          servicePort: 80
+          service:
+            name: service1
+            port:
+              number: 80
        path: /foo
+        pathType: Prefix
  - host: bar.baz.com
    http:
      paths:
      - backend:
-          serviceName: service2
-          servicePort: 80
+          service:
+            name: service2
+            port:
+              number: 80
        path: /foo
+        pathType: Prefix
 ..
 ```

@@ -430,11 +438,7 @@ Events:

 ## アベイラビリティーゾーンをまたいだ障害について

-障害のあるドメインをまたいでトラフィックを分散する手法は、クラウドプロバイダーによって異なります。詳細に関して、[Ingress コントローラー](/ja/docs/concepts/services-networking/ingress-controllers)のドキュメントを参照してください。複数のクラスターにおいてIngressをデプロイする方法の詳細に関しては[Kubernetes Cluster Federationのドキュメント](https://github.com/kubernetes-sigs/federation-v2)を参照してください。
-
-## 将来追加予定の内容
-
-Ingressと関連するリソースの今後の開発については[SIG Network](https://github.com/kubernetes/community/tree/master/sig-network)で行われている議論を確認してください。様々なIngressコントローラーの開発については[Ingress リポジトリー](https://github.com/kubernetes/ingress/tree/master)を確認してください。
+障害のあるドメインをまたいでトラフィックを分散する手法は、クラウドプロバイダーによって異なります。詳細に関して、[Ingress コントローラー](/ja/docs/concepts/services-networking/ingress-controllers)のドキュメントを参照してください。

 ## Ingressの代替案 {#alternatives}

@@ -447,4 +451,4 @@ Ingressリソースを直接含まない複数の方法でサービスを公開
 ## {{% heading "whatsnext" %}}
 * [Ingress API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)について学ぶ
 * [Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers/)について学ぶ
-* [MinikubeとNGINXコントローラーでIngressのセットアップを行う](/docs/tasks/access-application-cluster/ingress-minikube)
+* [MinikubeとNGINXコントローラーでIngressのセットアップを行う](/docs/tasks/access-application-cluster/ingress-minikube/)
@@ -6,9 +6,17 @@ weight: 50

 <!-- overview -->

-ネットワークポリシーは、{{< glossary_tooltip text="Pod" term_id="pod">}}のグループが、Pod相互や他のネットワークエンドポイントと通信する場合に許可を与える方法を指定するための仕様です。
+IPアドレスまたはポートのレベル(OSI参照モデルのレイヤ3または4)でトラフィックフローを制御したい場合、クラスター内の特定のアプリケーションにKubernetesのネットワークポリシーを使用することを検討してください。ネットワークポリシーはアプリケーション中心の構造であり、{{<glossary_tooltip text="Pod" term_id="pod">}}がネットワークを介して多様な「エンティティ」(「Endpoint」や「Service」のようなKubernetesに含まれる特定の意味を持つ共通の用語との重複を避けるため、ここではエンティティという単語を使用します。)と通信する方法を指定できます。

-NetworkPolicyリソースは、{{< glossary_tooltip text="ラベル" term_id="label">}}を使用してPodを選択し、選択したPodに対してどんなトラフィックを許可するかを指定するルールを定義します。
+Podが通信できるエンティティは以下の3つの識別子の組み合わせによって識別されます。
+
+1. 許可されている他のPod(例外: Podはそれ自体へのアクセスをブロックできません)
+2. 許可されている名前空間
+3. IPブロック(例外: PodまたはノードのIPアドレスに関係なく、Podが実行されているノードとの間のトラフィックは常に許可されます。)
+
+Podベースもしくは名前空間ベースのネットワークポリシーを定義する場合、{{<glossary_tooltip text="セレクター" term_id="selector">}}を使用してセレクターに一致するPodとの間で許可されるトラフィックを指定します。
+
+一方でIPベースのネットワークポリシーが作成されると、IPブロック(CIDRの範囲)に基づいてポリシーが定義されます。

 <!-- body -->
 ## 前提条件
@@ -186,14 +194,33 @@ __ipBlock__: 特定のIPのCIDRの範囲を選択して、ingressの送信元ま

 ## SCTPのサポート

-{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.19" state="beta" >}}

-この機能を利用するには、クラスター管理者がAPIサーバーで`--feature-gates=SCTPSupport=true,…`と指定して、`SCTPSupport`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にする必要があります。フィーチャーゲートが有効になれば、NetworkPolicyの`protocol`フィールドに`SCTP`が指定できるようになります。
+ベータ版の機能として、これはデフォルトで有効化されます。
+クラスターレベルでSCTPを無効化するために、クラスター管理者はAPIサーバーで`--feature-gates=SCTPSupport=false,…`と指定して、`SCTPSupport`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を無効にする必要があります。

 {{< note >}}
 SCTPプロトコルのネットワークポリシーをサポートする{{< glossary_tooltip text="CNI" term_id="cni" >}}プラグインを使用している必要があります。
 {{< /note >}}

+## ネットワークポリシーでできないこと(少なくともまだ)
+
+Kubernetes1.20現在、ネットワークポリシーAPIに以下の機能は存在しません。
+しかし、オペレーティングシステムのコンポーネント(SELinux、OpenVSwitch、IPTablesなど)、レイヤ7の技術(Ingressコントローラー、サービスメッシュ実装)、もしくはアドミッションコントローラーを使用して回避策を実装できる場合があります。
+Kubernetesのネットワークセキュリティを初めて使用する場合は、ネットワークポリシーAPIを使用して以下ののユーザーストーリーを(まだ)実装できないことに注意してください。これらのユーザーストーリーの一部(全てではありません)は、ネットワークポリシーAPIの将来のリリースで活発に議論されています。
+
+- クラスター内トラフィックを強制的に共通ゲートウェイを通過させる(これは、サービスメッシュもしくは他のプロキシで提供するのが最適な場合があります)。
+- TLS関連のもの(これにはサービスメッシュまたはIngressコントローラを使用します)。
+- ノードの固有のポリシー(これらにはCIDR表記を使用できますが、Kubernetesのアイデンティティでノードを指定することはできません)。
+- 名前空間またはサービスを名前で指定する(ただし、Podまたは名前空間を{{< glossary_tooltip text="ラベル" term_id="label" >}}で指定することができます。これは多くの場合で実行可能な回避策です)。
+- サードパーティによって実行される「ポリシー要求」の作成または管理
+- 全ての名前空間もしくはPodに適用されるデフォルトのポリシー(これを実現できるサードパーティのKubernetesディストリビューションとプロジェクトがいくつか存在します)。
+- 高度なポリシークエリと到達可能性ツール
+- 単一のポリシー宣言でポートの範囲を指定する機能
+- ネットワークセキュリティイベント(例えばブロックされた接続や受け入れられた接続)をログに記録する機能
+- ポリシーを明示的に拒否する機能(現在、ネットワークポリシーのモデルはデフォルトで拒否されており、許可ルールを追加する機能のみが存在します)。
+- ループバックまたは内向きのホストトラフィックを拒否する機能(Podは現在localhostのアクセスやそれらが配置されているノードからのアクセスをブロックすることはできません)。
+
 ## {{% heading "whatsnext" %}}

 - [ネットワークポリシーを宣言する](/ja/docs/tasks/administer-cluster/declare-network-policy/)で追加の例の説明を読む。
@@ -23,7 +23,7 @@ KubernetesはPodにそれぞれのIPアドレス割り振りや、Podのセッ

 ## Serviceを利用する動機

-{{< glossary_tooltip term_id="pod" text="Pod" >}}は停止が想定して設計されています。 Podが作成され、もしそれらが停止する時、Podは再作成されません。
+Kubernetes {{< glossary_tooltip term_id="pod" text="Pod" >}}はクラスターの状態に合わせて作成され削除されます。Podは揮発的なリソースです。
 {{< glossary_tooltip term_id="deployment" >}}をアプリケーションを稼働させるために使用すると、Podを動的に作成・削除してくれます。

 各Podはそれ自身のIPアドレスを持ちます。しかしDeploymentでは、ある時点において同時に稼働しているPodのセットは、その後のある時点において稼働しているPodのセットとは異なる場合があります。
@@ -35,7 +35,8 @@ KubernetesはPodにそれぞれのIPアドレス割り振りや、Podのセッ
 ## Serviceリソース {#service-resource}

 Kubernetesにおいて、ServiceはPodの論理的なセットや、そのPodのセットにアクセスするためのポリシーを定義します(このパターンはよくマイクロサービスと呼ばることがあります)。
-ServiceによってターゲットとされたPodのセットは、たいてい {{< glossary_tooltip text="セレクター" term_id="selector" >}} (セレクターなしのServiceを利用したい場合は[下記](#services-without-selectors)を参照してください)によって定義されます。
+ServiceによってターゲットとされたPodのセットは、たいてい {{< glossary_tooltip text="セレクター" term_id="selector" >}}によって定義されます。
+その他の方法について知りたい場合は[セレクターなしのService](#services-without-selectors)を参照してください。

 例えば、3つのレプリカが稼働しているステートレスな画像処理用のバックエンドを考えます。これらのレプリカは代替可能です。&mdash; フロントエンドはバックエンドが何であろうと気にしません。バックエンドのセットを構成する実際のPodのセットが変更された際、フロントエンドクライアントはその変更を気にしたり、バックエンドのPodのセットの情報を記録しておく必要はありません。

@@ -90,9 +91,9 @@ ServiceのデフォルトプロトコルはTCPです。また、他の[サポー
 Serviceは多くの場合、KubernetesのPodに対するアクセスを抽象化しますが、他の種類のバックエンドも抽象化できます。
 例えば:

-  * プロダクション環境で外部のデータベースクラスターを利用したいが、テスト環境では、自身のクラスターが持つデータベースを利用したい場合
-  * Serviceを、異なるNamespace内のServiceや他のクラスターのServiceに向ける場合
-  * ワークロードをKubernetesに移行するとき、アプリケーションに対する処理をしながら、バックエンドの一部をKubernetesで実行する場合
+* プロダクション環境で外部のデータベースクラスターを利用したいが、テスト環境では、自身のクラスターが持つデータベースを利用したい場合
+* Serviceを、異なる{{< glossary_tooltip term_id="namespace" >}}のServiceや他のクラスターのServiceに向ける場合
+* ワークロードをKubernetesに移行するとき、アプリケーションに対する処理をしながら、バックエンドの一部をKubernetesで実行する場合

 このような場合において、ユーザーはPodセレクター_なしで_ Serviceを定義できます。

@@ -137,20 +138,19 @@ link-local (169.254.0.0/16 and 224.0.0.0/24 for IPv4, fe80::/64 for IPv6)に設
 ExternalName Serviceはセレクターの代わりにDNS名を使用する特殊なケースのServiceです。さらなる情報は、このドキュメントの後で紹介する[ExternalName](#externalname)を参照ください。

 ### エンドポイントスライス
+
 {{< feature-state for_k8s_version="v1.17" state="beta" >}}

 エンドポイントスライスは、Endpointsに対してよりスケーラブルな代替手段を提供できるAPIリソースです。概念的にはEndpointsに非常に似ていますが、エンドポイントスライスを使用すると、ネットワークエンドポイントを複数のリソースに分割できます。デフォルトでは、エンドポイントスライスは、100個のエンドポイントに到達すると「いっぱいである」と見なされ、その時点で追加のエンドポイントスライスが作成され、追加のエンドポイントが保存されます。

-エンドポイントスライスは、[エンドポイントスライスのドキュメント](/docs/concepts/services-networking/endpoint-slices/)にて詳しく説明されている追加の属性と機能を提供します。
+エンドポイントスライスは、[エンドポイントスライスのドキュメント](/ja/docs/concepts/services-networking/endpoint-slices/)にて詳しく説明されている追加の属性と機能を提供します。

 ### アプリケーションプロトコル

-{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
-
-AppProtocolフィールドは、各Serviceのポートで使用されるアプリケーションプロトコルを指定する方法を提供します。
-
-アルファ機能のため、このフィールドはデフォルトで有効化されていません。このフィールドを使用するには、 `ServiceAppProtocol` という[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効化してください。
+{{< feature-state for_k8s_version="v1.19" state="beta" >}}

+`AppProtocol`フィールドによってServiceの各ポートに対して特定のアプリケーションプロトコルを指定することができます。
+この値は、対応するEndpointsオブジェクトとEndpointSliceオブジェクトに反映されます。
 ## 仮想IPとサービスプロキシー {#virtual-ips-and-service-proxies}

 Kubernetesクラスターの各Nodeは`kube-proxy`を稼働させています。`kube-proxy`は[`ExternalName`](#externalname)タイプ以外の`Service`用に仮想IPを実装する責務があります。
@@ -162,9 +162,9 @@ Kubernetesクラスターの各Nodeは`kube-proxy`を稼働させています。

 Serviceにおいてプロキシーを使う理由はいくつかあります。

- * DNSの実装がレコードのTTLをうまく扱わず、期限が切れた後も名前解決の結果をキャッシュするという長い歴史がある。
- * いくつかのアプリケーションではDNSルックアップを1度だけ行い、その結果を無期限にキャッシュする。
- * アプリケーションとライブラリーが適切なDNS名の再解決を行ったとしても、DNSレコード上の0もしくは低い値のTTLがDNSに負荷をかけることがあり、管理が難しい。
+* DNSの実装がレコードのTTLをうまく扱わず、期限が切れた後も名前解決の結果をキャッシュするという長い歴史がある。
+* いくつかのアプリケーションではDNSルックアップを1度だけ行い、その結果を無期限にキャッシュする。
+* アプリケーションとライブラリーが適切なDNS名の再解決を行ったとしても、DNSレコード上の0もしくは低い値のTTLがDNSに負荷をかけることがあり、管理が難しい。

 ### user-spaceプロキシーモード {#proxy-mode-userspace}

@@ -211,12 +211,12 @@ IPVSプロキシーモードはiptablesモードと同様に、netfilterのフ

 IPVSはバックエンドPodに対するトラフィックのバランシングのために多くのオプションを下記のとおりに提供します。

- `rr`: ラウンドロビン
- `lc`: 最低コネクション数(オープンされているコネクション数がもっとも小さいもの)
- `dh`: 送信先IPによって割り当てられたハッシュ値をもとに割り当てる(Destination Hashing)
- `sh`: 送信元IPによって割り当てられたハッシュ値をもとに割り当てる(Source Hashing)
- `sed`: 見込み遅延が最小なもの
- `nq`: キューなしスケジューリング
+* `rr`: ラウンドロビン
+* `lc`: 最低コネクション数(オープンされているコネクション数がもっとも小さいもの)
+* `dh`: 送信先IPによって割り当てられたハッシュ値をもとに割り当てる(Destination Hashing)
+* `sh`: 送信元IPによって割り当てられたハッシュ値をもとに割り当てる(Source Hashing)
+* `sed`: 見込み遅延が最小なもの
+* `nq`: キューなしスケジューリング

 {{< note >}}
 IPVSモードでkube-proxyを稼働させるためには、kube-proxyを稼働させる前にNode上でIPVSを有効にしなければなりません。
@@ -282,7 +282,7 @@ PodがNode上で稼働するとき、kubeletはアクティブな各Serviceに
 これは[Docker links互換性](https://docs.docker.com/userguide/dockerlinks/)のある変数(
 [makeLinkVariables関数](https://releases.k8s.io/{{< param "githubbranch" >}}/pkg/kubelet/envvars/envvars.go#L72)を確認してください)や、より簡単な`{SVCNAME}_SERVICE_HOST`や、`{SVCNAME}_SERVICE_PORT`変数をサポートします。この変数名で使われるService名は大文字に変換され、`-`は`_`に変換されます。

-例えば、TCPポート6379番を公開していて、さらにclusterIPが10.0.0.11に割り当てられている`"redis-master"`というServiceは、下記のような環境変数を生成します。
+例えば、TCPポート6379番を公開していて、さらにclusterIPが10.0.0.11に割り当てられている`redis-master`というServiceは、下記のような環境変数を生成します。

 ```shell
 REDIS_MASTER_SERVICE_HOST=10.0.0.11
@@ -308,12 +308,12 @@ ServiceのclusterIPを発見するためにDNSのみを使う場合、このよ
 CoreDNSなどのクラスター対応のDNSサーバーは新しいServiceや、各Service用のDNSレコードのセットのためにKubernetes APIを常に監視します。
 もしクラスターを通してDNSが有効になっている場合、全てのPodはDNS名によって自動的にServiceに対する名前解決をするようにできるはずです。

-例えば、Kubernetesの`"my-ns"`というNamespace内で`"my-service"`というServiceがある場合、KubernetesコントロールプレーンとDNS Serviceが協調して動作し、`"my-service.my-ns"`というDNSレコードを作成します。
-`"my-ns"`というNamespace内のPodは`my-service`という名前で簡単に名前解決できるはずです(`"my-service.my-ns"`でも動作します)。
+例えば、Kubernetesの`my-ns`というNamespace内で`my-service`というServiceがある場合、KubernetesコントロールプレーンとDNS Serviceが協調して動作し、`my-service.my-ns`というDNSレコードを作成します。
+`my-ns`というNamespace内のPodは`my-service`という名前で簡単に名前解決できるはずです(`my-service.my-ns`でも動作します)。

 他のNamespace内でのPodは`my-service.my-ns`といった形で指定しなくてはなりません。これらのDNS名は、そのServiceのclusterIPに名前解決されます。

-Kubernetesは名前付きのポートに対するDNS SRV(Service)レコードもサポートしています。もし`"my-service.my-ns"`というServiceが`"http"`という名前のTCPポートを持っていた場合、IPアドレスと同様に、`"http"`のポート番号を探すために`_http._tcp.my-service.my-ns`というDNS SRVクエリを実行できます。
+Kubernetesは名前付きのポートに対するDNS SRV(Service)レコードもサポートしています。もし`my-service.my-ns`というServiceが`http`という名前のTCPポートを持っていた場合、IPアドレスと同様に、`http`のポート番号を探すために`_http._tcp.my-service.my-ns`というDNS SRVクエリを実行できます。

 KubernetesのDNSサーバーは`ExternalName` Serviceにアクセスする唯一の方法です。
 [DNS Pods と Service](/ja/docs/concepts/services-networking/dns-pod-service/)にて`ExternalName`による名前解決に関するさらなる情報を確認できます。
@@ -337,8 +337,8 @@ KubernetesのDNSサーバーは`ExternalName` Serviceにアクセスする唯一
 ラベルセレクターを定義しないHeadless Serviceにおいては、Endpointsコントローラーは`Endpoints`レコードを作成しません。
 しかしDNSのシステムは下記の2つ両方を探索し、設定します。

-  * [`ExternalName`](#externalname)タイプのServiceに対するCNAMEレコード
-  * 他の全てのServiceタイプを含む、Service名を共有している全ての`Endpoints`レコード
+* [`ExternalName`](#externalname)タイプのServiceに対するCNAMEレコード
+* 他の全てのServiceタイプを含む、Service名を共有している全ての`Endpoints`レコード

 ## Serviceの公開 (Serviceのタイプ) {#publishing-services-service-types}

@@ -349,16 +349,15 @@ Kubernetesの`ServiceTypes`によって、ユーザーがどのような種類

 `Type`項目の値と、そのふるまいは以下のようになります。

-   * `ClusterIP`: クラスター内部のIPでServiceを公開する。このタイプではServiceはクラスター内部からのみ疎通性があります。このタイプはデフォルトの`ServiceType`です。
-   * [`NodePort`](#nodeport): 各NodeのIPにて、静的なポート(`NodePort`)上でServiceを公開します。その`NodePort` のServiceが転送する先の`ClusterIP` Serviceが自動的に作成されます。`<NodeIP>:<NodePort>`にアクセスすることによって`NodePort` Serviceにアクセスできるようになります。
-   * [`LoadBalancer`](#loadbalancer): クラウドプロバイダーのロードバランサーを使用して、Serviceを外部に公開します。クラスター外部にあるロードバランサーが転送する先の`NodePort`と`ClusterIP` Serviceは自動的に作成されます。
-   * [`ExternalName`](#externalname): `CNAME`レコードを返すことにより、`externalName`フィールドに指定したコンテンツ(例: `foo.bar.example.com`)とServiceを紐づけます。しかし、いかなる種類のプロキシーも設定されません。
+* `ClusterIP`: クラスター内部のIPでServiceを公開する。このタイプではServiceはクラスター内部からのみ疎通性があります。このタイプはデフォルトの`ServiceType`です。
+* [`NodePort`](#nodeport): 各NodeのIPにて、静的なポート(`NodePort`)上でServiceを公開します。その`NodePort` のServiceが転送する先の`ClusterIP` Serviceが自動的に作成されます。`<NodeIP>:<NodePort>`にアクセスすることによって`NodePort` Serviceにアクセスできるようになります。
+* [`LoadBalancer`](#loadbalancer): クラウドプロバイダーのロードバランサーを使用して、Serviceを外部に公開します。クラスター外部にあるロードバランサーが転送する先の`NodePort`と`ClusterIP` Serviceは自動的に作成されます。
+* [`ExternalName`](#externalname): `CNAME`レコードを返すことにより、`externalName`フィールドに指定したコンテンツ(例: `foo.bar.example.com`)とServiceを紐づけます。しかし、いかなる種類のプロキシーも設定されません。
+  {{< note >}}
+  `ExternalName`タイプのServiceを利用するためには、kube-dnsのバージョン1.7かCoreDNSのバージョン0.0.8以上が必要となります。
+  {{< /note >}}

-     {{< note >}}
-     `ExternalName`タイプのServiceを利用するためには、kube-dnsのバージョン1.7かCoreDNSのバージョン0.0.8以上が必要となります。
-     {{< /note >}}
-
-また、Serviceを公開するために[Ingress](/docs/concepts/services-networking/ingress/)も利用可能です。IngressはServiceのタイプではありませんが、クラスターに対するエントリーポイントとして動作します。
+また、Serviceを公開するために[Ingress](/ja/docs/concepts/services-networking/ingress/)も利用可能です。IngressはServiceのタイプではありませんが、クラスターに対するエントリーポイントとして動作します。
 Ingressは同一のIPアドレスにおいて、複数のServiceを公開するように、ユーザーの設定した転送ルールを1つのリソースにまとめることができます。

 ### NodePort タイプ {#nodeport}
@@ -461,6 +460,7 @@ Split-HorizonなDNS環境において、ユーザーは2つのServiceを外部
 タブを選択してください。
 {{% /tab %}}
 {{% tab name="GCP" %}}
+
 ```yaml
 [...]
 metadata:
@@ -469,8 +469,10 @@ metadata:
        cloud.google.com/load-balancer-type: "Internal"
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="AWS" %}}
+
 ```yaml
 [...]
 metadata:
@@ -479,8 +481,10 @@ metadata:
        service.beta.kubernetes.io/aws-load-balancer-internal: 0.0.0.0/0
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="Azure" %}}
+
 ```yaml
 [...]
 metadata:
@@ -489,8 +493,10 @@ metadata:
        service.beta.kubernetes.io/azure-load-balancer-internal: "true"
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="IBM Cloud" %}}
+
 ```yaml
 [...]
 metadata:
@@ -502,6 +508,7 @@ metadata:

 {{% /tab %}}
 {{% tab name="OpenStack" %}}
+
 ```yaml
 [...]
 metadata:
@@ -510,8 +517,10 @@ metadata:
        service.beta.kubernetes.io/openstack-internal-load-balancer: "true"
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="Baidu Cloud" %}}
+
 ```yaml
 [...]
 metadata:
@@ -520,8 +529,10 @@ metadata:
        service.beta.kubernetes.io/cce-load-balancer-internal-vpc: "true"
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="Tencent Cloud" %}}
+
 ```yaml
 [...]
 metadata:
@@ -529,6 +540,7 @@ metadata:
    service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: subnet-xxxxx
 [...]
 ```
+
 {{% /tab %}}
 {{< /tabs >}}

@@ -675,8 +687,16 @@ AWS上でのELB Service用のアクセスログを管理するためにはいく
        # この値はservice.beta.kubernetes.io/aws-load-balancer-healthcheck-intervalの値以下である必要があります。
        # デフォルトでは5 この値は2から60の間で設定可能

+        service.beta.kubernetes.io/aws-load-balancer-security-groups: "sg-53fae93f"
+        # ELBが作成される際に追加されるセキュリティグループのリスト
+        # service.beta.kubernetes.io/aws-load-balancer-extra-security-groupsアノテーションと異なり
+        # 元々ELBに付与されていたセキュリティグループを置き換えることになります。
+
        service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: "sg-53fae93f,sg-42efd82e"
        # ELBに追加される予定のセキュリティーグループのリスト
+
+        service.beta.kubernetes.io/aws-load-balancer-target-node-labels: "ingress-gw,gw-name=public-api"
+        # ロードバランサーがターゲットノードを指定する際に利用するキーバリューのペアのコンマ区切りリストです。
 ```

 #### AWSでのNetwork Load Balancerのサポート {#aws-nlb-support}
@@ -712,7 +732,7 @@ NLBの背後にあるインスタンスに対してクライアントのトラ
 |------|----------|---------|------------|---------------------|
 | ヘルスチェック | TCP | NodePort(s) (`.spec.healthCheckNodePort` for `.spec.externalTrafficPolicy = Local`) | VPC CIDR | kubernetes.io/rule/nlb/health=\<loadBalancerName\> |
 | クライアントのトラフィック | TCP | NodePort(s) | `.spec.loadBalancerSourceRanges` (デフォルト: `0.0.0.0/0`) | kubernetes.io/rule/nlb/client=\<loadBalancerName\> |
-| MTCによるサービスディスカバリー | ICMP | 3,4 | `.spec.loadBalancerSourceRanges` (デフォルト: `0.0.0.0/0`) | kubernetes.io/rule/nlb/mtu=\<loadBalancerName\> |
+| MTUによるサービスディスカバリー | ICMP | 3,4 | `.spec.loadBalancerSourceRanges` (デフォルト: `0.0.0.0/0`) | kubernetes.io/rule/nlb/mtu=\<loadBalancerName\> |

 どのクライアントIPがNLBにアクセス可能かを制限するためには、`loadBalancerSourceRanges`を指定してください。

@@ -738,8 +758,9 @@ spec:
      annotations:
        # 指定したノードでロードバランサーをバインドします
        service.kubernetes.io/qcloud-loadbalancer-backends-label: key in (value1, value2)
+
        # 既存のロードバランサーのID
-        service.kubernetes.io/tke-existed-lbid:lb-6swtxxxx
+        service.kubernetes.io/tke-existed-lbid: lb-6swtxxxx

        # ロードバランサー(LB)のカスタムパラメーターは、LBタイプの変更をまだサポートしていません
        service.kubernetes.io/service.extensiveParameters: ""
@@ -750,11 +771,14 @@ spec:
        # ロードバランサーのタイプを指定します
        # 有効な値: classic(Classic Cloud Load Balancer)またはapplication(Application Cloud Load Balancer)
        service.kubernetes.io/loadbalance-type: xxxxx
+
        # パブリックネットワーク帯域幅の課金方法を指定します
        # 有効な値: TRAFFIC_POSTPAID_BY_HOUR(bill-by-traffic)およびBANDWIDTH_POSTPAID_BY_HOUR(bill-by-bandwidth)
        service.kubernetes.io/qcloud-loadbalancer-internet-charge-type: xxxxxx
+
        # 帯域幅の値を指定します(値の範囲:[1-2000] Mbps)。
        service.kubernetes.io/qcloud-loadbalancer-internet-max-bandwidth-out: "10"
+
        # この注釈が設定されている場合、ロードバランサーはポッドが実行されているノードのみを登録します
        # そうでない場合、すべてのノードが登録されます
        service.kubernetes.io/local-svc-only-bind-node-with-pod: true
@@ -777,6 +801,7 @@ spec:
  type: ExternalName
  externalName: my.database.example.com
 ```
+
 {{< note >}}
 ExternalNameはIpv4のアドレスの文字列のみ受け付けますが、IPアドレスではなく、数字で構成されるDNS名として受け入れます。
 IPv4アドレスに似ているExternalNamesはCoreDNSもしくはIngress-Nginxによって名前解決されず、これはExternalNameは正規のDNS名を指定することを目的としているためです。
@@ -914,12 +939,12 @@ ServiceはKubernetesのREST APIにおいてトップレベルのリソースで
 もしクラウドプロバイダーがサポートしている場合、ServiceのEndpointsに転送される外部のHTTP/HTTPSでのリバースプロキシーをセットアップするために、LoadBalancerモードでServiceを作成可能です。

 {{< note >}}
-ユーザーはまた、HTTP / HTTPS Serviceを公開するために、Serviceの代わりに{{< glossary_tooltip term_id="ingress" >}}を利用することもできます。
+ユーザーはまた、HTTP/HTTPS Serviceを公開するために、Serviceの代わりに{{< glossary_tooltip term_id="ingress" >}}を利用することもできます。
 {{< /note >}}

 ### PROXY プロトコル

-もしクラウドプロバイダーがサポートしている場合(例: [AWS](/docs/concepts/cluster-administration/cloud-providers/#aws))、Kubernetesクラスターの外部のロードバランサーを設定するためにLoadBalancerモードでServiceを利用できます。これは[PROXY protocol](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)がついた接続を転送します。
+もしクラウドプロバイダーがサポートしている場合、Kubernetesクラスターの外部のロードバランサーを設定するためにLoadBalancerモードでServiceを利用できます。これは[PROXY protocol](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)がついた接続を転送します。

 ロードバランサーは、最初の一連のオクテットを送信します。
 下記のような例となります。
@@ -927,15 +952,16 @@ ServiceはKubernetesのREST APIにおいてトップレベルのリソースで
 ```
 PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n
 ```
+
 クライアントからのデータのあとに追加されます。

 ### SCTP

-{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.19" state="beta" >}}

-KubernetesはService、Endpoints、NetworkPolicyとPodの定義においてα版の機能として`protocol`フィールドの値でSCTPをサポートしています。この機能を有効にするために、クラスター管理者はAPI Serverにおいて`SCTPSupport`というフィーチャーゲートを有効にする必要があります。例えば、`--feature-gates=SCTPSupport=true,…`といったように設定します。
+KubernetesはService、Endpoints、EndpointSlice、NetworkPolicyとPodの定義において`protocol`フィールドの値でSCTPをサポートしています。ベータ版の機能のため、この機能はデフォルトで有効になっています。SCTPをクラスターレベルで無効にするには、クラスター管理者はAPI Serverにおいて`SCTPSupport` [フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を`--feature-gates=SCTPSupport=false,…`と設定して無効にする必要があります。

-そのフィーチャーゲートが有効になった時、ユーザーはService、Endpoints、NetworkPolicyの`protocol`フィールドと、Podの`SCTP`フィールドを設定できます。
+そのフィーチャーゲートが有効になった時、ユーザーはService、Endpoints、EndpointSlice、NetworkPolicy、またはPodの`protocol`フィールドに`SCTP`を設定できます。
 Kubernetesは、TCP接続と同様に、SCTPアソシエーションに応じてネットワークをセットアップします。

 #### 警告 {#caveat-sctp-overview}
@@ -967,11 +993,8 @@ SCTPはWindowsベースのNodeではサポートされていません。
 kube-proxyはuserspaceモードにおいてSCTPアソシエーションの管理をサポートしません。
 {{< /warning >}}

-
-
 ## {{% heading "whatsnext" %}}

-
-* [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)を参照してください。
-* [Ingress](/docs/concepts/services-networking/ingress/)を参照してください。
-* [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/)を参照してください。
+* [Connecting Applications with Services](/ja/docs/concepts/services-networking/connect-applications-service/)を参照してください。
+* [Ingress](/ja/docs/concepts/services-networking/ingress/)を参照してください。
+* [EndpointSlices](/ja/docs/concepts/services-networking/endpoint-slices/)を参照してください。