より転載https://blog.csdn.net/huwh_/article/details/75675761
1.コントローラマネージャプロファイル
コントローラーマネージャー内部管理コントロールセンターのクラスタとして、クラスタ内の責任ノード、ポッドコピーサービスエンドポイント（エンドポイント）、名前空間（名前空間）、サービスアカウント（ServiceAccount）、リソース割当量（ResourceQuota）管理、ときノード計画外のダウンタイム、コントローラマネージャは、クラスタが期待される動作条件に常にあることを保証するために検出し、自動修復プロセスを実行します。
各コントローラインタフェースAPIサーバーによって各リソース・オブジェクトの現在の状態は、障害がシステムの状態変化の様々な得発生した場合、システムは、に状態を修復しようとし、クラスタ全体のリアルタイム監視を提供する「とは、所望の状態。」
2.レプリケーション・コントローラ
と区別するためには、リソースが複製コントローラRCと呼ばれるオブジェクトを、この記事では、コントローラのコピーと呼ばれ、複製コントローラのコントローラマネージャを指します。関連RCのポッドコピー内のクラスタの数を確保することで、コントローラのレプリカは、予め設定された値のままです。
1は、ポッドは常に戦略を再起動している場合にのみとき（RestartPolicy =常に）、コントローラのコピーが（など、破壊し、再起動を作成する）ポッドの操作を管理します。
2、ポッドテンプレートRCは、それが彼らの間では関係ありません、金型のうち、左後、金型は、ものづくり、カビのようなものです。ポッドが作成されたら、テンプレートの変更は、ポッドには影響しませんどんなにが作成されています。
図3は、PODが制御ラベルRCを変更することによって解放することができる、方法は、クラスタからのデータ修復のデバッグをポッドを移行するために使用することができます。
図4は、RCポッドを使用すると、ポッドを削除したい場合はRCプロパティのコピーを必要な数が0に設定されている、それが作成するには影響しません削除します。
図5は、RCがコントロールポッドを自動化することができるので、RCは、ポッドを作成した横断災害復旧機能を改善しません。
2.1。レプリケーションコントローラ義務
1は、クラスタのみNポッドの例では、NはRCポッドのコピー数が定義されていることを確認します。
図2に示すように、システムの拡張がspec.replicas RCにおける体積減少または属性値を調整することによって達成されます。
RCポッドテンプレートを変更してシステムをアップグレードローリングを実装するための3、。
2.2。レプリケーションコントローラーの使用シナリオ
| 利用シナリオ | 説明 | コマンドを使用します。 |
| 再スケジューリング | ノード障害または予期しない終了がポッドが実行されている場合は、クラスタがまだ指定され実行されていることを保証するために、コピーの数を再スケジュールすることができます。 | |
| 伸縮性 | 手動または自動プロキシ拡張コントローラspec.replicasプロパティのコピーが弾性伸縮性を達成することができる修理。 | kubectlスケール |
| ローリングアップデート | kubectlコマンドまたはAPIを実行することにより、新たなRCファイルを作成し、それが新しいコピーを追加し、古いコピーを削除し、0時に古いコピーである、古いRCを削除します。 | kubectl圧延更新 |
ローリング・アップグレードの特定の参照kubectlローリング更新--help、公式ドキュメントします。https：//kubernetes.io/docs/tasks/run-application/rolling-update-replication-controller/
[ルート@ NODE5〜]＃kubectlローリング更新は--help 与えられたReplicationControllerのローリング更新を実行します。 使用するために一度に一つのポッドを更新することにより、新しいレプリケーションコントローラと指定されたレプリケーションのコントローラを置き換える 新しいPodTemplateを。新controller.jsonは、同じ名前空間を指定する必要があり 、既存のレプリケーション・コントローラとそのreplicaSelectorに少なくとも一つの（共通）ラベルを上書きします。 使用法： kubectl rollingupdate OLD_CONTROLLER_NAME（[NEW_CONTROLLER_NAME] --image = NEW_CONTAINER_IMAGE | -f NEW_CONTROLLER_SPEC）[フラグ] 別名： rollingupdate、rollingupdate 例： フロントエンド-V2に新しいレプリケーションコントローラデータを使用してフロントエンド-V1の＃更新ポッド。 JSON。 $ kubectl rollingupdateフロントエンド-V1 -fフロントエンド-v2.json 標準入力に渡されたJSONデータを使用してフロントエンド-V1の＃更新ポッド。 $猫のフロントエンド-v2.json | kubectlローリング・アップデート・フロントエンド-V1 -f - ちょうど画像を変更し、切り替えることにより、フロントエンド-V2へのフロントエンド-V1のポッド＃更新 複製コントローラの＃名を。 V2：$ kubectlローリング更新フロントエンド-V1-V2のフロントエンド--image =画像 だけで画像を変更し、古い名前を保つことによって、フロントエンドの＃更新ポッド のフロントエンド--image =画像の$ kubectlローリングアップデートを：v2の
ノードコントローラ3
の起動ノード情報APIサーバーでkubeletレジスタ自体、及びAPIサーバーへレポートステータス情報にタイミング、etcdに更新情報を受信するAPIサーバー。
関連情報へのAPIサーバノードのリアルタイムのアクセスを介してノードコントローラは、各ノードのノード管理の関連する制御機能を実現し、クラスタの監視をします。次のようにプロセスは以下のとおりです。
1、Controller Manager在启动时如果设置了--cluster-cidr参数，那么为每个没有设置Spec.PodCIDR的Node节点生成一个CIDR地址，并用该CIDR地址设置节点的Spec.PodCIDR属性，防止不同的节点的CIDR地址发生冲突。
2、具体流程见以上流程图。
3、逐个读取节点信息，如果节点状态变成非“就绪”状态，则将节点加入待删除队列，否则将节点从该队列删除。
4. ResourceQuota Controller
资源配额管理确保指定的资源对象在任何时候都不会超量占用系统物理资源。
支持三个层次的资源配置管理：
1）容器级别：对CPU和Memory进行限制
2）Pod级别：对一个Pod内所有容器的可用资源进行限制
3）Namespace级别：包括Pod数量、Replication Controller数量、Service数量、ResourceQuota数量、Secret数量、可持有的PV（Persistent Volume）数量
说明：
1、k8s配额管理是通过Admission Control（准入控制）来控制的；
2、Admission Control提供两种配额约束方式：LimitRanger和ResourceQuota；
3、LimitRanger作用于Pod和Container；
4、ResourceQuota作用于Namespace上，限定一个Namespace里的各类资源的使用总额。
ResourceQuota Controller流程图：
5. Namespace Controller
用户通过API Server可以创建新的Namespace并保存在etcd中，Namespace Controller定时通过API Server读取这些Namespace信息。
如果Namespace被API标记为优雅删除（即设置删除期限，DeletionTimestamp）,则将该Namespace状态设置为“Terminating”,并保存到etcd中。同时Namespace Controller删除该Namespace下的ServiceAccount、RC、Pod等资源对象。
6. Endpoint Controller
Service、Endpoint、Pod的关系：
Endpoints表示了一个Service对应的所有Pod副本的访问地址，而Endpoints Controller负责生成和维护所有Endpoints对象的控制器。它负责监听Service和对应的Pod副本的变化。
1、如果监测到Service被删除，则删除和该Service同名的Endpoints对象；
2、如果监测到新的Service被创建或修改，则根据该Service信息获得相关的Pod列表，然后创建或更新Service对应的Endpoints对象。
3、如果监测到Pod的事件，则更新它对应的Service的Endpoints对象。
kube-proxy进程获取每个Service的Endpoints，实现Service的负载均衡功能。
7. Service Controller
Service Controller是属于kubernetes集群与外部的云平台之间的一个接口控制器。Service Controller监听Service变化，如果是一个LoadBalancer类型的Service，则确保外部的云平台上对该Service对应的LoadBalancer实例被相应地创建、删除及更新路由转发表。
参考《Kubernetes权威指南》