【Kubernetes】

一、kubernetes架构

二、工作流程

核心概念

1.包含多种类型的资源对象：pod,label,service,replication controller等
2.所有资源对象都可以通过kubernetes提供的kubectl工具进行增，删，改，查等操作，并将其保存在etcd中持久化存储。
3.是一个高度自动化的资源控制系统，通过跟踪对比etcd里保存的资源期望状态与当前环境中的实际资源状态的差异，来实现自动控制和自动纠错等高级功能。

Pod

是k8s创建或部署的最小/最简单的基本单位，一个Pod代表集群正在运行的一个进程。可以把Pod理解成豌豆荚，而同一Pod内的每个容器是一个个豌豆。
一个Pod由一个或多个容器组成，Pod中容器共享网络、存储和计算机资源，在同一Docker主机上运行。
同一个 Pod之间的容器可以通过localhost 互相访问，并且可以挂载Pod内所有的数据卷;但是不同的 Pod之间的容器不能用localhost 访问，也不能挂载其他 Pod 的数据卷。
pod中网络通信

pod控制器

pod控制器是pod启动的一种模板，用来保证在k8s里启动的pod应始终按照用户的预期运行（副本数、生命周期、健康状态检查等）
pod控制器
·Deployment:无状态应用部署。Deployment的作用是管理和控制 Pod和Replica8et，管控它们运行在用户期望的状态中。
Replicaset:确保预期的 Pod副本数量。Replicaet 的作用就是管理和控制Pod，管控他们好好干活。但是，Replicaset受控于Deployment。
可以理解成Deployment就是总包工头，主要负责监督底下的工人 Pod干活，确保每时每刻有用户要求数量的 Pod
在工作。如果一旦发现某个工人Pod不行了，就赶紧新拉一个 Pod 过来替换它。而Replicaset就是总包工头手下的小包工头。从 Kis使用者角度来看，用户会直接操作Deployment 部署服务，而当Deployment被部署的时候，KBS 会自动生成要求的ReplicaSet和 Pod。用户只需要关心Deployment 而不操心Replicaset。
资源对象Replication Controller是ReplicaSet的前身，官方推荐用neployment 取代 Replication Controller来部署服务。

Daemonset

确保所有节点运行同一类Pod，保证每个节点上都有一个此类Pod运行，通常用于实现系统级后台任务。（适用于日志收集）

statefulset

有状态应用部署

Job

一次性任务。根据用户的设置，Job管理的 Pod 把任务成功完成就自动退出了。

Cronjob

周期性计划性任务

Label

标签：是k8s特色的管理方式，便于分类管理资源对象。
Label可以附加到各种资源对象上，例如Node、Pod、Service、RC等，用于关联对象、查询和筛选。一个Label是一个key-value的键值对，其中key与value由用户自己指定。
一个资源对象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的资源对象中，也可以在对象创建后动态添加或者删除。可以通过给指定的资源对象捆绑一个或多个不同的Label，来实现多维度的资源分组管理功能。
与Label类似的，还有Annotation（注释）。
区别在于有效的标签值必须为63个字符或更少，并且必须为空或以字母数字字符（【a-z0-9A-Z】开头和结尾，中间可以包含横杠(-)、下划线(_)、点(.)和字母或数字。注释值则没有字符长度限制）
Label选择器（Label selector）
给某个资源对象定义一个Label,就相当于给他打了一个标签：随后可以通过标签选择器(Label selector)查询和筛选拥有某些label的资源对象。
标签选择器目前有两种：基于等值关系（等于、不等于）和基于集合关系（属于、不属于、存在）。

Service

在k8s的集群里，虽然每个Pod会被分配一个单独的IP地址，但由于Pod是有生命周期的（他们可以被创建，而且销毁之后不会再启动），随时可能会因为业务的变更，导致这个IP地址也会随着Pod的销毁而消失
Service就是用来解决这个问题的核心概念
k8s中的Service
是网关层，可以看作一组提供相同服务的Pod的对外访问接口、流量均衡器。
Service作用于哪些Pod是通过标签选择器来定义的
Service除了提供稳定的对外访问方式之外，还能起到负载均衡(Load Balance)的功能，自动把请求流量分布到后端所有的服务上，service可以做到对客户端透明的进行水平扩展(scale).而实现service这一功能关键，就是kube-proxy.kube-proxy运行在每个节点上，监听API Server中服务对象的变化，通过以下三种流量调度模式：
userspace（废弃）、iptanles(濒临废弃)、ipvs（推荐，性能最好）来实现网络的转发。
Service是k8s服务的核心，屏蔽了服务细节，统一对外暴露服务接口，真正做到了“微服务”。

service和ingress

service是通过标签选择器关联具有对有label的pod.再把相关pod的IP加入到自己的endpoints当中，service再根据endpoints里的IP进行转发

Ingress

是整个k8s的接入层，负责集群内部通讯；工作在OSI网络参考模型下，第七层的应用，对外暴露的接口，典型的访问方式是http/https.Service只能进行第四层的流量调度，表现形式是ip+port.Ingress则可以调度不同业务域、不同URL访问路径的业务流量。

Name

由于k8s内部，使用“资源”来定义每一种逻辑概念（功能），所以每种“资源”，都应该有自己的“名称”。“资源”有api版本(apiversion)、类别(kind)、元数据(metadata)、定义清单(spec)、状态(status)等配置信息。"名称"通常定义在"资源"的"元数据"信息里。在同一个namespace空间中必须是唯一的。

Namespace

随着项目增多、人员增加、集群规模的扩大，需要一种能够逻辑上隔离k8s内各种"资源"的方法，这就是Namespace。Namespace是为了把一个k8s集群划分为若干个资源不可共享的虚拟集群组而诞生的。不同的Namespace内的“资源”名称可以相同，相同Namespace内的同种“资源”，“名称”不能相同。
合理的使用k8s的Namespace，可以使得集群管理员能够更好的对交付到k8s里的服务进行分类管理和浏览。
k8s里默认存在的Namespace有：default、kube-system、kube-public等。
查询k9s里特定“资源”要带上相应Namespace
总结
控制器
节点控制器 副本控制器 端点控制器 服务账户和令牌控制器 资源配额控制器 命令空间控制器 服务控制器