k8s基本概述&资源对象相关概念
Kubernetes，简称K8s，是用8代替8个字符“ubernete”而成的缩写，是一个开源的云原生的容器集群管理工具，容器编排工具，也是一个自动化的容器操作平台。其作为云原生应用的基础调度平台，相当于云原生的操作系统
Kubernetes的目标是简单高效的部署容器化的应用，简化应用管理的复杂度，提供了应用部署，规划，更新，维护的一种机制。
Kubernetes作为一个容器管理与调度编排领域的首选平台和事实标准，最终使命是成为新一代应用上云的首选平台，为广大开发者开启云原生应用的大门。
传统的应用部署方式是通过插件或脚本来安装应用。这样做的缺点是应用的所有生存周期（运行、配置、管理）将与当前操作系统绑定，这样做并不利于应用的升级更新/回滚等操作。
新的方式是通过部署容器方式实现，每个容器之间互相隔离，每个容器都有自己的文件系统 ，容器之间的进程不会相互影响。相对于虚拟机，容器能快速部署，由于容器与底层设施、机器文件系统是解耦的，所以它能在不同云、不同版本操作系统间进行迁移。
容器占用资源少、部署快，每个应用可以被打包成一个容器镜像，每个应用与容器间形成一对一的关系，使用容器可以在 build 或 release 的阶段，为应用创建容器镜像，因为每个应用不需要与其余的应用堆栈组合，也不依赖于生产环境基础结构，这使得从研发到测试、生产能提供一致环境。
Namespace
用于将物理集群划分为多个虚拟集群，本身也是一个object。Namespace间完全隔离，因此也常被用来隔离不同的用户及权限。内置有三个Namespace，分别是：default，kube-system（平台组件），kube-public。
Annotations（注解）
可以将任意非标识性元数据附加到对象上。将数据作为Annotations附着在对象上，有利于创建一些用于部署、管理和做内部检查的共享工具和客户端。
Label（标签）
label可以附着在任意对象上，每个对象也都可以有任意标签。标签可在对象定义时附加上，也可以通过命令动态管理标签。
K8S对象分类
workload（工作负载类）
Pod
Controllers（控制器）：诸如Deployment、DaemonSet、Job、StatefulSet
discovery&load balance
Service
Endpoint
Ingress
config&storage(注入初始化配置数据或持久化保存到容器外)
Configmap
Sercet
Volume
PersistentVolumeClaim
cluster
Node/Namespace
PersistVolume
ClusterRole/ClusterRoleBinding
ResourceQuota
Pod相关
工作负载以pod为中心，controller控制器用于维护pod的状态，配置和存储对象用于注入初始化数据，并持久化pod运行时产生的数据。service将pod聚合在一起，统一对集群内外提供服务。
pod是一个有特定关系的容器集合，包含一个或多个container。是比容器更高级别的抽象。pod包含一组容器和卷，同个组内的容器共享一个存储卷（volume） 。一个卷就是一个目录，容器对其有访问权限。
pod是短暂的，不是持续性实体。怎么才能持久化容器数据使其能够跨重启而存在呢？Kubernetes支持卷的概念，因此可以使用持久化的卷类型。
pod是集群中可以创建和部署的最小最简的kubernetes对象单元。一个pod就代表着集群中运行的一个进程，是应用运行的载体。pod本身没有资源，Pod中的容器具有资源。
整个Kubernetes系统都是围绕着pod展开的。一个pod一旦被创建就会放到Etcd中存储，然后由Master调度到一个Node绑定，再由这个Node上的Kubelet对其进行实例化。每个pod会被分配一个单独的podIP，podIP + ContainerPort 组成了一个Endpoint。
在Docker中，容器是最小的处理单元，增删改查的对象是容器，容器是一种虚拟化技术，容器之间是隔离的。而在Kubernetes中，pod包含一个或者多个相关的容器，pod可以认为是容器的一种延伸扩展，一个pod也是一个隔离体，而pod内部包含的一组容器又可以访问共同的数据卷来实现文件系统的共享。
pod被分配到Node之后会根据镜像下载策略进行镜像下载，可以根据自身集群的特点来决定采用何种下载策略。无论何种策略，都要确保Node上有正确的镜像可用（一般都是采用harbor）。
#此时说明pod中共有一个container且已经正常启动。
kubectl get pods -n monitoring
NAME READY STATUS RESTARTS AGE
alertmanager-56797bdb65-x2qbv 1/1 Running 0 8d
pod是一个非持久性实体。pod不建议手动创建pod。推荐使用控制器自动管理pod。pod在调度失败、节点故障都可能被终止掉。
Pending：挂起，这时pod已经被k8s集群接受，但有一个或多个容器镜像尚未创建，等待时间包括调度pod的时间和通过网络下载容器镜像的时间。
Running：此时pod已经被绑定到某一个节点上，pod中所有的容器都被创建并且至少有一个容器正在运行或者处于启动或重启状态。
Succeed：此时pod中的所有容器都被成功终止并且不会重启。
Failed：pod中的所有容器都已经被终止，并且至少有一个容器因为失败而终止（容器以非0状态退出）。
service相关
与云原生应用中的微服务概念对应。k8s集群为每一个service分配一个集群唯一ip地址，在service的声明周期内，该ip地址不变。作为入口地址，向外提供稳定可靠的Service。
service通过label selector关联到实际支撑业务运行的pod上，并通过集群内置的服务负载均衡将服务请求分发到后端的pod。通过nodeport或设置loadbalance机制实现集群外部对service的访问。
controller控制器相关
controller用于保证集群内一组pod能始终按照某种期望状态正常运行。包括pod副本的数量、节点选择、资源约束、持久化数据维持等。控制器对象主要包括Deployment，replicaset，statefulset、daemonset。
replicaset：即RS。pod副本集合控制器，确保健康pod的副本数始终满足用户定义的数量。相比RC，RS增加了集合式label selector的支持。支持单独使用，但更多隐藏在deployment控制器后面，由deployment自动管理。
如果想要创建同一个容器的多份拷贝，可以通过RC使用pod模板创建出多份拷贝。RC确保任意时间都有指定数量的pod副本在运行。如果为某个pod创建了RC并且指定3个副本，它会创建3个pod，并且持续监控它们。如果某个pod不响应，那么RC会替换它，保持总数为3。如果之前不响应的pod恢复了，现在就有4个pod了，那么RC会将其中一个终止保持总数为3。如果在运行中将副本总数改为5，RC会立刻启动2个新pod，保证总数为5。还可以按照这样的方式缩小Pod，这个特性在执行滚动升级时很有用。当创建RC时，需要指定两个东西：
- pod模板：用来创建pod副本的模板
- Label：RC需要监控的Pod的标签。
deployment：为pod和replicaset提供了声明式的定义方法。用户在deployment文件中描述期望状态，deployment controller就会自动将pod和replicaset的实际状态改变到期望状态。如在yaml文件中声明需要多少Pod副本。在创建完Deployment对象后就会自动部署多少个Pod。
statefulset：提供了对有状态的应用的部署和控制的支持。适用场景：稳定的持久化存储，稳定的网络标志，有序部署有序扩展，有序收缩有序删除，有序自动滚动升级。
daemonset：保证在每个node上都运行一个pod副本，适用于监控跟踪、日志收集等。
configmap：将配置信息与容器镜像内容解耦。用来向pod提供非敏感的配置信息。
secret：解决的是集群内密码、token、密钥等敏感数据的配置问题。和configmap的使用方法类似。常与service account关联，存储在tmpfs文件系统中，pod删除后secret文件也会对应删除。
关系图
controller，即控制器，主要有Deployment，Daemonset、Replicaset也即RS（为Replicas controller也即RC的进化版）等。
Service、Pod以及Node间的关系为：
Deployment、Replicaset、Pod的关系为：
一个Deployment对应多个ReplicaSet、一个ReplicaSet对应多个Pod。
RS部署Pod。
Deployment使管理RS更加方便。
RS保证在同一时间能够运行指定数量的Pod副本，如果实际Pod数量比指定的多就结束掉多余的，如果实际数量比指定的少就启动缺少的。Deployment使用了RS，它是更高一层的概念。在一般情况下，我们推荐使用Deployment而不直接使用RS。
这一整套可以向外提供稳定可靠的Service。
Endpoint、Service、Pod的关系为：
Endpoint是可被访问的服务端点，只有Service关联的是状态为Running的pod才可能成为Endpoint。