kubernetesアーキテクチャ
このシステムアーキテクチャ図では、作業ノードで実行されているサービスのクラスタで構成サービスおよびサービスレベルパネルに置きます。
Kubernetesノードは、マスターによって制御されている実行中のアプリケーションコンテナ必要不可欠なサービスを、持っています。
当然の各ノード上では、ドッカーを実行する必要があります。ドッカーは、コンテナをダウンロードして実行するすべての特定の画像を担当することにします。
Kubernetesは、主に以下のコアコンポーネントで構成されます。
kubectl：クライアントの操作指示を送信するためのK8Sコマンドライン終了。
マスターノード
1. APIサーバ[リソース演算子]：フロントエンドのインターフェース、さまざまなツールとK8S K8S K8Sクラスタは、クラスタを通じてリソースを管理することができ、他のクライアントコンポーネント。これは、HTTP / HTTPSのRESTful API、すなわちK8S APIを提供します。
- 他のすべてのコンポーネントは、それが唯一のAPIサーバとストレージトラフィック、APIサーバでクラスタの状態をアクセスするために他のモジュールを提供するAPIを通じてリソースデータを操作する必要があり、ユニークなリソースはオペレータオブジェクト提供します。
最初は、クラスタ状態訪問の安全性を確保することです。
API Serverがないため、バックエンド・ストレージ・テクノロジー・etcdの状態訪問は、変更された方法です。バックエンド・ストレージを達成するために、クラスタの状態やアクセス方法を隔離するために、第2、。
- コアオブジェクトの削除変更検索操作封入エントリーシステムとしてKubernetes、安らかのインタフェースモードは、内部コンポーネントと外部顧客の呼び出しに供給されます。関連するリソース・データ「全額クエリ」+「モニターの変更は、」リアルタイムに関連するビジネス機能を完了します。
2.スケジューラ[クラスタ分布スケジューラ]：ポッドは、どのノードの動作を決定する責任があります。ときにスケジューリングは、クラスタのトポロジの完全なアカウントを取る各ノードの現在の負荷だけでなく、高可用性、パフォーマンス、データの親和性と需要に対処するだろう。
すべてのクラスタリソースの1.Scheduler収集と分析は、現在、Kubernetesミニオンは（メモリ、CPU）負荷ノード、そうしてKubernetesに新しいポッドを配布するクラスタで使用するノード。
すべての実行中のポッドは2リアルタイム監視Kubernetesクラスタを未分配し、分散されています。
3.Schedulerミニオンも原因頻繁に見つけるミニオンノードに、ノード情報を監視し、スケジューラは、ローカルに最新の情報のコピーをキャッシュされました。
4.最後に、スケジューラポッドは、指定されたノードミニオンに配布した後、ポッドは、バインディングAPIサーバーに関連する情報を書き戻します。
4.コントローラマネージャ[内部管理コントロールセンター]：リソースが状態を期待されていることを保証するために、クラスタリソースを管理する責任があります。これは、レプリケーション・コントローラ、エンドポイントコントローラ、名前空間コントローラを含め、様々なコントローラで構成され 、Serviceaccountsコントローラなどがあります。
各種コントローラを実行する責任クラスタの障害の検出と回復の自動化を実装し、以下のとおりです。
1.endpointコントローラ：定期的に関連付けられているサービスと、ポッド（エンドポイント・オブジェクトによって維持される関連情報）、常に最新のポッドへのマッピングサービスを確保します。
2.replicationコントローラ：定期的に常にポッドの実際の操作の数と一致するコピーreplicationController定義の数を確保するために、replicationControllerとポッド関連します。
5. Etcd：状態は情報K8Sクラスタ構成情報やさまざまなリソースを格納するための責任があります。場合は、データの変更、etcdはすぐに通知が関連するコンポーネントをK8Sます。[代替を有する（サードパーティコンポーネント）。領事、飼育係]（）
6.ポッド：最小構成単位K8Sクラスタ。Aポッドは、1つ以上の容器を実行することができます。ほとんどの場合には、コンテナ内のコンテナだけポッド。
7. Flannerは：、K8Sクラスタネットワークでホスト間通信ポッドことを保証することができます。選択肢もあります。
[root@master ~]# kubectl get pod --all-namespaces
//查看pod信息
[root@master ~]# kubectl get pod --all-namespaces -o wide
//显示pod的节点信息
ノードノード
Kubelet [PODがノード上執事]：それはノードエージェント（エージェント）ノードポッド上で動作しているとき、スケジューラが決定され、ノードkubeletにポッド固有の設定情報、kubeletは、この情報に基づいて作成し、実行コンテナ、およびマスターレポートの動作状態。
- などの作成、変更するために、ポッド、監視、削除、ライフサイクル全体の管理を担当するノードのノード
- ノードAPIサーバーの現在の状態にタイミング情報を報告します。
- マスターAPI Serverとその割り当てられたコマンドの仕事、永続的なキーと値のストアetcd、ファイルサーバやHTTPとの相互作用を受けて、マスターAPIサーバーとミニオンの間のブリッジをkubelet、設定情報を読み込みます。
- 次のように具体的な作業は次のとおりです。
バインドに環境変数コンテナ、コンテナを設定し、ボリュームを指定したポッドは、単一の容器を実行によると、バインドコンテナ港に、ネットワークコンテナを作成するために、ポッドを指定。
ポッド同期状態から同期状態ポッドcAdvisorは取得コンテナ情報、情報POD、ルート情報、機械情報を。
コンテナ、コンテナキルでコマンドを実行して、すべてのコンテナポッドを削除します。
kube-proxy[负载均衡、路由转发]:负责将访问service的TCP/UDP数据流转发到后端的容器。如果有多个
副本，kube-proxy会实现负载均衡。
- Proxy是为了解决外部网络能够访问跨机器集群中容器提供的应用服务而设计的，运行在每个Node上。Proxy提供TCP/UDP sockets的proxy，每创建一种Service，Proxy主要从etcd获取Services和Endpoints的配置信息（也可以从file获取），然后根据配置信息在Minion上启动一个Proxy的进程并监听相应的服务端口，当外部请求发生时，Proxy会根据Load Balancer将请求分发到后端正确的容器处理。
- Proxy不但解决了同一主宿机相同服务端口冲突的问题，还提供了Service转发服务端口对外提供服务的能力，Proxy后端使用了随机、轮循负载均衡算法。
除了核心组件，还有一些推荐的Add-ons：
kube-dns负责为整个集群提供DNS服务
Ingress Controller为服务提供外网入口
Heapster提供资源监控
Dashboard提供GUI
Federation提供跨可用区的集群
Fluentd-elasticsearch提供集群日志采集、存储与查询
一. 分层架构
Kubernetes设计理念和功能其实就是一个类似Linux的分层架构，如下图所示。
核心层：Kubernetes最核心的功能，对外提供API构建高层的应用，对内提供插件式应用执行环境
应用层：部署（无状态应用、有状态应用、批处理任务、集群应用等）和路由（服务发现、DNS解析等）
管理层：系统度量（如基础设施、容器和网络的度量），自动化（如自动扩展、动态Provision等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy等）
接口层：kubectl命令行工具、客户端SDK以及集群联邦
生态系统：在接口层之上的庞大容器集群管理调度的生态系统，可以划分为两个范畴
Kubernetes外部：日志、监控、配置管理、CI、CD、Workflow、FaaS、OTS应用、ChatOps等
Kubernetes内部：CRI、CNI、CVI、镜像仓库、Cloud Provider、集群自身的配置和管理等
二. 在K8s中运行一个容器应用
下面通过运行一个容器应用的过程，来一起理解一下K8s组件是如何协作的。
开发者开发一个应用后，打包Docker镜像，上传到Docker registry；然后编写一个yaml部署描述文件，以描述应用的结构和资源需求。开发者通过kubectl（或其它应用），将部署描述文件提交到API server，API server将部署需求更新到etcd。etcd在K8s管理结点中的作用相当于数据库，其它组件提交到API server的数据都存储于etcd。API server非常轻量，并不会直接去创建或管理Pod等资源，在多数场景下甚至不会去主动调用其它的K8s组件发出指令。其它组件通过建立和API server的长连接，监视关心的对象，监视到变化后，执行所负责的操作。
继续我们的启动应用之旅，如图所示，Controller Manager中的控制器监视到新的部署描述后，根据部署描述，创建ReplicaSet、Pod等资源。Scheduler监视到新的Pod资源后，结合集群的资源情况，选定一或多个工作结点运行Pod。工作结点上的Kubelet监视到有Pod被计划在自己的结点后，向Docker等Container runtime发出启动容器的指令，Docker engineer将按照指令从Docker registy拉取镜像，然后启动并运行容器。
三. K8s集群的高可用部署
通过之前的介绍，我们看到K8s可以在多个工作结点上启动并管理容器，下面来学习一下，如何实现管理结点的高可用部署。
上图的K8s高可用部署中有3个管理结点。etcd自身是一个分布式数据存储系统，按照其多实例部署方案，结点只需在启动时知道其它结点的IP和端口号即可组成高可用环境。和通常的应用服务器一样，API Server是无状态的，可以运行任意多个实例，且彼此之间无需互相知道。为了能使kubectl等客户端和Kubelet等组件连接到健康的API Server、减轻单台API Server的压力，需使用基础架构提供的负载均衡器作为多个API Server实例的入口。如上图的部署方法，每个主结点上都运行了一个etcd实例，这样API Server只需连接本地的etcd实例即可，无需再使用负载均衡器作为etcd的入口。
Controller Manager和Scheduler需要修改K8s集群，同时修改时可能引发并发问题。假设两个ReplicaSet Controller同时监视到需创建一个Pod，然后同时进行创建操作，就会创建出两个Pod。K8s为了避免这个问题，一组此类组件的实例将选举出一个leader，仅有leader处于活动状态，其它实例处于待命状态。Controller Manager和Scheduler也可以独立于API server部署，通过负载均衡器连接到多个API server实例。
范例
分析各个组件的作用以及架构工作流程:
1) kubectl发送部署 请求到API server
2) APIserver通知Controller Manager创建一个Deployment资源。
3) Scheduler执行调度任务,将两个副本Pod分发到node01和node02. 上。
4) node01和node02, 上的kubelet在各自节点上创建并运行Pod。补充
1.应用的配置和当前的状态信息保存在etcd中，执行kubectl get pod时API server会从etcd中读取这些数据。
2.flannel会为每个Pod分配一个IP。 但此时没有创建Service资源，目前kube-proxy还没有参与进来。
运行一个例子（创建一个deployment资源对象<pod控制器>）
[root@master ~]# kubectl run test-web --image=httpd --replicas=2
//创建一个deployment资源对象。运行完成之后，如果有镜像可直接开启，没有的话需要等待一会儿，node节点要在docker hup上下载
查看一下
[root@master ~]# kubectl get deployments.或 kubectl get deploy
[root@master ~]# kubectl get pod
[root@master ~]# kubectl get pod -o wide
//显示pod的节点信息
如果，node节点没有运行test-web服务，需要在节点上重启一下<systemctl restart kubelet>
如果删除一个pod
[root@master ~]# kubectl delete pod test-web-5b56bdff65-2njqf 查看一下
[root@master ~]# kubectl get pod -o wide
现在发现容器还存在，因为控制器会自动发现，一旦与之前执行的命令有误差，他会自动补全。
参考：
https://blog.csdn.net/gongxsh00/article/details/79932136
https://www.jianshu.com/p/18edac81c718