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/