k8s-005

自动装箱：基于资源依赖以及最大约束能够自动完成容器的部署，且不影响其容器的可用性
自我修复：自愈能力，一旦容器出现问题，它可以在一秒钟重新启动一个新的起来(前提：镜像是已经下载至本地并且程序本身初始化快)
水平扩展：自动实现水平扩展，当容器资源不够时，可以实现不断向上扩展(只要容器所在物理资源足够)
服务发现：自动实现服务发现
负载均衡
自动发布和回滚
秘钥和配置管理
早期非云原生的应用程序不是面向云原生而开发的，所以应用程序需要读取配置文件来获取配置；而面向云原生开发的应用程序是基于环境变量来获取配置，所以直接更改环境变量的值，那么容器中的应用在重新启动的时候则直接自动拥有了你所传递的环境变量的配置级别；传统的非云原生的容器应用程序如果想要实现读取配置文件，则需要通过写脚本进行定义然后传参的方式输入到容器应用的配置文件中。
配置中心：当镜像启动为容器时，只需要让镜像去加载外部配置中心当中的配置信息，即可完成配置；让应用程序加载配置信息时不是通过配置文件的方式去获取；我们完全可以将配置信息存储在一台服务器上，应用程序启动时不是通过配置文件来加载配置信息，而是通过服务器上所提供的配置信息直接获取，不再本地加载配置，而是通过一个第三方的服务器去加载自己的配置，通过网络先获取到，获取到之后在启动；这样的好处是配置的集中化，以后更改配置文件只需要改配置中心的配置就可以了
存储编排：把存储卷实现动态供给，根据容器需求创建实现满足其容器的存储卷
任务的批处理运行

API Server：负责接收请求，解析请求，处理请求。
Scheduler：负责去观测每个Node之上总共可用的计算CPU、RAM和存储资源，并根据用户所请求创建的这个容器所需的资源量来判断哪个Node节点最合适。
两级调度：K8S提供了一个2级调度的方式来实现资源的调度；第一步先做预选，评估每个节点到底有多少个是符合这个容器运行需求的；第二步优选，从选出来的里面选择最优的那个节点。
注：如果某个node节点宕机了，那么该node节点上的pod也会没了，这时就会通过k8s的自愈能力去另外的node节点启动相应的pod
Controller-Manager：负责维护集群的状态

kubelet：执行调度器传送的请求去执行命令；kubelet并不去进行创建容器
Docker：容器引擎，运行Pod中的容器运行
kube-proxy：负责为Service提供cluster内部的服务发现和负责均衡

K8S上最小的调度逻辑单元；
特点：将多个容器联合起来加入到同一个网络名称空间中。
一个Pod中可以运行多个容器，多个容器共享同一个底层的网络名称空间(Net\UAT\Mount)；
同一个Pod中的各容器还共享第二种资源，存储卷；存储卷不属于容器，而是属于Pod。
一般一个Pod内只放一个容器，除非容器之间有特别紧密的关系需要放置在同一个Pod中，如果放在同一个Pod中，那么其中一个容器为主容器，其他为辅助这个主容器内的应用程序完成更多的功能。
多个Pod运行在一个集群中，如何管理？如何让某个控制器只管理部分Pod？
肯定不能以Pod名称来识别(不是唯一固定的标识)；可以在Pod之上附加一些元数据，用标签(Label：kev=value)来识别Pod。可通过标签选择器selector进行过滤。

正是由于控制器机制的使用和引入，使得在kubernetes的集群设计中Pod完全可以叫做有生命周期的对象；而后由调度器将其调度至集群中的某节点运行。
ReplicationController：副本控制器
当我们启动一个Pod时，如果这个Pod不够了，那么我们可以在启动一个副本；而后控制器专门控制着同一类Pod对象的各种副本，一旦副本数量少了，它会自动添加一个副本补够；多了则剔除。
该控制器可以实现滚动更新，自动控制实现；同时也支持回滚。
ReplicaSet：副本集控制器
Deployment：无状态副本集
StatefulSet：有状态副本集
DaemonSet：每个Node上运行一个副本，而不是随意运行
Job：作业
Ctonjob：周期性任务计划作业
每一种控制器，都是用来实现某一种特定的应用管理的。

DevOps并不是一种技术，它是一种文化、是一种运动、是一种趋势；简单来说就是讲以往手动去实现或者去解决的问题，通过用工具化的方式去自动化的实现解决，从而使Dev和Ops之间可以协同工作。
CI：持续集成
开发提交代码至仓库后然后可以直接触发代码构建，构建完之后再被自动化测试工具进行各种测试，测试没有问题，然后交付给运维；如果测试有问题，将对应的代码直接打回给对应的开发人员，然后修复提交再进行构建测试，直到测试通过。
CD：持续交付，Delivery
测试完成后将对应的包传到某个可以运维直接拿到构建好的包的地方，这就是持续交付；
CD：持续部署，Deployment
测试完后的包直接可以发布到线上环境，这就是持续部署。传统方式是无法在异构的平台上进行持续部署的，不同的环境下构建打包方式不同，而有了容器技术后，不在关注程序跑在什么样的平台，不管是win环境还是linux，mac都可以直接跑起来，只要该系统中运行了容器引擎。