展開の最初に、概念
K8S自体がネットワークの機能を提供していない、サードパーティのプラグインネットワーク展開は、容器の交換を開放するために、ネットワークは、各ノードをK8S使用する必要があります。
PODは、K8Sの論理的な概念であり、K8S管理がPODで、PODがインターワーキングlocalhostを介して容器との間の複数の容器を含みます。PODは、IPアドレスが必要です。各PODは、ラベルを持っています
POD-> RC-> RS->展開（開発）
展開は、ユーザK8Sクラスタの動作の更新を表します。展開が適用されたAPIオブジェクトモデルのRSよりも広くなっています。ポッドの部数ことを保証するために。
あなたはそれがローリング・アップグレードサービスすることができ、新しいサービス、新しい更新サービスを作成することができます。ローリング・アップグレードサービス。RSの非常に良い説明と、このような複合操作があり、実際に新しいRS、RS、そのコピーの新しい番号が古い複合操作RS 0のコピーの数を減らし、状態の上に増加しているの作成ように、より一般的な用途展開について説明しました。
RC、RSと展開のみPODサポートサービスの数は、これらのサービスにアクセスする方法の問題を解決しないことを確実にします。PODは、実行中のサービスのインスタンスだけで、あなたは、1つのノードで停止し、別の新しいIPノードに新しいPODを開始し、そのためのサービスを提供するために、IPとポート番号を確認することができないことができるかもしれません。
着実にサービスに必要なサービスの発見とロードバランシング機能を提供します。サービス検出は、対応するインスタンスを見つけるために、クライアントアクセス用に、バックエンドサービスをサービス作業を完了します。
クライアントに集中K8Sではそのサービスオブジェクトサービスにアクセスする必要があります。クラスタは仮想IP、仮想クラスタサービスを介して内部IPアクセスに対応して内の各サービスが有効になります。
要約手順を作成しました：
（1）kubectl展開することにより、ユーザが作成しました
（2）展開さらにreplicaSetを作成
（3）さらにreplicaSetポッドを作成します
まず、イングレスは何ですか？
私たちは、クラスタサービスへの外部アクセスを提供する必要があり、次の質問があります。LoadBlancerサービス、ExternalName、NodePortサービス、イングレスは：これまでの研究から、我々はKubernetes公開されたサービスは、現在3つしかありの方法を理解することができます
図1に示すように、ポッドドリフト
Kubernetesは、自動的に新しいスタートを確実にするために、またコピー内の他のマシンからの動的拡張や他の普通の言葉（ポッド）がハングアップすることができ、ポッドは、いつでも任意のノードに表示されることがあり、制御するための強力な能力をコピーしますあなたは、任意のノード上の任意の時点で死亡することも、創造と破壊のポッド、ポッドIP動的に変更することを確認してとても自然、そしてどのようにこのダイナミックなポッドIPはにさらさ？ここではサービス機構のKubernetesにより、サービスはラベルとして指定されたラベルを持つポッドのグループを選択し、監視し、自動的にそのポッドIPをロードし、その後、我々は、リスト上でのみサービスIP外部に露出し公開することができます。これはNodePortですモード：すなわち内部ポッドIPに転送し、各ノード上のポートを開き、によって、
2、ポート管理
問題に直面するNodePortの方法を使用してサービスを公開するサービスが一度掛けることで、NodePortは、各ノードをオンにし、そのポートを維持するために大規模かつ困難になります。この時間は、我々はそれを転送するために、直接内部nginxのを使用することができますか？これはよく知られており、彼らは互いにポッドポッドと通信することができ、ポッド、共有することができ、共有ネットワーク内の名前空間は、ポッドは、ノードのポートで待機しているとき、ホスト空間のネットワーク名は、それがあります。だから、これはどのように達成すべき？単純な実装はDaemonSetは、次にルールを記述、各ノードで80を監視する外部nginxのは、クラスタ内で、（NodePortように）それ自体をホストポート80に結合するため、戻し適切なサービスIPに直接転送するために使用することですライン上で、
3、ドメイン名の割り当てと動的更新の問題
上記の方法から、nginxの-ポッドを使用して問題を解決しているようだが、実際には大きな欠陥がある：新しいサービスがどのようにnginxの構成とを追加されるたびにそれを修正するには？？私たちは、使用してnginxのは、仮想ホストドメイン名によって異なるサービスを区別することができることを知って、各サービスは、上流のロード・バランシング・プールによって異なって定義され、プラス負荷がリバースプロキシのバランスをとるための場所は、唯一の毎日の使用でnginxのを修正する必要があります。 confが、その後、どのようにそれでK8Sにおけるスケジューリングのこの方法を達成するために実現することができますか？？？
、バックエンドサービスの初期サービスのみecshopと仮定すると、後でこれら2つのサービスが、それをスケジュールnginxの-ポッドに追加すべきか、その後、掲示板や会員サービスの増加？常に手動で変更またはローリングアップデート遠位nginxのポッドことはできません！！イングレスコントローラとイングレス：イングレスは、この時点では、そうでない場合はnginxの上に登場し、イングレスは、2つの主要コンポーネントが含まれています。
イングレスこれは単にあなたがオリジナルのnginxの設定を変更してからサービスを対応するドメイン名のさまざまな設定、イングレスオブジェクトに抽象化今、このアクションする必要があることを意味し、あなたがYAMLを作成することができ、移動して、変更するすべてのnginxのを、直接変更しないでください質問があるので、YAMLは、リスト上で作成/更新：「nginxのをどのように扱いますか？」
自分のテンプレートに従って、いくつかのnginxの構成を生成するために、そして彼を読んで、イングレスクラスタを知覚するために、動的ルール変更、Kubernetesと対話するためのAPIを介して進入Controoler、その後、nginxのを書いた;侵入コントローラは、「nginxの処理モード」、この事を解決することですポッド、そして最終的にそれをリロードし、
イングレスは、実際にはKubernetes APIの標準的なリソースの種類の一つであり、それは実際には、前方URLパスであるルールにDNS名（ホスト）または要求のセットに基づいてサービスリソースを指定します。完了したクラスタ内で発行されたクラスタサービス要求の外にトラフィックを転送します。私たちは、イングレスリソース自体が「流れの浸透」ではない、あるルールの単なる集合体であることを理解する必要があり、これらのルールはまた、リスニングソケットなどの追加機能の補助セットを必要として、規則に従ってこれらのルートと一致します前方に、これらのリソースは、ソケットと流れアセンブリが進入コントローラーでリスニングのIngressに転送することができます。
PS：イングレス展開コントローラは、コントローラとは異なり、コントローラが直接進入部分KUBE-コントローラ・マネージャとして動作しない、それだけで、クラスタの添付ファイルは、同様のCoreDNSをKubernetesである、あなたは、単一のクラスタにデプロイする必要があります。
サービスの最初に、概念
ポッドで実行中のアプリケーションは、このようなコントローラのリソースオブジェクトによって制御されているetcdなどnginxの、Tomcatの、、、などのクライアントデーモンサービスに提供され、ライフサイクルがあり、私たちは知っているポッド資源や自主内のオブジェクト不随意端末後、唯一の置換ポッドオブジェクトが再構成された、非再生可能ベースのコンポーネントです。動的かつ柔軟な管理では、サービスにアクセスし、クラスポッド・オブジェクトの機能をロードバランシングするための安定した、統一されたインタフェースを提供します。それは言葉の束がかなりそれを理解していなかったということではないでしょうか？？？？
実際には、ポッドのライフサイクルがあることを、クライアントへの固定アクセスインタフェースを提供することはできません、再構築があり、そこに破壊されています。そして、作業負荷の類似したポッド値、そこに、それによってサービスリソースを達成することができるようにするためには、アリの雲やLVS負荷分散機能のようなクラスポッドリソースオブジェクトとして均衡固定アクセスインターフェイスと負荷を提供することができます。
しかし、知っている、IPアドレスであり、ポッドServiceオブジェクト、仮想アドレスは、1がポッドIPアドレスで、クラスタ内でのみアクセス可能な、クラスタは外部トラフィックにアクセスすることはできません。単一のネットワーク・ノード上でこの種の問題は、（HOSTPORT）が露出ポートを行うための方法することができます解決し、共有作業スペースポッドノードのリソース（hostNetwork）の名前を可能にするために、あなたはまた、サービスのリソースのNodePortやロードバランサのタイプを使用することができ、またはリソースのIngress層7のロードバランシング機能があります。
サービスは、それをコアKubernetesリソースタイプ、ポッド、ポッドの論理的組合せに選択のセットを定義するタグ・サービスに基づくリソースの一つであり、以下に示すように、自身のIPアドレスとポートスケジューリングエージェントによってグループ内のオブジェクトを要求しますビューのクライアントの観点から、サービスやロードバランサなどの直接応答によって処理されたとして、それを好きではないように、クライアントは本当に、ユーザーの要求ポッドリソースを扱う、隠されています！
またKubernetesクラスタのIPアドレス範囲に充て構成内に配置されているクラスタIPとして知られているサービスオブジェクトのIPアドレスは、サービスオブジェクトの作成後に変更されないままの仮想IPアドレスであり、同じクラスタ内にあることができますアクセスポッドリソース。クライアント要求を受信するためのサービスポート、及び、トランスポート層のTCP / IPプロトコルスタックに基づいてポート剤として知られているようなプロキシ機構、各ポートポッドアプリケーションの後端に要求を転送します。
二、サービスの実装モデル
Kubernetesクラスタでは、各ノードがKUBE-プロキシプロセスを実行します。KUBE-プロキシは、サービスがVIPむしろExternalNameの形よりも（仮想IP）の形を、実装のために責任があります。Kubernetes v1.0のバージョンでは、ユーザー空間で完全に行動します。Kubernetes v1.1のバージョンではデフォルトの動作モードをiptablesのエージェントが追加されますが、ありません。以降Kubernetesバージョン1.2からは、デフォルトではiptablesのエージェントです。Kubernetesではv1.8.0-beta.0はIPVSエージェントを追加しました。Kubernetes v1.0のバージョンでは、サービスは、 "レイヤ4"（TCP / UDP IP経由）の概念です。Kubernetes v1.1のバージョンではイングレスAPI（ベータ版）を追加し、「7層」（HTTP）サービスを表すために使用されます。
KUBE-プロキシこのコンポーネントは、サービスと、時計を監視することで、サービスに関するapiserver情報の変更がサービスに関連するすべてのリソースの状態の変化へのアクセスを追跡し、資源関連の変更を作成し、KUBE-プロキシは、現在のノードに変換する必要があります可能なリソーススケジューリングルール上（例：iptablesの、IPVS）
2.1、ユーザー空間プロキシモード
クライアントがサービスのiptablesのポッドカーネル空間、ユーザーの聴取空間にポートKUBE-プロキシにリクエストを要求したとき、このモードでは、カーネル空間へKUBE-プロキシ、そしてKUBE-プロキシ要求によって後処理次に、サービスIP、およびサービスiptalbesによる要求に応じて、各ノードにサービスポッドに移しました。
これはKUBE-プロキシパッケージがで完了し、その後、iptablesの規則に従って配布された後で、このモデルは、ユーザ空間とアクセスKUBE-プロキシにカーネル空間を入力するように、クライアントから要求され、大きな問題があることを示し、iptablesのカーネル空間各ノードへのユーザ空間ポッド。パフォーマンスのコア損失からユーザ空間からアウトこのようなトラフィックは受け入れられません。Kubernetes 1.1バージョンの前に、ユーザ空間はデフォルトのプロキシモデルです。
2.2は、プロキシモードをiptablesの
iptable NAT転送を使用して達成、また、パフォーマンスの無視できない損失があるため、IPクライアント要求、直接ローカルサービスIPを要求するカーネルは、各ポッドにルールに転送されますが、直接の要求をiptablesの。サービス/エンドポイントクラスタの数千人がある場合に加えて、ノード上のiptablesのルールは非常に大きくなり、パフォーマンスが割り引かれます。デフォルトタイプの初めからKubernetesバージョン1.1、バージョン1.2で導入されたiptablesのエージェントモデル。
2.3、IPVSプロキシモード
1.9アルファリリースからKubernetesは、バージョン1.11のデフォルト設定のため、IPVSプロキシモードを導入しました。到着IPカーネル空間のクライアント要求は、ルールのIPVSに応じて、直接各ポッドに配布します。KUBEプロキシオブジェクトとKubernetesサービスエンドポイントを監視し、それに応じてIPVSルールを作成するためのnetlinkインターフェースを呼び出して、定期的にKubernetesサービスエンドポイントオブジェクトと予想と一致IPVS状態を確保するために、ルールIPVSオブジェクトを同期させます。サービスにアクセスすると、トラフィックは、バックエンドポッドのいずれかにリダイレクトされます。
そして、iptables同様に、IPVSベースのnetfilterフック関数が、基礎となるデータ構造としてハッシュテーブルを使用して、カーネル空間で動作します。これはIPVSが速くトラフィックをリダイレクトし、プロキシルールを同期するときに、より良い性能を持っていることを意味します。また、IPVSのような負荷分散アルゴリズムのためのより多くのオプションを、提供します。
RR：ロビンスケジューリング
LC：接続の最小数
DH：ターゲット・ハッシュ
SH：ソース・ハッシュ
SED：最短予想遅延
NQ：スケジュールをラインアップしていません
注意：IPVSモデルは、IPVSカーネルモジュールがインストールされているノード上で実行する前に、KUBE-プロキシを前提としています。IPVS KUBEプロキシプロキシモードに作動されたとき、KUBEプロキシノードモジュールIPVSをインストールするかどうかを検証し、インストールされていない場合、KUBEプロキシiptablesのプロキシモードにフォールバックします。
サービスのバックエンドポッドは、情報がKUBE-プロキシが情報の変更などを見ることができるようになりながら、apiserverに適応し、そしてそれはすぐにオンになりますすぐに反映されますどのようにポッドのタグセレクタ適応を変更した場合このすべてでIPVSまたはiptablesのルールダイナミックかつリアルタイムで、ポッドを削除すると同じ原理です。
四、ヘッドレスサービス
時には、バランス、および個別のサービスIPをロードする必要か必要はありません。このような場合には、「なし」のヘッドレスサービスクラスタIP（spec.clusterIP）値を指定して作成することができます。
このオプションは、開発者が自由にすることにより、結合してKubernetesシステムを減らし、独自の方法を模索することができます。アプリケーションは、まだ簡単に他のメカニズムを見つける必要があるシステムを構築することは、このAPIに基づくことができる、自己登録モデルやアダプタを使用することができます。
クラスタのIPとは、このようなサービスに割り当てられていないだろう、KUBE-プロキシそれらに対処しませんが、プラットフォームが均衡し、それらのルーティングをロードしません。どのように応じて、自動設定をDNSサービスセレクタの定義かどうか。
図1に示すように、ポッド・リソース・オブジェクト
ポッドリソースオブジェクトは、アプリケーションコンテナの1つ以上の論理コンポーネント、ストレージリソースの専用IP、その他のサポートオプションの操作のコレクションです。
Kubernetesネットワークモデルは、各ポッドの同じIPネットワークIPアドレスセグメントは、IPクラスタポッドラン内のどのノードに関係なく、ポッドアドレス種々間の通信のために使用することができる必要があり、同様に動作するローカル・エリア・ネットワークに類似しているポッドオブジェクト一般的には仮想マシン。
我々はポッドポッドは、各オブジェクトが同じポッドオブジェクトに複数のプロセスを実行する物理ホストまたは仮想マシンに類似しているオブジェクトができ、それは物理ホスト上で動作している独立したプロセスと同様であるが、違いがです各プロセスは、容器の中に互いに分離して実行され、そして種々の容器の間で共有重要なリソースの二種類：ネットワークおよびストレージボリューム。
ネットワーク：各被験者は、ホスト名、IPアドレスとポートを含め、ポッドポッドIPアドレスに同じ内部ネットワークの共有ポッドとポッドUTS名前空間オブジェクトのすべてのコンテナが割り当てられます。ポッド以外の構成要素と通信し、リソース・オブジェクトのクラスタサービス+完全なIPポートを使用する必要がありつつ、これらの容器は、ローカルループバックインタフェースLOを介して通信することができます。
ストレージボリューム：これにより、ユーザはコンテナ間のデータ共有を完了し、同じポッド内で使用される全てのコンテナのために共有することができるリソースのポッド・ストレージ・ボリュームにオブジェクトのセットを構成することができます。ストレージボリュームも終了コンテナ後に再起動を保証し、または永続的なデータストレージを削除した後に確保することができます。
ポッドは、アプリケーションの特定のインスタンスを表し、私たちは、このアプリケーションを拡張する必要がある場合、それはあなたがアプリケーションに同時にポッドを複数のインスタンスを作成する必要があることを意味し、各インスタンスは、アプリケーションの実行中のコピーを表します。これらは、作成したオブジェクトのポッド・コピーを管理する、オブジェクトは、展開制御対象として、コントローラと呼ばれるグループによって達成されます。
ポッドを作成するとき、我々はまた、このようなConfigmap、シークレット、ストレージボリューム、ボリュームのマウント、およびその他の環境変数としてポッドのための具体的な情報、のポッドプリセット目標噴射を使用することができます。ポッドプリセットオブジェクトを使用すると、ポッドテンプレートを作成すると、すべての情報は、各テンプレートに表示されて提供する必要はありません。
、リソースの可用性に基づいて、所定の動作及び各ノードの所望の状態は、作業ノード、倉庫からノードダウンロード作業鏡像点上の選択されたオブジェクトへのポッドのマスタースケジュールは、動作中のコンテナ船のローカル環境で起動するであろう。マスター状態はでetcdでクラスタ全体を保存し、APIサーバーによってさまざまなコンポーネントとクライアントのクラスタに共有することになります。
2、コントローラ
デザインはでK8Sクラスタでは、ポッドは、オブジェクトのライフサイクルです。それは削除され、正常に終了するまで、コンテナアプリケーションプロセスの実行後、コントローラポッドオブジェクトから直接手によって作成された、または作成されたユーザは、クラスタ内のワーキングノードでスケジュールスケジューラ（スケジューラ）が実行されます。そして、資源の枯渇やノードの障害時に、ことに留意すべきである、回復ポッドオブジェクトにつながることができます。
そして、この設計ではK8S、使い捨てのコントローラポッドオブジェクト管理操作の使用。例えば、アプリケーションのユーザの予想数を達成するために配備され、拡張ポッド、体積減少、ロールオーバーおよび自己修復機能の目的を達成するために、ポッドポッドオブジェクト、等を再構築するためのテンプレートに基づいてのコピーのポッドの数を確保します。例えば、ノード障害、コントローラは、他のノードの再構成を再スケジュールするノードでポッド関連付けられたオブジェクトを実行します。
コントローラ自体は、集合的にポッドコントローラと呼ばれている等の複製、コントローラ、展開、StatefulSet、DaemonSet、ジョブを含むリソースタイプ、です。展開は以下コントローラの実装のこのタイプの代表であり、コントローラは、ポッドステートレスなアプリケーションを管理するために使用されます。
ポッド定義されたコントローラは、典型的には、コピーの所望の数、ポッドテンプレートタグセレクタで構成されています。ラベルタグセレクタに係るポッドオブジェクトのフィルタに一致するようにポッドコントローラは、すべての選択基準を満たすポッドオブジェクトは、状態の数は、コピーの所望の数を達成することができることを保証するために管理するための電流コントローラおよびコピーの総数に含まれます。
実用的なアプリケーションシナリオにおいて、要求は、トラフィック負荷がより少ない又はポッドの既存のコピーの電流容量に近接してい受信なお、必要なコピーの所望の数を手動規模なアプリケーションを実現するために私達のポッド制御を変更します伸縮を収容。リソース監視プロメテウスヒープセットまたはクラスター内のこのタイプのアセンブリを展開するとき、ユーザは、HPA（HorizontalPodAutoscaler）はコピーポッドの適切な数を計算することができ、かつ自動的に達成するために、コピーのポッドコントローラ所望の数を変更しますストレッチングダイナミック規模アプリケーションは、クラスタリソースの利用率を向上させます。
クラスタ内の各ノード上のK8SがcAdvisorを実行し、容器とデータが住んでノードのCPU、メモリ、およびディスクリソースの使用状況を収集し、これらの統計は、APIサーバーによってHeapsterの重合後にアクセスすることができます。そしてHorizontalPodAutoscalerは、コンテナの健康状態を監視し、拡張意思決定を行うためにこれらの統計に基づいています。
3、サービス
私たちは、オブジェクトがポッドポッドIPアドレスがあることを知っているが、アドレスは、オブジェクトが、再起動後に同じままであることを確認するか、ポッドのメンテナンストラブル間のクラスタアプリケーションの依存関係をもたらすポッドを再構築することはできません。例えば、前のポッドポッドベースのアプリケーションは、バックエンドで固定IPアドレスを使用することはできません。
サービスおよびリソースを有するポッドオブジェクトがアクセスされた中間層の固定IPアドレスを追加することで、クライアントは、オブジェクトポッドの後端に関連付けられたサービススケジューリングとリソース・エージェントによって、このアドレスへのアクセス要求を開始します。
サービスは、特定のコンポーネントではなく、一緒に集合ポリシーオブジェクトポッドへのアクセスを、ポッドルールにより形成された複数のオブジェクトの論理的なセットを定義します。サービスオブジェクト選択およびオブジェクトと関連するポッドコントローラポッドが同じであるようにして、タグセレクタによって定義されます。図は次のとおりです。
10.96.0.0/12ネットワーク、システムによって動的範囲内のサービスオブジェクトのIPアドレス：IPサービスのような一般的に使用される独自のアドレス、クラスタ通信専用クラスタIPと呼ばれる仮想IP、あります割り当て。
このような直接要求のクラスタのクラスタIP内のポッドオブジェクトは、クライアントポッドからのアクセス要求上図のように、クラスタサービスは、宛先アドレスとしてIPを介してアクセスすることができるが、クラスタネットワークアドレスがプライベートネットワークに属するで、のみであってもよいですクラスタ内のアクセス。
従来の方法は、クラスタのクラスタの外部への内部アクセスを必要とする以下の通りである方法ネットワークノードを導入することによって行われます。
リクエストIPアドレス+ポート作業ノード（ノードのポート）にアクセス。
適切なサービスのクラスタオブジェクトのIPサービスポートへの要求に作用する、素人の用語は：作業ノードマップポートサービスのポートがあります。
リスニングポートは、サービスへの要求は、オブジェクトポッドポッドやIPアプリケーションの後端をオブジェクトに転送します。
したがって、Exxternalクライアントから外部のクライアントクラスタのビューに似ては、直接クラスタサービスのIPを要求しますが、IPアドレスのノード（例えばノードY）を介して達成するために仕事をする必要はありませんが、転送要求が2回必要ですポッドは、ターゲットオブジェクトを取得します。このタイプのアクセスの欠点は、通信効率に一定の遅延です。