replace link to en
This commit is contained in:
@@ -24,19 +24,19 @@ content_type: concept
|
||||
|
||||
## 設定
|
||||
|
||||
* [ConfigMapを用いたRedisの設定](/docs/tutorials/configuration/configure-redis-using-configmap/)
|
||||
* [ConfigMapを用いたRedisの設定](/ja/docs/tutorials/configuration/configure-redis-using-configmap/)
|
||||
|
||||
## ステートレスアプリケーション
|
||||
|
||||
* [クラスター内のアプリケーションにアクセスするために外部IPアドレスを公開する](/ja/docs/tutorials/stateless-application/expose-external-ip-address/)
|
||||
|
||||
* [例: Redisを使用したPHPゲストブックアプリケーションのデプロイ](/docs/tutorials/stateless-application/guestbook/)
|
||||
* [例: Redisを使用したPHPゲストブックアプリケーションのデプロイ](/ja/docs/tutorials/stateless-application/guestbook/)
|
||||
|
||||
## ステートフルアプリケーション
|
||||
|
||||
* [StatefulSetの基本](/docs/tutorials/stateful-application/basic-stateful-set/)
|
||||
|
||||
* [例: 永続ボリュームを使ったWordPressとMySQLのデプロイ](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/)
|
||||
* [例: 永続ボリュームを使ったWordPressとMySQLのデプロイ](/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/)
|
||||
|
||||
* [例: Stateful Setsを使ったCassandraのデプロイ](/docs/tutorials/stateful-application/cassandra/)
|
||||
|
||||
@@ -50,7 +50,7 @@ content_type: concept
|
||||
|
||||
## サービス
|
||||
|
||||
* [Source IPを使う](/docs/tutorials/services/source-ip/)
|
||||
* [Source IPを使う](/ja/docs/tutorials/services/source-ip/)
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -30,7 +30,7 @@ weight: 10
|
||||
|
||||
<p>Kubernetes Podの寿命は永続的ではありません。実際、<a href="/ja/docs/concepts/workloads/pods/pod/">Pod</a>には<a href="/ja/docs/concepts/workloads/pods/pod-lifecycle/">ライフサイクル</a>があります。ワーカーのノードが停止すると、そのノードで実行されているPodも失われます。そうなると、<a href="/ja/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a>は、新しいPodを作成してアプリケーションを実行し続けるために、クラスターを動的に目的の状態に戻すことができます。別の例として、3つのレプリカを持つ画像処理バックエンドを考えます。それらのレプリカは交換可能です。フロントエンドシステムはバックエンドのレプリカを気にしたり、Podが失われて再作成されたとしても配慮すべきではありません。ただし、Kubernetesクラスター内の各Podは、同じノード上のPodであっても一意のIPアドレスを持っているため、アプリケーションが機能し続けるように、Pod間の変更を自動的に調整する方法が必要です。</p>
|
||||
|
||||
<p>KubernetesのServiceは、Podの論理セットと、それらにアクセスするためのポリシーを定義する抽象概念です。Serviceによって、依存Pod間の疎結合が可能になります。Serviceは、すべてのKubernetesオブジェクトのように、YAML<a href="/docs/concepts/configuration/overview/#general-configuration-tips">(推奨)</a>またはJSONを使って定義されます。Serviceが対象とするPodのセットは通常、<i>LabelSelector</i>によって決定されます(なぜ仕様に<code>セレクタ</code>を含めずにServiceが必要になるのかについては下記を参照してください)。</p>
|
||||
<p>KubernetesのServiceは、Podの論理セットと、それらにアクセスするためのポリシーを定義する抽象概念です。Serviceによって、依存Pod間の疎結合が可能になります。Serviceは、すべてのKubernetesオブジェクトのように、YAML<a href="/ja/docs/concepts/configuration/overview/#general-configuration-tips">(推奨)</a>またはJSONを使って定義されます。Serviceが対象とするPodのセットは通常、<i>LabelSelector</i>によって決定されます(なぜ仕様に<code>セレクタ</code>を含めずにServiceが必要になるのかについては下記を参照してください)。</p>
|
||||
|
||||
<p>各Podには固有のIPアドレスがありますが、それらのIPは、Serviceなしではクラスターの外部に公開されません。Serviceによって、アプリケーションはトラフィックを受信できるようになります。ServiceSpecで<code>type</code>を指定することで、Serviceをさまざまな方法で公開することができます。</p>
|
||||
<ul>
|
||||
|
||||
Reference in New Issue
Block a user