Fix misc things.
This commit is contained in:
TAKAHASHI Shuuji
@@ -19,10 +19,10 @@ Kubernetesを機能させるには、*Kubernetes API オブジェクト* を使
|
||||
|
||||
一旦desired state (望ましい状態)を設定すると、Pod Lifecycle Event Generator([PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md))を使用した*Kubernetes コントロールプレーン*が機能し、クラスターの現在の状態をdesired state (望ましい状態)に一致させます。そのためにKubernetesはさまざまなタスク(たとえば、コンテナの起動または再起動、特定アプリケーションのレプリカ数のスケーリング等)を自動的に実行します。Kubernetesコントロールプレーンは、クラスターで実行されている以下のプロセスで構成されています。
|
||||
|
||||
* **Kubernetes Master** :[kube-apiserver](/docs/admin/kube-apiserver/)、[kube-controller-manager](/docs/admin/kube-controller-manager/)、[kube-scheduler](/docs/admin/kube-scheduler/) の3プロセスの集合です。これらのプロセスはクラスター内の一つのノード上で実行されます。実行ノードはマスターノードとして指定します。
|
||||
* **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と通信します。
|
||||
* **[kube-proxy](/docs/admin/kube-proxy/)**, 各ノードのKubernetesネットワークサービスを反映するネットワークプロキシです。
|
||||
* **[kubelet](/docs/admin/kubelet/)**: Kubernetes Masterと通信します。
|
||||
* **[kube-proxy](/docs/admin/kube-proxy/)**: 各ノードのKubernetesネットワークサービスを反映するネットワークプロキシです。
|
||||
|
||||
## Kubernetesオブジェクト
|
||||
|
||||
|
||||
@@ -26,9 +26,8 @@ RuntimeClassはコンテナランタイムの設定を選択するための機
|
||||
|
||||
### セットアップ
|
||||
|
||||
RuntimeClass機能のFeature Gateが有効になっていることを確認してください(デフォルトで有効です)。Feature Gateを有効にする方法については、[Feature
|
||||
Gates](/docs/reference/command-line-tools-reference/feature-gates/)を参照してください。
|
||||
その`RuntimeClass`のFeature GateはApiServerとkubeletのどちらも有効になっていなければなりません。
|
||||
RuntimeClass機能のフィーチャーゲートが有効になっていることを確認してください(デフォルトで有効です)。フィーチャーゲートを有効にする方法については、[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を参照してください。
|
||||
その`RuntimeClass`のフィーチャーゲートはApiServerとkubeletのどちらも有効になっていなければなりません。
|
||||
|
||||
1. ノード上でCRI実装を設定する。（ランタイムに依存）
|
||||
2. 対応するRuntimeClassリソースを作成する。
|
||||
|
||||
@@ -48,7 +48,7 @@ Kubernetesは...
|
||||
|
||||
* サポートするアプリケーションの種類を限定しません。Kubernetesはステートレス、ステートフル、およびデータ処理ワークロードなど、非常に多様なワークロードをサポートするように作られています。アプリケーションをコンテナ内で実行できる場合は、Kubernetes上でもうまく動作するはずです。
|
||||
* ソースコードのデプロイやアプリケーションのビルドを行いません。継続的インテグレーション、デリバリー、デプロイ(CI/CD)ワークフローは、技術選定がそうであるように、組織の文化や好みによって決まるからです。
|
||||
* ミドルウェア(例: message buses)、データ処理フレームワーク(例: Spark)、データベース(例: mysql)、キャッシュ、クラスターストレージシステム(例: Ceph) のような、アプリケーションレベルの機能は組み込みでは提供しません。これらのコンポーネントはKubernetesの上で動作できますし、Open Service Brokerのようなポータブルメカニズムを経由してKubernetes上のアプリケーションからアクセスすることもできます。
|
||||
* ミドルウェア(例: メッセージバス)、データ処理フレームワーク(例: Spark)、データベース(例: mysql)、キャッシュ、クラスターストレージシステム(例: Ceph) のような、アプリケーションレベルの機能は組み込みでは提供しません。これらのコンポーネントはKubernetesの上で動作できますし、Open Service Brokerのようなポータブルメカニズムを経由してKubernetes上のアプリケーションからアクセスすることもできます。
|
||||
* ロギング、モニタリング、アラーティングソリューションへの指示は行いません。概念実証(PoC)としていくつかのインテグレーション、およびメトリックを収集およびエクスポートするためのメカニズムを提供します。
|
||||
* 設定言語/システム(例： jsonnet)を提供も強制もしません。任意の形式の宣言仕様の対象となる可能性がある宣言APIを提供します。
|
||||
* 包括的なインフラ構成、保守、管理、またはセルフヒーリングシステムを提供、導入しません。
|
||||
@@ -57,7 +57,7 @@ Kubernetesは...
|
||||
|
||||
## なぜコンテナなのか？
|
||||
|
||||
なぜコンテナを使うべきかの理由をお探しですか？
|
||||
コンテナを使うべき理由をお探しですか？
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -78,7 +78,7 @@ kubectl config view --minify | grep namespace:
|
||||
## NamespaceとDNS
|
||||
|
||||
ユーザーが[Service](/ja/docs/concepts/services-networking/service/)を作成するとき、Serviceは対応する[DNSエントリ](/ja/docs/concepts/services-networking/dns-pod-service/)を作成します。
|
||||
このエントリは`<service-name>.<namespace-name>.svc.cluster.local`という形式になり,これはもしあるコンテナがただ`<service-name>`を指定していた場合、Namespace内のローカルのServiceに対して名前解決されます。
|
||||
このエントリは`<service-name>.<namespace-name>.svc.cluster.local`という形式になり、これはもしあるコンテナがただ`<service-name>`を指定していた場合、Namespace内のローカルのServiceに対して名前解決されます。
|
||||
これはデベロップメント、ステージング、プロダクションといって複数のNamespaceをまたいで同じ設定を使う時に効果的です。
|
||||
もしユーザーがNamespaceをまたいでアクセスしたい時、 完全修飾ドメイン名(FQDN)を指定する必要があります。
|
||||
|
||||
|
||||
@@ -202,7 +202,7 @@ myapp-pod 1/1 Running 0 9m
|
||||
|
||||
このシンプルな例を独自のInitコンテナを作成する際の参考にしてください。[次の項目](#what-s-next)にさらに詳細な使用例に関するリンクがあります。
|
||||
|
||||
## Initコンテナのふるまいに関する詳細 {#Detailed behavior}
|
||||
## Initコンテナのふるまいに関する詳細 {#detailed-behavior}
|
||||
|
||||
Podの起動時において、各Initコンテナはネットワークとボリュームが初期化されたのちに順番に起動します。各Initコンテナは次のInitコンテナが起動する前に正常に終了しなくてはなりません。もしあるInitコンテナがランタイムもしくはエラーにより起動失敗した場合、そのPodの`restartPolicy`の値に従ってリトライされます。しかし、もしPodの`restartPolicy`が`Always`に設定されていた場合、Initコンテナの`restartPolicy`は`OnFailure`が適用されます。
|
||||
|
||||
|
||||
Reference in New Issue
Block a user