标签：对象创建 复制 存在 耦合 客户端 定义 要求 集合 修改
Kubernetes作为容器编排生态圈中重要一员，是Google大规模容器管理系统borg的开源版本实现，吸收借鉴了google过去十年间在生产环境上所学到的经验与教训。 Kubernetes提供应用部署、维护、 扩展机制等功能，利用Kubernetes能方便地管理跨机器运行容器化的应用。当前Kubernetes支持GCE、vShpere、CoreOS、OpenShift、Azure等平台，除此之外，也可以直接运行在物理机上.kubernetes是一个开放的容器调度管理平台，不限定任何一种言语，支持java/C++/go/python等各类应用程序 。
kubernetes是一个完备的分布式系统支持平台，支持多层安全防护、准入机制、多租户应用支撑、透明的服务注册、服务发现、内建负载均衡、强大的故障发现和自我修复机制、服务滚动升级和在线扩容、可扩展的资源自动调度机制、多粒度的资源配额管理能力,完善的管理工具，包括开发、测试、部署、运维监控，一站式的完备的分布式系统开发和支撑平台。
实际上，使用Kubernetes只需一个部署文件，使用一条命令就可以部署多层容器（前端，后台等）的完整集群
（1）Pod
Pod是Kubernetes中最小部署单元，所有的容器均在Pod中运行,一个Pod可以承载一个或者多个相关的容器。Pod中容器共享存储和网络，同一个Pod中的容器会部署在同一个docker宿主机上并且能够共享资源。
（2）Service
Service是一个应用服务抽象，定义了Pod逻辑集合和访问这个pod集合的策略（比如访问策略）。Service代理Pod集合对外表现为一个访问入口，分配一个机器IP地址，来自这个IP的请求将负载均衡转发到后端Pod中的容器。Service通过Lable Selector选择一组Pod提供服务。
（3）Volume
数据卷
（4）Namespace
是kubernetes系统中的另一个重要的概念，通过将系统内部的对象“分配”到不同的Namespace中，形成逻辑上分组的不同项目、小组或用户组，便于不同的分组在共享使用整个集群的资源的同时还能被分别管理。Kubernetes集群在启动后，会创建一个名为“default”的Namespace，如果不特别指明Namespace，则用户创建的Pod、RC、Service都被系统创建到“default”的Namespace中。
（5）Label
Label机制是K8S中一个重要设计，通过Label进行对象弱关联，灵活地分类和选择不同服务或业务，让用户根据自己特定的组织结构以松耦合方式进行服务部署。Label是一对KV，对用户而言非常有意义的，但对K8S本身而言没有直接意义的。Label可以在创建对象时指定，也可以在后期修改，每个对象可以拥有多个标签，但key值必须是唯一的。
（6）RC（Replication Controller）
Replication Controller确保任何时候Kubernetes集群中有指定数量的pod副本(replicas)在运行， 如果少于指定数量的pod副本(replicas)，Replication Controller会启动新的Container，反之会杀死多余的以保证数量不变。Replication Controller使用预先定义的pod模板创建pods，一旦创建成功，pod 模板和创建的pods没有任何关联，可以修改pod 模板而不会对已创建pods有任何影响，也可以直接更新通过Replication Controller创建的pods。对于利用pod 模板创建的pods，Replication Controller根据label selector来关联，通过修改pods的label可以删除对应的pods。
（7）Deployment
Kubernetes Deployment提供了官方的用于更新Pod和Replica Set（下一代的Replication Controller）的方法，您可以在Deployment对象中只描述您所期望的理想状态（预期的运行状态），Deployment控制器为您将现在的实际状态转换成您期望的状态，例如，您想将所有的webapp:v1.0.9升级成webapp:v1.1.0，您只需创建一个Deployment，Kubernetes会按照Deployment自动进行升级。现在，您可以通过Deployment来创建新的资源（pod，rs，rc），替换已经存在的资源等。
Deployment集成了上线部署、滚动升级、创建副本、暂停上线任务，恢复上线任务，回滚到以前某一版本（成功/稳定）的Deployment等功能，在某种程度上，Deployment可以帮我们实现无人值守的上线，大大降低我们的上线过程的复杂沟通、操作风险。
（8）StatefulSet
使用Deployment创建的Pod是无状态的，当挂在Volume之后，如果该Pod挂了，Replication Controller会再run一个来保证可用性，但是由于是无状态的，Pod挂了的时候与之前的Volume的关系就已经断开了，新起来的Pod无法找到之前volume。StatefulSet 的目的就是给为数众多的有状态负载提供正确的控制器支持。
当应用有以下任意要求时，StatefulSet的价值就体现出来了。
● 稳定的、唯一的网络标识。
● 稳定的、持久化的存储。
● 有序的、优雅的部署和扩展。
● 有序的、优雅的删除和停止。
（9）DaemonSet
DaemonSet能够让所有（或者一些特定）的Node节点运行同一个pod。当节点加入到kubernetes集群中，pod会被（DaemonSet）调度到该节点上运行，当节点从kubernetes集群中被移除，被（DaemonSet）调度的pod会被移除，如果删除DaemonSet，所有跟这个DaemonSet相关的pods都会被删除。
（10）Job
在有些场景下，是想要运行一些容器执行某种特定的任务，任务一旦执行完成，容器也就没有存在的必要了。在这种场景下，创建pod就显得不那么合适。于是就是了Job，Job指的就是那些一次性任务。通过Job运行一个容器，当其任务执行完以后，就自动退出，集群也不再重新将其唤醒。还可以执行定时任务。
1.kubectl
客户端命令行工具，将接受的命令格式化后发送给kube-apiserver，作为整个系统的操作入口。
2.kube-apiserver
作为整个系统的控制入口，以REST API服务提供接口。
3.kube-controller-manager
用来执行整个系统中的后台任务，包括节点状态状况、Pod个数、Pods和Service的关联等。
4.kube-scheduler
负责节点资源管理，接受来自kube-apiserver创建Pods任务，并分配到某个节点。
5.etcd
负责节点间的服务发现和配置共享。
6.kube-proxy
运行在每个计算节点上，负责Pod网络代理。定时从etcd获取到service信息来做相应的策略。
7.kubelet
运行在每个计算节点上，作为agent，接受分配该节点的Pods任务及管理容器，周期性获取容器状态，反馈给kube-apiserver。
8.DNS
一个可选的DNS服务，用于为每个Service对象创建DNS记录，这样所有的Pod就可以通过DNS访问服务了。
1.Kubectl(user commands): k8s APIs客户端工具，通过用户输入命令操作APIs资源
2.认证，用户输入命令要通过APIs的认证
3.认证通过之后，交由APIs中REST中对象处理（Kubernetes以RESTFul形式开放接口，用户可操作的REST对象有三个Pod,service,controller）
4.APIs中的操作处理都会持久化存储到一个分布式存储etcd
5.Scheduler调度组件，会检测REST对象中是否有新的动作产生，并将具体操作，根据算法下发到node节点中
6.Controller通过API Server提供的接口实时监控整个集群的每个资源对象的当前状态，当发生各种故障导致系统状态发生变化时，会尝试将系统状态修复到“期望状态”
7.kubeletl类似于一个agent，处理AIPs下发的任务，如创建Pod、容器、获取节点信息等
8.proxy负责网络代理，Service具体实现就是有proxy处理,维护网络规则和四层负载均衡工作
标签：对象创建 复制 存在 耦合 客户端 定义 要求 集合 修改
原文地址：https://www.cnblogs.com/jay-fred/p/9968860.html
