Kubernetes 核心概念
kubernetes中的基本概念和术语大多是围绕资源对象来说的，而资源对象在总体上可以分为以下两类：
（1）某种资源的对象，例如节点（Node），Pod，服务（Service），存储卷（Volume）
（2）与资源对象相关的事物与动作，例如标签（Label）、注解（Annotation）、命名空间（namespace）、部署（Deployment）、HPA(Horizontal Pod Autoscaling，Pod水平自动伸缩)、PVC(dynamically provisioned claim)
1. 资源对象通用属性
版本：版本信息里面包括了此对象所属的资源组
类型（Kind）：定义资源对象类型
元数据：
- 资源对象的名称要唯一
- 资源对象的标签表明资源对象的特征、类别，以及通过标签筛选不同的资源对象并实现对象之间的关联、控制和写作功能。
- 注解可悲理解为一种特殊的标签，不过更多地是与程序挂钩，通常用于实现资源对象属性的自定义扩展。
1.1. 声明
可以通过YAML或JSON格式生命一个k8s的资源对象，每一个资源对象都有自己的特定结构定义，并保存在etcd二中非关系型数据库中，以实现最快的读写速度。所有资源对象都可以通过k8s提供的kubectl工具执行增、删、改、查等操作。
1.2. 状态
比如POD，通过kubectl客户端工具创建一个Pod并将其提交到系统中后，它就处于等待调度的状态，调度成功后为pending状态，等待容器镜像下载和启动、启动成功后为Running状态，正常停止后为Succeeded状态，非正常停止后为Failed状态。
2. 资源对象分类
- 集群类
- 应用类
- 存储类
- 安全类
2.1. 集群类
在集群管理方面，Kubernetes将集群中的机器分为一个Master和一些Node。
2.1.1. Master
Master指的是集群的控制节点，在每个K8s集群中都需要有一个或一组被称为Master的节点，来负责整个集群的管理和控制。Master通常占据一个独立的服务器（在高可用部署中建议至少使用3台服务器），是整个集群的“大脑”。
在Master上运行着集群管理相关的一些进程：kube-apiserver、kube-controller-manager和kube-scheduler。
- kube-apiserver：提供HTTP RESTful API接口的主要服务，是K8s里对所有资源进行增、删、改、查等操作的唯一入口，也是集群控制的入口进程。
- kube-controller-manager：k8s里所有资源对象的自动化控制中心，可以将其理解为资源对象的“大总管”。
- kube-scheduler：负责资源调度（Pod调度）的进程，相当于公交公司的调度室。
这些进程实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理功能，并且都是自动完成的。另外，在Master上通常还要部署etcd服务。
2.1.2. Node
k8s集群中除Master外的其他服务器被称为Node，Node作为集群中的工作节点，其上运行着真正的应用程序。与Master一样，Node可以是一台物理主机，也可以是一台虚拟机。Node是k8s集群中的工作负载节点，每个Node都会被Master分配一些工作负载（Docker容器）。当某个Node宕机时，其上的工作负载会被Master自动转移到其他Node上。在每个Node上都运行这以下关键进程，这些服务进程负责Pod的创建、启动、监控、重启、销毁，以及实现软件模式的负载均衡。k
- kubelet: 负责Pod对应的容器的创建、启动等任务，同时与Master密切写作、实现集群管理的基本功能。
- kube-proxy：实现k8s service的通信与负载均衡机制的服务。
- 容器运行时（如Docker）：负责本机的容器创建和管理
2.1.3. 命名空间
命名空间可以用于实现多租户的资源隔离，典型的一种思路就是给每个租户分配一个命名空间，命名空间属于k8s集群范畴的资源对象，在一个集群里可以创建多个命名空间，每个命名空间都是互相独立的存在，属于不同命名空间的资源对象从逻辑上相互隔离。在每个k8s集群安装完成且正常运行之后，Master会自动创建两个命名空间，一个是默认的（default）、一个是系统级的（kube-system）。用户创建的资源对象如果没有指定命名空间，则被默认存放在default命名空间中，而系统相关的资源对象如网络组件、DNS组件、监控类组件存放在kube-systemc命名空间中。我们可以通过命名将集群内部的资源对象分配到不同的命名空间中，形成逻辑上分组不同的项目、小组或用户组，便于不同的分组在共享使用整个集群的资源的同时能够被分别管理，当给每个租户都创建一个命名空间来实现多租户的资源隔离时，还能结合k8s的资源配额管理，限定不同租户能占用的资源，如cpu使用量和内存使用量。
2.2. 应用类
2.2.1. Service
一个service对象拥有以下关键属性
- 一个全局唯一的服务名称
- 一个vip(cluster ip)和端口
- 提供某种远程服务能力
- 能够将客户端对服务端的访问请求转发到一组容器应用上
一般情况下service指定的是无状态服务，通常由多个程序副本提供服务，在特殊情况下也可以是有状态的单实例服务，比如Mysql这种数据存储类的服务。Service的每个服务进程有独立的ip和port，service具有一个全局唯一的clusterIP，service一旦被创建，k8s就会自动为他分配一个可用的clusterIP地址，而且在service的整个生命周期中，这个地址都不会变。借助k8s集群的DNS服务，就可以实现service name(域名)到clusterIP地址的DNS映射功能，kubernetes能够让我们通过service(cluster ip + port)连接指定服务，提供透明的负载均衡和故障恢复机制。
2.2.2. pod对象
Pod运行在一个被称为节点（Node）的环境中，这个节点（Node）既可以是物理机，也可以是云上的某个虚拟机，一个节点上能够运行多个Pod。其次，一个Pod包含一组容器，在每个Pod中都会运行一个特殊的叫Pause的容器，其他容器则为业务容器，这些业务容器共享Pause容器的网络栈和Volume挂载卷，因此他们之间的通信和数据交换更为高效，在设计时我们可以充分利用这一特性将一组密切相关的服务进程放进同一个Pod中。最后，需要注意的是不是每个pod和它里面运行的容器都能够被映射到一个service上，只有需要提供服务的那组Pod才会被映射为一个service。
2.2.3. PodIP,NodeIP,ClusterIP
NodeIP是k8s集群中的每个节点的物理网卡的IP地址，是一个真实存在的物理网络，所有属于这个物理网络的主机（不管这个主机在不在k8s集群内）都可以直接通信。因此，k8s集群外的节点访问k8s集群内的某个节点的TCP/IP服务时，都必须通过NodeIP通信。
PodIP是每个POD的IP地址，在使用Docker作为容器支持引擎的情况下，是Docker Engine根据docker0网桥的IP地址段进行分配的，通常是一个虚拟二层网络。K8s集群里面的Pod容器是可以互相访问的，借助了NodeIP构建了虚拟二层网络。
在k8s集群里，service的clusterIP地址属于集群内的地址，无法在集群外直接使用这个地址，k8s引入了NodePort的概念，在每个Node上为需要外部访问的service开启一个对应的TCP监听端口，外部系统使用任意一个Node的IP+NodePort即可访问此服务。如果集群中存在多个Node情况，则需要外挂一个负载均衡器，这个负载均衡器一般独立于k8s集群之外，通过是一个硬件的负载均衡器或者软件实现的haproxy或nginx。NodePort功能强大，但每个Service都需要在Node上独占一个端口，而端口是有限的物理资源，于是引入了ingress来让多个service复用端口。
每个service都会分配一个clusterIp，clusterIp的负载均衡是源端负载均衡，在client所在Node上通过iptables或ipvs选择后端pod。