kubectl：クライアントの操作指示を送信するためのK8Sコマンドライン終了。
APIサーバー：フロントエンドインターフェースK8Sクラスタ、クライアントのさまざまなツールやその他のコンポーネントK8Sは、それを介してさまざまなリソースK8Sクラスタを管理することができます。。それはつまりAPI K8S、HTTP / HTTPSのRESTful APIを提供
スケジューラ：ポッドは、どのノードの動作を決定する責任があります。ときにスケジューリングは、クラスタのトポロジの完全なアカウントを取る各ノードの現在の負荷だけでなく、高可用性、パフォーマンス、データの親和性と需要に対処するだろう。
コントローラマネージャ：リソースが状態を期待されていることを確認するためにクラスタリソースを管理する役割を担います。これは、レプリケーション、エンドポイントコントローラ。を含む様々なコントローラー、コントローラーで構成されている
名前空間コントローラー、Serviceaccountsコントローラーのような。
Etcd：状態情報K8Sクラスタ構成情報やさまざまなリソースを節約するための責任。場合は、データの変更、etcdはすぐに通知が関連するコンポーネントをK8Sます。サードパーティのコンポーネントは、それは選択肢を持っています。領事、ZooKeeperの
ポッド：最小構成単位K8Sクラスタ。Aポッドは、1つ以上の容器を実行することができます。ほとんどの場合には、コンテナ内のコンテナだけポッド。
Flanner：クロスホスト通信ポッドを確保することができるK8Sクラスタネットワークソリューションです。サードパーティのソリューション、選択肢があります。
各ノードがどのアプリケーション見る
＃kubectl [〜マスター@ルート]を GETポッド--all-名前空間
詳細については、ノードれるアプリケーション参照
[ルート@マスター〜]＃kubectl GETポッド--all-名前空間は広い-oを
Kubeler：他是Node的agent（代理），当Scheduler确定某个Node上运行Pod之后，会将Pod的具体配置信息发送给该节点的Kubelet,Kubeler会根据这些信息创建和运行容器，并向Master报告运行状态。
Kube-proxy：负责将访问service的TCP/UDP数据流转发到后端的容器。如果有多个副本，kube-proxy会实现负载均衡。
运行一个例子：三台都导入httpd镜像导成docker镜像
创建一个deployment资源对象。Pod控制器。
[root@master ~]# kubectl run test-web --image=httpd --replicas=2
查看节点：
[root@master ~]# kubectl get deployments.
简写：
[root@master ~]# kubectl get deploy
[root@master ~]# kubectl get pod
哪台dang掉重启kuelet:
[root@master ~]# systemctl restart kubelet
[root@master ~]# kubectl get pod -o wide
删除节点：
[root@master ~]# kubectl delete pod test-web-5b56bdff65-j6g75
还是两个：这就是控制器的原因
さまざまなコンポーネントとアーキテクチャのワークフローの役割の分析：
1）kubectl Serverは、APIへのデプロイ要求を送信
2）を展開リソースを作成するためにコントローラーManagerサーバーのAPIを通知
スケジュールされたタスクを実行するために3）スケジューラを、2つのコピーがポッドnode01とnode02でに配布される
4）自分のノードを作成して実行するようにポッド内node01とnode02で上kubelet。
追加：
設定1.アプリケーションとetcd内に格納されている現在のステータス情報は、APIサーバはkubectl GETポッドの実装でetcdからデータを読み込みます。
各ポッド2.flannel後味アサインA IP。しかし、サービスのリソースを作成しない、この時間は、現在のKUBE-プロキシが関与していません。