Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update links to ja docs (home/, tasks/tools/install-kubectl/, concepts/services-networking/service/) #18930

Merged
merged 3 commits into from
Feb 3, 2020
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion content/ja/docs/concepts/_index.md
Original file line number Diff line number Diff line change
Expand Up @@ -31,7 +31,7 @@ Kubernetesには、デプロイ済みのコンテナ化されたアプリケー
基本的なKubernetesのオブジェクトは次のとおりです。

* [Pod](/ja/docs/concepts/workloads/pods/pod-overview/)
* [Service](/docs/concepts/services-networking/service/)
* [Service](/ja/docs/concepts/services-networking/service/)
* [Volume](/docs/concepts/storage/volumes/)
* [Namespace](/ja/docs/concepts/overview/working-with-objects/namespaces/)

Expand Down
2 changes: 1 addition & 1 deletion content/ja/docs/concepts/architecture/nodes.md
Original file line number Diff line number Diff line change
Expand Up @@ -98,7 +98,7 @@ CapacityとAllocatableについて深く知りたい場合は、ノード上で

## 管理 {#management}

[Pod](/docs/concepts/workloads/pods/pod/)や[Service](/docs/concepts/services-networking/service/)と違い、ノードは本質的にはKubernetesによって作成されません。GCPのようなクラウドプロバイダーによって外的に作成されるか、VMや物理マシンのプールに存在するものです。そのため、Kubernetesがノードを作成すると、そのノードを表すオブジェクトが作成されます。作成後、Kubernetesはそのノードが有効かどうかを確認します。 たとえば、次の内容からノードを作成しようとしたとします:
[Pod](/docs/concepts/workloads/pods/pod/)や[Service](/ja/docs/concepts/services-networking/service/)と違い、ノードは本質的にはKubernetesによって作成されません。GCPのようなクラウドプロバイダーによって外的に作成されるか、VMや物理マシンのプールに存在するものです。そのため、Kubernetesがノードを作成すると、そのノードを表すオブジェクトが作成されます。作成後、Kubernetesはそのノードが有効かどうかを確認します。 たとえば、次の内容からノードを作成しようとしたとします:

```json
{
Expand Down
7 changes: 3 additions & 4 deletions content/ja/docs/concepts/configuration/overview.md
Original file line number Diff line number Diff line change
Expand Up @@ -35,7 +35,7 @@ weight: 10

## Service

- 対応するバックエンドワークロード(DeploymentまたはReplicaSet)の前、およびそれにアクセスする必要があるワークロードの前に[Service](/docs/concepts/services-networking/service/)を作成します。Kubernetesがコンテナを起動すると、コンテナ起動時に実行されていたすべてのServiceを指す環境変数が提供されます。たとえば、fooという名前のServiceが存在する場合、すべてのコンテナは初期環境で次の変数を取得します。
- 対応するバックエンドワークロード(DeploymentまたはReplicaSet)の前、およびそれにアクセスする必要があるワークロードの前に[Service](/ja/docs/concepts/services-networking/service/)を作成します。Kubernetesがコンテナを起動すると、コンテナ起動時に実行されていたすべてのServiceを指す環境変数が提供されます。たとえば、fooという名前のServiceが存在する場合、すべてのコンテナは初期環境で次の変数を取得します。

```shell
FOO_SERVICE_HOST=<the host the Service is running on>
Expand All @@ -50,12 +50,11 @@ weight: 10

デバッグ目的でのみポートにアクセスする必要がある場合は、[apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls)または[`kubectl port-forward`](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)を使用できます。

ノード上でPodのポートを明示的に公開する必要がある場合は、hostPortに頼る前に[NodePort](/docs/concepts/services-networking/service/#nodeport)の使用を検討してください。
ノード上でPodのポートを明示的に公開する必要がある場合は、hostPortに頼る前に[NodePort](/ja/docs/concepts/services-networking/service/#nodeport)の使用を検討してください。

- `hostPort`の理由と同じくして、`hostNetwork`の使用はできるだけ避けてください。

- `kube-proxy`のロードバランシングが不要な場合は、[headless Service](/docs/concepts/services-networking/service/#headless-
services)(`ClusterIP`が`None`)を使用してServiceを簡単に検出できます。
- `kube-proxy`のロードバランシングが不要な場合は、[headless Service](/ja/docs/concepts/services-networking/service/#headless-service)(`ClusterIP`が`None`)を使用してServiceを簡単に検出できます。

## ラベルの使用

Expand Down
4 changes: 2 additions & 2 deletions content/ja/docs/concepts/overview/what-is-kubernetes.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@
title: Kubernetesとは何か?
content_template: templates/concept
weight: 10
card:
card:
name: concepts
weight: 10
---
Expand Down Expand Up @@ -98,7 +98,7 @@ Kubernetesは...

{{% capture whatsnext %}}
* [はじめる](/docs/setup/)準備はできましたか?
* さらなる詳細については、[Kubernetesのドキュメント](/docs/home/)を御覧ください。
* さらなる詳細については、[Kubernetesのドキュメント](/ja/docs/home/)を御覧ください。
{{% /capture %}}


Original file line number Diff line number Diff line change
Expand Up @@ -135,7 +135,7 @@ my-nginx 10.244.2.5:80,10.244.3.4:80 1m

クラスター内の任意のノードから、`<CLUSTER-IP>:<PORT>`でnginx Serviceにcurl接続できるようになりました。
Service IPは完全に仮想的なもので、ホスト側のネットワークには接続できないことに注意してください。
この仕組みに興味がある場合は、[サービスプロキシー](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)の詳細をお読みください。
この仕組みに興味がある場合は、[サービスプロキシー](/ja/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)の詳細をお読みください。

## Serviceにアクセスする

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -16,13 +16,13 @@ KubernetesのDNSはクラスター上でDNS PodとServiceをスケジュール

### 何がDNS名を取得するか

クラスター内(DNSサーバーそれ自体も含む)で定義された全てのServiceはDNS名を割り当てられます。デフォルトでは、クライアントPodのDNSサーチリストはPod自身のネームスペースと、クラスターのデフォルトドメインを含みます。
クラスター内(DNSサーバーそれ自体も含む)で定義された全てのServiceはDNS名を割り当てられます。デフォルトでは、クライアントPodのDNSサーチリストはPod自身のネームスペースと、クラスターのデフォルトドメインを含みます。
下記の例でこの仕組みを説明します。

Kubernetesの`bar`というネームスペース内で`foo`という名前のServiceがあると仮定します。`bar`ネームスペース内で稼働しているPodは、`foo`に対してDNSクエリを実行するだけでこのServiceを探すことができます。`bar`とは別の`quux`ネームスペース内で稼働しているPodは、`foo.bar`に対してDNSクエリを実行するだけでこのServiceを探すことができます。

下記のセクションでは、サポートされているレコードタイプとレイアウトについて詳しくまとめています。
うまく機能する他のレイアウト、名前、またはクエリーは、実装の詳細を考慮し、警告なしに変更されることがあります。
うまく機能する他のレイアウト、名前、またはクエリーは、実装の詳細を考慮し、警告なしに変更されることがあります。
最新の仕様に関する詳細は、[KubernetesにおけるDNSベースのServiceディスカバリ](https://github.com/kubernetes/dns/blob/master/docs/specification.md)を参照ください。

## Service
Expand All @@ -36,8 +36,8 @@ Kubernetesの`bar`というネームスペース内で`foo`という名前のSer
### SRVレコード

SRVレコードは、通常のServiceもしくは[Headless
Services](/docs/concepts/services-networking/service/#headless-services)の一部である名前付きポート向けに作成されます。それぞれの名前付きポートに対して、そのSRVレコードは`_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster.local`という形式となります。
通常のServiceに対しては、このSRVレコードは`my-svc.my-namespace.svc.cluster.local`という形式のドメイン名とポート番号へ名前解決します。
Services](/ja/docs/concepts/services-networking/service/#headless-service)の一部である名前付きポート向けに作成されます。それぞれの名前付きポートに対して、そのSRVレコードは`_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster.local`という形式となります。
通常のServiceに対しては、このSRVレコードは`my-svc.my-namespace.svc.cluster.local`という形式のドメイン名とポート番号へ名前解決します。
Headless Serviceに対しては、このSRVレコードは複数の結果を返します。それはServiceの背後にある各Podの1つを返すのと、`auto-generated-name.my-svc.my-namespace.svc.cluster.local`という形式のPodのドメイン名とポート番号を含んだ結果を返します。

## Pod
Expand Down
21 changes: 11 additions & 10 deletions content/ja/docs/concepts/services-networking/ingress.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,8 +17,8 @@ weight: 40

- ノード: Kubernetes内のワーカーマシンで、クラスターの一部です。

- クラスター: Kubernetesによって管理されているコンテナ化されたアプリケーションを実行させるノードのセットです。この例や、多くのKubernetesによるデプロイでは、クラスター内のノードはパブリックインターネットとして公開されていません。
- クラスター: Kubernetesによって管理されているコンテナ化されたアプリケーションを実行させるノードのセットです。この例や、多くのKubernetesによるデプロイでは、クラスター内のノードはパブリックインターネットとして公開されていません。

- エッジルーター: クラスターでファイアウォールのポリシーを強制するルーターです。エッジルーターはクラウドプロバイダーやハードウェアの物理的な一部として管理されたゲートウェイとなります。

- クラスターネットワーク: 物理的または論理的なリンクのセットで、Kubernetesの[ネットワークモデル](/docs/concepts/cluster-administration/networking/)によって、クラスター内でのコミュニケーションを司るものです。
Expand All @@ -27,7 +27,7 @@ weight: 40

## Ingressとは何か

Ingressはクラスター外からクラスター内{{< link text="Service" url="/docs/concepts/services-networking/service/" >}}へのHTTPとHTTPSのルートを公開します。トラフィックのルーティングはIngressリソース上で定義されるルールによって制御されます。
Ingressはクラスター外からクラスター内{{< link text="Service" url="/ja/docs/concepts/services-networking/service/" >}}へのHTTPとHTTPSのルートを公開します。トラフィックのルーティングはIngressリソース上で定義されるルールによって制御されます。

```none
internet
Expand All @@ -39,7 +39,7 @@ Ingressはクラスター外からクラスター内{{< link text="Service" url=

IngressはServiceに対して、外部疎通できるURL、負荷分散トラフィック、SSL/TLS終端の機能や、名前ベースの仮想ホスティングを提供するように構成できます。[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)は通常はロードバランサーを使用してIngressの機能を実現しますが、エッジルーターや、追加のフロントエンドを構成してトラフィックの処理を支援することもできます。

Ingressは任意のポートやプロトコルを公開しません。HTTPやHTTPS以外のServiceをインターネットに公開するときは、[Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport)や[Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer)のServiceタイプを使用することが多いです。
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タイプを使用することが多いです。

## Ingressを使用する上での前提条件

Expand Down Expand Up @@ -74,8 +74,8 @@ spec:
servicePort: 80
```

他の全てのKubernetesリソースと同様に、Ingressは`apiVersion`、`kind`や`metadata`フィールドが必要です。設定ファイルの利用に関する一般的な情報は、[アプリケーションのデプロイ](/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)などがあります。
他の全てのKubernetesリソースと同様に、Ingressは`apiVersion`、`kind`や`metadata`フィールドが必要です。設定ファイルの利用に関する一般的な情報は、[アプリケーションのデプロイ](/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コントローラー](/docs/concepts/services-networking/ingress-controllers)の種類が異なれば、サポートするアノテーションも異なります。サポートされているアノテーションについて学ぶために、ユーザーが使用するIngressコントローラーのドキュメントを確認してください。

Ingress [Spec](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)は、ロードバランサーやプロキシーサーバーを設定するために必要な全ての情報を持っています。最も重要なものとして、外部からくる全てのリクエストに対して一致したルールのリストを含みます。IngressリソースはHTTPトラフィックに対してのルールのみサポートしています。
Expand All @@ -86,7 +86,7 @@ Ingress [Spec](https://git.k8s.io/community/contributors/devel/sig-architecture/

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

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

Expand Down Expand Up @@ -183,7 +183,7 @@ IngressコントローラーはService(`service1`、`service2`)が存在する
構築が完了すると、ADDRESSフィールドでロードバランサーのアドレスを確認できます。

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

### 名前ベースの仮想ホスティング
Expand Down Expand Up @@ -392,8 +392,9 @@ Ingressと関連するリソースの今後の開発については[SIG Network]
Ingressリソースに直接関与しない複数の方法でServiceを公開できます。

下記の2つの使用を検討してください。
* [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer)
* [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport)

* [Service.Type=LoadBalancer](/ja/docs/concepts/services-networking/service/#loadbalancer)
* [Service.Type=NodePort](/ja/docs/concepts/services-networking/service/#nodeport)

{{% /capture %}}

Expand Down
Loading