1.轻量级 ：使用go语言编译型语言，语言级别支持进程管理，不需要人为控制，所以以go开发的资源消耗占用资源小
2.开源
3.自我修复：对异常状态的容器进行重启或重建（先创建、再删除），目的是保证业务线不中断
4.弹性伸缩：使用命令、UI或者基于CPU使用情况自动快速扩容和缩容应用程序实例，保证应用业务高峰并发时的高可用性；且在业务低峰时回收资源，以最小成本运行服务
5.自动部署和回滚：K8S采用滚动更新策略更新应用(默认)，一次更新一个Pod，而不是同时删除所有Pod，如果更新过程中出现问题，将回滚更改，确保升级不会影响业务
5.服务发现和负载均衡：K8S为多个pod（容器）提供一个统一访问入口（内部IP地址和一个DNS名称），并且负载均衡关联的所有容器，使得用户无需考虑容器IP问题
7.机密和配置管理：管理机密数据和应用程序配置，而不需要把敏感数据暴露在镜像里，提高敏感数据安全性。并可以将一些常用的配置存储在K8S中，方便应用程序使用
8.存储编排(静态、动态)：挂载外部存储系统，无论是来自本地存储，公有云（如AWS），还是网络存储（如NFS、GlusterFS、Ceph）都作为集群资源的一部分使用，极大提高存储使用灵活性
9.批处理：提供一次性任务（job），定时任务（crontab）；满足批量数据处理和分析的场景
一个pod 会封装多个容器组成一个子节点的运行环境
最小部署单元一组容器的集合（基础容器+ 主应用容器+挂斗/副容器）
一个Pod中的容器共享网络命名空间（基础容器提供的pause）
Pod是短暂的 （叙述的是其生命周期）
pod内最少跑3个容器，分布是基础容器pause+运行容器+主应用
自主式Pod：这种Pod本身是不能自我修复的。当Pod被创建后（不论是由你直接创建还是被其它controller），都会被K8s调度到集群的Node上。直到pod的进程终止、被删掉。因为缺少资源而被驱逐、或者Node故障之前这个Pod都会一直保持在八个Node上。如果Pod运行的Node故障，或者是调度器本身故障，这个Pod就会被删除。同样的，如果Pod所在Node缺少资源或者Pod处于维护状态，Pod也会被驱逐。
控制器管理的Pod：K8s使用更高级的称为Controller的抽象层，来管理Pod实例。Controller可以创建和管理多个Pod，提供副本管理、滚动升级和集群级别的自愈能力。例如。如果一个Node故障，Controller就能自动将该节点上的Pod调度到其他健康的Node上，虽然可以直接使用Pod，但是在K8s中通常是使用Controller来管理Pod的。
K8S中资源的概念： 在kubernetes中，所有控制器，组件等都称为资源
资源清单格式（资源清单/配置文件）：在k8s中，一般使用yaml格式的文件来创建符合我们预期期望的pod
创建资源的方法
apiserver 仅接受JSON格式的资源定义
yaml格式提供配置清单，apiserver 可自动将其转为JSON格式，而后再提交
Pod 生命周期：收到kubectl指令–>初始化容器（init container），生成文件(init可以有多个，但是不可以同时运行)–>创建容器成功–>start容器–>readnessProbe(就绪性特征)：就绪检测–> liveness Probe (存活性探针)：生存检测–>stop容器
InitC：是一个pod中先于应用容器启动的容器
init总是运行到成功完成为止，init结束后pod不会退出，多个init不能同时运行
mainC主容器启动后需要一些必要的文件和目录的访问权限，而最好不包含产生这些容器的工具（冗余和安全性），所以，initC包含了这些工具和访问权限，直接给mainC提供这些文件
保证容器都启动完成，不会让容器间的关联性，启动顺序导致pod一直重启
若pod重启，所有的init都要重新执行
readiness: pod创建成功，但是容器里的应用没有部署完成，但是对外显示running，实际上并不能访问，就绪检测完成后pod才对外显示running。
liveness：liveness监测到主容器不能正常工作时，启用重启策略
Pod phase容器探针
在Pod中担任linux命名空间共享的基础
启动Pid命名空间，开启init进程
Pod hook(钩子)：是由Kubernetes管理的kubelet发起的，当容器中的进程启动前或者容器中的进程终止之前运行，这是包含在容器的生命周期之中。可以同时为Pod中的所有容器都配置 hook
Hook的类型包括两种
exec:执行一段命令
HTTP：发送HTTP请求
控制器：对不同的对象及其特性使用不同的方式控制管理
主要的控制器说明：
ReplicaSet(rc) 确保预期的Pod副本数量；无法独立存在，需要以来已deployment挥着statefulset
Deployment 无状态应用部署
StatefulSet 有状态应用部署；指的就是mysql
DaemonSet 确保所有Node运行同一种Pod；无须借助于replicaset
Job 一次性任务
Cronjob 定时任务
HPA 弹性伸缩
通过service这个统一入口/定义的访问策略对外暴露服务K8S内部的Pod
通讯是以一组私有地址进行通讯的，所以默认情况下无法直接为客户端（服务、用户）提供访问
可以通过Service服务发现，把我们内部的pod资源暴露给客户端访问（以暴露一个ip:端口的方式），让客户端可以通过这个IP：端口的形式访问到K8S内部的多个pod（通常意义上是一个应用的副本集
无状态服务：
任何一个请求都可以被任意一个实例处理
不存储状态数据，实例可以水平拓展，通过负载均衡将请求分发到各个节点
在一个封闭的系统中，只存在一个数据闭环
通常存在于单体架构的集群中
比如：LVS 服务不依赖自身的状态，实例的状态数据可以维护在内存中
有状态服务：
一个请求只能被某个节点（或者同等状态下的节点）处理
存储状态数据，实例的拓展需要整个系统参与状态的迁移
在一个封闭的系统中，存在多个数据闭环，需要考虑这些闭环的数据一致性问题
通常存在于分布式架构中
例如数据库（需要持久化）服务本身依赖或者存在局部的状态数据，这些数据需要自身持久化或者可以通过其他节点恢复
K8S会自动完成把一个新的pod 调度到对应的节点（预选/优选算法）对于生产环境上，我们往往会需要将pod创建的过程（比如创建到的节点位置）进行管理
附加到某个资源上，用于关联对象、查询和筛选
比如：label创建一个POD
编写pod yml文件：(nginx资源怎么跑，用什么环境变量，需不需要资源限制，要调度到哪个节 点） label：nginx
把pod 暴露出去：service---->通过yml文件定义 label：nginx 通过同一个label标签，进行关联，组合在一起
资源名称空间：网络、user、pid 、default、kube-system
k8s自带的名称空间：default、kube-system
生产环境：一般会新建一个namespace，专门放置一些项目/服务使用的pod资源
注释（描述性信息）
认证、鉴权、访问控制、原理及流程
从搭建集群，就需要用到加密，CA认证
管理和控制，必须先通过认证/授权，才能进行管理
跑的一些应用，nginx、squid -->需要一些访问控制策略
类似linux里面yum
helm 安装 magodb
helm 模板、自定义
K8S 也是一个典型的C/S架构，由master主控节点和node节点组成
auth：认证
身份权限的认证；客户端通过堡垒机管理node，在k8s内只有master可以管理集群，这时就需要master对node进行授权，使用的是apiserver，授权node管理集群
kube-APIserver：6443
调度、统筹k8s集群，各组件协调者，以RESTful API提供接口服务
所有对象资源的增删改查和监听操作都交给APIServer处理后再提交给 Etcd存储，从而隔离其他组件与etcd直接交互
kube-controller-manager(控制器管理中心-定义资源类型)
处理集群中常规后台任务，一个资源对应一个控制器，而ControllerManager 就是负责管理这些控制器的。
kube-scheduler：集群调度器
通过调度算法策略决定最终任务在哪个node节点上
根据调度算法（预选/优选的策略）为新创建的Pod选择一个Node节点，可以任意部署,可以部署在同一个节点上,也可以部署在不同的节点上。
etcd ：分布式键值存储系统
特性是服务自动发现，去中心化，版本是V3+，v2只支持把数据保存在内存中。用于保存k8s集群几乎所有的信息数据，包括路由状态，比如Pod、Service等对象信息
kubelet
kubelet是Master在Node节点上的Agent，管理代理的角色(kubelet)是bootstrap，kublet管理对应的node节点，及node节点与master之间的交互，kubectl会监控负责的node节点，周期性汇报给master(kubectl)
kube-proxy（四层）
使用services定义了一组pod资源的访问策略，做反向代理，只要访问到services的id即可访问到pod
docker或rocket
容器引擎，运行容器；kubelet借助于docker引擎创建容器
项目对内访问流程：
假设用户需创建 nginx资源（网站/调度）kubectl ——》auth ——》api-server基于yaml 文件的 kubectl create run / apply -f nginx.yaml(pod 一些属性，pod )
请求发送至master 首先需要经过apiserver（资源控制请求的唯一入口）
apiserver 接收到请求后首先会先记载在Etcd中
Etcd的数据库根据controllers manager（控制器） 查看创建的资源状态（有无状态化）
通过controllers 触发 scheduler (调度器)
scheduler 通过验证算法，验证架构中的nodes节点，筛选出最适合创建该资源，接着分配给这个节点进行创建
node节点中的kubelet 负责执行master给与的资源请求，根据不同指令，执行不同操作
对外提供服务则由kube-proxy开设对应的规则（代理）
container 容器开始运行（runtime 生命周期开始计算）
外界用户进行访问时，需要经过kube-proxy -》service 访问到container （四层）
如果container 因故障而被销毁了，master节点的controllers 会再次通过scheduler 资源调度通过kubelet再次创建容器，恢复基本条件限制（控制器，维护pod状态、保证期望值-副本数量）pod -->ip 进行更改–>service 定义统一入口（固定被访问的ip:端口）
项目对外访问流程：
七层：ingress-nginx/load balance
四层 ：kube-prox
service：访问策略定义一组pod
本文主要讲解了k8s的特性，基本组件以及架构
特性：
轻量级：重点在于开发的语言(解释下语言go，系统资源消耗较少)
开源：按照谷歌的borg系统设计出来并开源的产品
自我修复：控制器；控制器控制pod，保证pod可以维持我们所期望的副本数量
弹性伸缩：使用yml文件定义阈值(cgroups控制的limit的资源上限)和水平伸缩方式
自动部署、回滚：yml文件定义的部署方式watch-list技术，rollback回滚机制
服务发现、负载均衡：services+kube-proxy(L4+L7)
机密和配置管理：使用RBAC+configmap配置中心
具有自己的RBAC加密、认证机制，可以对访问、服务层面进行加密认证
存储编排使用动态+静态：
NFS GFS等网络存储+本地存储+云存储(以上是静态)，pv+pvc动态
批处理：一次性任务(job)和周期性任务(crontab)
job+crontab，帮助我们处理类似于“shell”脚本该做的事
基本组件
pod：最小资源单位
资源清单
pod控制器
服务发现
存储服务分类：有状态和无状态
调度器scheduler
label标签
namespace：名称空间
annotations：注释
集群安装：RBAC通讯加密
HELM：k8s内包的管理工具
k8s的架构：使用kubectl命令行管理工具
master组件
auth：认证
apiserver：统一入口
controller-manager：控制器管理中心
schedul：调度器
node组件
kubelet：管理本机运行容器的生命周期
kube-proxy：七层负载
docker：容器引擎，创建容器
