kubernetes是什么？
2014年，Google以Borg为根底，开源了kubernetes，简称k8s，一个以后最火的容器集群管理系统就此诞生。
官网：http://www.kubernets.io
kubernetes三个外围性能
Kubernetes - 调度
kubernetes能够将容器放入集群中进行调度，比方有一个容器，须要2C2G的资源，kubernetes就会将这个容器主动的调度到集群闲暇或者有足够资源的节点上
Kubernetes - 主动复原
kubernetes会对集群内的宿主机进行状态查看，如呈现故障，kubernetes会把运行在失败节点上的容器进行主动迁徙，迁徙到衰弱的资源节点下面
Kubernetes - 程度伸缩
kubernetes有利用负载查看的能力，能够检测业务上所承当的负载，如果一个业务响应时长过高，或者负载很高，能够对该业务进行扩容
kubernetes个性
自我修复
在节点产生故障时，重启失败的容器，保障预期的正本数，并确保优雅高低线(容器启动中时不对外提供服务)
弹性伸缩
依据一些指标(CPU、内存、负载等)配置主动扩容和缩容利用容器，保障在不同业务压力下的集群规模
主动部署和回滚
k8s默认先部署新的容器，部署实现后，再替换老的容器，如果公布过程中产生故障，则回滚操作
服务发现和负载平衡
k8s为多个容器提供对立入口(外部ip地址和一个dns名称)，并负载关联所有容器，使得用户无需思考容器ip地址
秘密和配置管理
治理秘密数据和应用程序配置，而不须要把敏感数据裸露在镜像里，进步敏感数据安全性，并能够将罕用的配置存储在k8s中，不便程序应用
存储编排
挂载内部存储系统，无论来自本地存储、私有云(如oss)、还是网络存储，都能够作为集群资源的一部分应用，极大的进步存储应用的灵活性
定时工作
提供一次性工作、定时工作，相似Linux服务器的crontab
kubernetes架构
kubernetes是一个比拟典型的二层架构， Master作为地方的管控节点，所有的UI、CLI、Node节点跟Master通信。UI CLI把想要的命令发给Master，Master将命令下发给Node节点进行最终的执行
kubernetes中所有的组件都会和API Server连贯，组件与组件之间，个别不进行独立的连贯，都依赖于API Server进行音讯的传送
官网参考:https://kubernetes.io/docs/concepts/overview/components/
Master组件
Master是集群的管制平台
- master组件负责集群中的全局决策(如调度)
- master组件探测并响应集群事件(当 Deployment 的理论 Pod 正本数未达到 replicas 字段的规定时，启动一个新的 Pod)
Master组件能够运行在集群中的任何机器上，但为了简洁，通常会运行所有的master组件，且不在此机器上运行容器
kube-apiserver
提供kubernetes的api，能够程度扩大以进步性能和高可用，kubctl等管理工具就是通过apiserver实现对kubernetes的治理
etcd
分布式高可用的键值对存储组件，API server中所须要的元信息都被搁置在etcd，通过etcd保障kubernetes组件的高可用
kube-scheduler
资源调度组件，监控所有新创建尚未调配到节点上的Pod，并且主动为Pod抉择一个适合的节点去运行
调度的因素包含：
- 单个或多个pod的资源申请
- 硬件、软件、策略的限度
- 亲和性和反亲和性标准(affinity and anti-affinity specifications)
- 数据本地化要求
- 工作负载间相互作用
kube-controller-manager
控制器过程组件，逻辑上来说，每个控制器是一个独立的过程，但为了升高复杂度，它们都被编译成一个二进制文件并在单个过程中运行
这些组件包含：
- 节点(Node)控制器：监听所有节点停机事件并作出响应
- 正本(Replication)控制器：保护集群中的正本控制器对象所冀望的Pod正本数
- 端点(Endpoints)控制器：为端点对象(joins Services & Pods)赋值
- Service Account & Token控制器： 负责为新的名称空间创立 default Service Account 以及 API Access Token
cloud-controller-manager
该组件运行了与具体云基础设施供应商互动的控制器，通过 cloud-controller-manager，Kubernetes能够更好地与云供应商联合，例如，在阿里云的 Kubernetes 在云控制台界面上轻松点击鼠标，即可实现 Kubernetes 集群的创立和治理
Node组件
Node是真正运行业务负载的，以Pod的形式运行，一个Pod中运行一个或者多个容器
Node并不会和User进行间接的通信，它只会和Master通信
kubelet
Kubelet是真正去运行pod的组件，是Node上最为要害的组件，它通过apiserver承受到Pod运行的状态，而后提交到最底层的四个组件(Container Runtime、Storage Plugin、Network Plugin、Kube-proxy)，创立容器所须要的运行环境，将容器运行起来
次要包含：
- 创立容器
- 下载secret
- Pod挂载数据卷
- 获取节点和容器状态
留神：kubelet只治理Kubernetes创立的容器
kube-proxy
Kube-proxy实现service组网，为Node节点上实现Pod网络代理，运行在集群中的每一个节点上，保护网络规定和实现四层负载平衡，是实现 Kubernetes Service 概念的重要局部
kube-proxy在节点上保护网络规定，使集群内、集群外正确地与 Pod 进行网络通信。如果操作系统中存在 packet filtering layer，kube-proxy 将应用这一个性（iptables代理模式），否则，kube-proxy将自行转发网络申请（User space代理模式
容器运行引擎
容器引擎负责运行容器。Kubernetes反对多种容器引擎：Docker、containerd、cri-o、rktlet 以及任何实现了 Kubernetes容器引擎接口的容器引擎
Kubernetes 外围概念
外围概念 - Pod
一个逻辑单位，多个容器的组合，kubernetes的原子调度单位
Google工程师们发现，在Borg我的项目部署的利用，往往都存在着相似于“过程和过程组”的关系，更具体的说，就是这些利用之间有着亲密的协作关系，使得它们必须部署在同一台机器上并且共享某些信息，因而每个容器相当于一个过程，Pod相当于过程组，使得这些容器能够更高的合作
- 最小的调度以及资源单位
- 由一个或者多个容器组成
- 定义容器运行的形式(Command、环境变量等)
- 提供给容器共享的运行环境(网络、过程空间)
- pod与pod之间是相互隔离的
- Pod共享网络和存储
- Pod是短暂的(随着服务进行，Pod也将销毁)
外围概念 - Volume
用于治理kuberntes中的存储
- 申明在Pod中的容器可拜访的文件目录
- 能够被挂载在Pod中一个(或者多个)容器的指定门路下
- 反对多种后端存储的形象(本地存储、分布式存储、云存储)
Pod - > Volume -> Remote Block Device
外围概念 - Deployment
这是一个在Pod之上的抽象概念，比方一组Pod形成的一个利用，pod是组成Deployment最小的单元
- 定义一组Pod的正本数目、版本等
- 通过控制器(Controller)维持Pod的数目(主动复原失败的Pod)
- 通过控制器以指定的策略管制版本(滚动降级、从新生成、回滚等)
外围概念 - Service
其实就是一个VIP提供给内部拜访
- 提供拜访一个或多个Pod实例的稳固拜访地址
- 反对多种拜访形式实现(ClusterIP、NodePort、LoadBalancer)
外围概念 - Namespaces
- 一个集群外部的逻辑隔离机制（鉴权、资源额度）
- 每个资源都属于一个Namespace
- 同一个Namespace中的资源命名惟一
- 不同Namespace中的资源可重名
参考
https://kubernetes.io/zh/docs...
https://kuboard.cn/learning/