kubernetes组件

当你部署完了kubernetes，即拥有了一个完整的集群。
一个kubernetes集群由一组被称作节点的机器组成。这些节点上运行kubernetes所管理的容器化应用。集群具有至少一个工作节点。
工作节点托管作为应用负载组件的Pod。控制平面管理集群中的工作节点和Pod。为集群提供故障转移和高可用性，这些控制平面一般跨多主机运行，集群跨多个节点运行。

container

我们先以container为七点，k8s既然是容器编排工具，那么一定会有container。

那么k8s是如何操作这些container的呢？从感性的角度来说，他要提升点档次来区分docker，因此k8s不想直接操作container，因为操作container的事情是由docker来做的，k8s中要有自己的最小操作单位，称为Pod。

Pod

Pod其实就是一个或多个container的组合。

我们来看看官网的阐述：

Pod是可以在kubernetes中创建和管理的、最小的可部署的计算单元。
Pod（就像在鲸鱼荚或者豌豆荚中）是一组（一个或多个）容器；这些容器共享存储网络、以及怎样运行这些容器的声明。Pod中的内容总是并置（colocated）的并且一同调度，在共享的上下文中运行。Pod所建模的是特定于应用的“逻辑主机”，其中包含一个或多个应用容器，这些容器是相对紧密的耦合在一起的。在非云环境中，在相同的物理机或虚拟机上运行的应用类似于在同一逻辑主机上运行的应用。

谁来维护Pod。

既然Pod是kubernetes中的最小计算单位，那么谁来维护Pod的？那就是ReplicaSet，通过selector来进行管理。

ReplicaSet

ReplicaSet工作原理

replicaSet是通过一组字段来定义的，包括一个用来识别可获得得Pod的集合的选择算符，一个 用来标明应该维护的副本个数的数值，一个用来指定应该创建新Pod以满足副本个数条件时要使用的Pod模板等等。每个ReplicaSet都通过根据需要创建和删除Pod以使得副本个数达到期望值，进而实现其存在价值。当replicaSet需要创建新的Pod时，会使用提供的Pod模板。
ReplicaSet通过Pod上的metadata.ownerReferences字段连接到附属Pod，该字段给出当前对象的属主资源。ReplicaSet所获得的Pod都在其ownerReferences字段中包含了属主ReplicaSet的标识信息。正是通过这一连接，ReplicaSet知道它所维护的Pod集合的状态，并据此计划其操作行为。
ReplicaSet使用其选择算符来辩识要获得得Pod集合。如果某个Pod没有ownerReferences或者其ownerReferences不是一个控制器，且其匹配到某ReplicaSet的选择算符，则该Pod立即被此ReplicaSet获得。

Pod和ReplicaSet的状态如何维护（Deployment）

一个Deployment为Pods和ReplicaSets提供声明式的更新能力，你负责描述Deployment中的目标状态，而Deployment控制器（Controller）以受控速率更改实际状态，使其变为期望状态。你可以定义deployment以创建新的ReplicaSet，或删除现有Deployment，并通过新的Deployment收养其资源。

用例：

• 创建Deployment以将ReplicaSet上线。ReplicaSet在后台创建Pods。检查ReplicaSet的上线状态，检查其是否成功。
• 通过更新Deployment的PodTemplateSpec，生命Pod的新状态。新的ReplicaSet会被创建。Deployment以受控速率将Pod从旧ReplicaSet迁移到新ReplicaSet。每个新的ReplicaSet都会更新下Deployment的修订版本。
• 如果Deployment的当前状态不稳定，回滚到较早的Deployment版本。每次回滚都会更新Deployment的修订版本。
• 扩大Deployment规模以承担更多负载。
• 暂停Deployment以应用对PodTemplateSpec所做的多项修改，然后回复其执行以启动新的上线版本。
• 使用Deployment状态来判定上线过程是否出现停滞。
• 清理较旧的不再需要的ReplicaSet。

标签（Labels）

我们知道了Pod的是一个和多个container的组合，那么我们又是如何将Pod进行分类的呢？（例如 A-Pods负责登录业务，B-Pod负责其他业务）。这里就需要使用到label了。

标签（Labels）是附加到kubernetes对象（比如Pods）上的键值对。标签旨在用于指定对用户有意义且相关的对象的标识属性，但不直接对核心系统有语义含义。标签可以用于组织和选择对象的子集。标签可以在创建时附加到对象，随和可以随时添加和修改。每个对象都可以定义一组键值标签。每个键对于给定对象必须是唯一的。

具有相同label的service能否有个名称呢？Service

Service：

将运行在一组Pods上的应用程序公开为网络服务的抽象方法。使用kubernetes，你无需修改应用程序即可使用不熟悉的服务发现机制。kubernetes为Pods提供自己的IP地址，并为一组Pod提供相同的DNS名，并且可以在他们之间进行负载均衡。

如何运行Pod

我们介绍了那么多？那么Pod到底运行在哪里呢？当然是机器啦，比如一台centos机器，我们把这个机器称作为node

Node:

kubernetes通过将容器放入在节点（Node）上运行的Pod中来执行你的工作负载。节点可以是一个虚拟机或者物理机器，取决于所在的集群配置。每个节点包含运行Pods所需要的服务；这些节点由控制面负载管理。
通常集群中会有若干个节点；而在一个学习用或者资源受限的环境中，你的集群中也可能只有一个节点。
节点上的组件包括kubelet，容器运行时以及kube-proxy

显然不会只有一个Node，多台Node共同组成集群才行。我们再来画个图整体感受下。

此时，我们在把关注点放到由3个Node节点组成的Mater-Node集群。

这个集群如果想配合完成工作，总要有一些组件的支持吧，我们一起来看看：

• 操作集群的客户端，和集群打交道kubectl
• 请求肯定是到达Master Node ，然后在分配给worker Node创建Pod之类的，命令通过kubectl过来之后，这里还有一个认证授权操作。
• 请求过来之后，Master Node中谁来接收？ APIServer
• API接收到请求之后，接下来调用哪个Worker Node创建Pod，Container之类的，得要有调度策略 Scheduler。
• Schedule通过不同的策略，真正要分开请求到不同的Worker Node上创建内容，具体谁负责？Controller Manager
• worker Node接收到创建请求之后，具体谁负载？kubelet服务，最终kubelet会调用Docker Engine创建对应的容器。
• 域名解析问题：DNS
• 要有一个监控面板能够检测整个集群的状态？Dashboard
• 集群中这些数据如何保存？分布式存储。ETCD
• 至于像容器的持久化存储，网络等，有兴趣的可以参考我的Docker专栏的内容。

可能粗略介绍会十分模糊，后续会陆续更新详细介绍具体的组件。如有不对之处，还请不吝赐教。