k8s介绍

⼀、编排分类
单机容器编排 : docker-compose
容器集群编排 : docker swarm 、 mesos+marathon 、 kubernetes
应⽤编排 : ansible( 模块,剧本,⻆⾊ )
⼆、系统管理进化史
1. 传统部署时代
早期,各个组织是在物理服务器上运⾏应⽤程序。 由于⽆法限制在
物理服务器中运⾏的应⽤程序资源使⽤,因此会导致资源分配问
题。
例如,如果在同⼀台物理服务器上运⾏多个应⽤程序, 则可能会出
现⼀个应⽤程序占⽤⼤部分资源的情况,⽽导致其他应⽤程序的性
能下降。
⽽⼀种解决⽅案是将每个应⽤程序都运⾏在不同的物理服务器上,
但是当某个应⽤程序资源利⽤率不⾼时,剩余资源⽆法被分配给其
他应⽤程序,⽽且维护许多物理服务器的成本很⾼。
2. 虚拟化部署时代 ⽽后,虚拟化技术被引⼊了。虚拟化技术允许在单个物理服务器的
CPU 上运⾏多台虚拟机 (VirtureMachine) 。 虚拟化能使应⽤程序在不
同 VM 之间被彼此隔离,且能提供⼀定程度的安全性, 因为⼀个应
⽤程序的信息不能被另⼀应⽤程序随意访问。
虚拟化技术能够更好地利⽤物理服务器的资源,并且因为可轻松地
添加或更新应⽤程序,⽽因此可以具有更⾼的可扩缩性,以及降低
硬件成本等等的好处。通过虚拟化,你可以将⼀组物理资源呈现为
可丢弃的虚拟机集群。
每个 VM 是⼀台完整的计算机,在虚拟化硬件之上运⾏所有组件,
包括其⾃⼰的操作系统,所以由此看来,虚拟机技术占⽤资源量
⼤,在⼀台主机上最多运⾏⼗⼏台,效率不⾼。
3. 容器部署时代
容器,衍⽣于虚拟技术,但具有更宽松的隔离特性,使容器可以在
共享操作系统的同时,还能保持其轻量级的特点。⽽且每个容器都
具有⾃⼰的⽂件系统、 CPU 、内存、进程空间等,且具有最良好的
可移植性和平台兼容性。
敏捷应⽤程序的创建和部署: 与使⽤ VM 镜像相⽐,提⾼了容
器镜像创建的简便性和效率
持续开发、集成和部署:通过快速简单的回滚 ( 由于镜像不可变
性 ) ,提供可靠且频繁的容器镜像构建和部署。 关注开发与运维的分离: 在构建、发布时创建应⽤程序容器镜
像,⽽不是在部署时,从⽽将应⽤程序与基础架构分离。
可观察性: 不可以显示 OS 级别的信息和指标,还可以显示应⽤
程序的运⾏状况和其他指标信。
跨开发、测试和⽣产的环境⼀致性: 在笔记本计算机上也可以和
在云中运⾏⼀样的应⽤程序。
跨云和操作系统发⾏版本的可移植性: 可在 Ubuntu 、 RHEL 、
CoreOS 、本地、 GoogleKubernetes Engine 和其他任何地⽅运
⾏。
以应⽤程序为中⼼的管理: 提⾼抽象级别,从在虚拟硬件上运⾏
OS 到使⽤逻辑资源在 OS 上运⾏应⽤程序。
松散耦合、分布式、弹性、解放的微服务: 应⽤程序被分解成较
⼩的独⽴部分, 并且可以动态部署和管理 - ⽽不是在⼀台⼤型单
机上整体运⾏。
资源隔离: 可预测的应⽤程序性能。
资源利⽤: ⾼效率和⾼密度。
三、 Kubernetes 简介
Kubernetes 缩写: K8S , k 和 s 之间有⼋个字符,所以因此得名。
Kubernetes 由 google 的 Brog 系统作为原型,后经 Go 语⾔延⽤
Brog 的思路重写,并捐献给 CNCF 基⾦会开源。 Kubernetes 是⼀个可移植的、可扩展的开源平台,⽤于管理容器化
的⼯作负载和服务,可促进声明式配置和⾃动化。
官⽹: https://kubernetes.io
Github https://github.com/kubernetes/kubernetes
四、 Kubernetes 功能
Kubernetes 的⽬标是让部署容器化的应⽤简单并且⾼效,提供了应
⽤部署,规划,更新,维护的⼀种机制。
Kubernetes 在 Docker 等容器技术的基础上,为容器化的应⽤提供
部署运⾏、资源调度、服务发现和动态伸缩等⼀系列完整功能,提
⾼了⼤规模容器集群管理的便捷性。
主要功能:

  1. 使⽤ Docker 等容器技术对应⽤程序包装 (package) 、实例化
    (instantiate) 、运⾏ (run) 。
  2. 以集群的⽅式运⾏、管理跨机器的容器,解决 Docker 跨机器容
    器之间的通讯问题。
  3. K8S 的⾃我修复机制使得容器集群总是运⾏在⽤户期望的状
    态。
    五、 Kubernetes 特性 五、 Kubernetes 特性
  4. ⾃动装箱 : Kubernetes 可以根据所需资源和其他限制条件智能
    地定位容器,⽽不会影响可⽤性。
  5. 弹性伸缩: 使⽤命令、 UI 或者基于 CPU 使⽤情况⾃动快速扩容
    和缩容应⽤程序实例,保证应⽤业务⾼峰并发时的⾼可⽤性;业
    务低峰时回收资源,以最⼩成本运⾏服务。
  6. ⾃我修复: 在节点故障时重新启动失败的容器,替换和重新部
    署,保证预期的副本数量;杀死健康检查失败的容器,并且在未
    准备好之前不会处理客户端请求,确保线上服务不中断。
  7. 服务发现和负载均衡: K8S 为多个容器提供⼀个统⼀访问⼊⼝
    (内部 IP 地址和⼀个 DNS 名称),并且负载均衡关联的所有容
    器,使得⽤户⽆需考虑容器 IP 问题。
  8. ⾃动发布(默认滚动发布模式)和回滚: K8S 采⽤滚动策略更新
    应⽤,⼀个更新⼀个 Pod ,⽽不是同时删除所有的 Pod ,如果更
    新过程中出现问题,将回滚更改,确保升级不收影响业务。
  9. 集中化配置管理和密钥管理: 管理机密数据和应⽤程序配置,⽽
    不需要把敏感数据暴露在镜像⾥,提⾼敏感数据安全性,并可以
    将⼀些常⽤的配置存储在 K8S 中,⽅便应⽤程序使⽤。
  10. 存储编排: ⽀持外挂存储并对外挂存储资源进⾏编排,挂载外部
    存储系统,⽆论是来⾃本地存储,公有云(如: AWS ),还是
    ⽹络存储(如: NFS 、 Glusterfs 、 Ceph )都作为集群资源的⼀
    部分使⽤,极⼤提⾼存储使⽤灵活性。 8. 任务批量处理运⾏: 提供⼀次性任务,定时任务,满⾜批量数据
    处理和分析的场景。
    六、 K8S 解决裸跑 Docker 的痛点
  11. 单机使⽤,⽆法有效集群。
  12. 随着容器数量的上升,管理成本攀升。
  13. 没有有效的容灾、⾃愈机制。
  14. 没有预设编排模板,⽆法实现快速、⼤规模容器调度。
  15. 没有统⼀的配置管理中⼼⼯具。
  16. 没有容器⽣命周期的管理⼯具。
  17. 没有图形化运维管理⼯具。
    七、 Kubernetes 架构
    K8S 属于主从设备模型( Mater-Slave 架构) ,由 Master 节点负责
    集群的调度、管理和运维(分配活的), Slave 节点是运算⼯作负载
    节点(⼲活的),被称为 Worker Node 节点。
    Master 需要占据⼀个独⽴服务器运⾏,因为其是整个集群的 " ⼤
    脑 " ,⼀旦宕机或不可⽤,那么所有控制命令都将失效,可对主节点
    进⾏⾼可⽤配置。 当 Worker Node 节点宕机时,其上的⼯作负载会被 Master ⾃动转
    移到其他节点上。

    1. Master 节点组件
    API Server
    * 整个集群的控制中枢,提供集群中各个模块之间的数据交换 * ,并将
    集群状态和信息存储到分布式键 - 值 (key-value) 存储系统 Etcd 集群
    中。
    同时它也是集群管理、资源配额、提供完备的集群安全机制的⼊
    ⼝,为集群各类资源对象提供增删改查以及 watch 的 REST API 接
    ⼝。 Controller-manager
    集群状态管理器,以保证 Pod 或其他资源达到期望值 * 。 * 当集群中
    某个 Pod 的副本数或其他资源因故障和错误导致⽆法正常运⾏,没
    有达到设定的值时, Controller Manager 会尝试⾃动修复并使其达到
    期望状态。
    Scheduler
    * 集群 Pod 的调度中⼼,主要是通过调度算法将 Pod 分配到最佳的
    Node 节点 * ,它通过 APIServer 监听所有 Pod 的状态,⼀旦发现新
    的未被调度到任何 Node 节点的 Pod(PodSpec.NodeName 为空 ) ,就
    会根据⼀系列策略选择最佳节点进⾏调度。
    Etcd
    * ⽤于可靠地存储集群的配置数据,是⼀种持久性、轻量型、分布式
    的键 - (key-value) 数据存储组件 * ,作为 Kubernetes 集群的持久化
    存储系统。
    注:⽣产环境建议存放到单个的 SSD 硬盘,并且做好冗余。
    2. Work Node 节点
    Kubelet
    * 负责与 Master 通信协作,管理该节点上的 Pod ,对容器进⾏健康
    检查及监控,同时负责上报节点和节点上⾯ Pod 的状态。 * Kube-proxy
    * 运⾏在每个 node 节点上,实现 pod 的⽹络代理,维护⽹络规则和
    四层负载均衡规则 * ,负责写⼊规则到 iptables 或 ipvs 实现服务映射
    访问。
    Runtime
    * 负责容器的管理 * ( 新版本 K8S 使⽤的是 Containerd) 。
    CoreDNS
    ⽤于 Kubernetes 集群内部 Service 的解析 ,可以让 Pod 把
    Service 名称解析成 Service 的 IP 然后通过 Service 的 IP 地址进⾏
    连接到对应的应⽤上。
    Calico
    符合 CNI 标准的⼀个⽹络插件,它 * 负责给每个 Pod 分配⼀个不会
    重复的 IP ,并且把每个节点当做⼀各 " 路由器 "* ,这样⼀个节点的
    Pod 就可以通过 IP 地址访问到其他节点的 Pod 。
    Docker
    * 运⾏容器,负责本机的容器创建和管理⼯作。 *
    ⼋、 Pod 概念 ⼋、 Pod 概念
    Pod 是 Kubernetes 中的基本构建块,它代表⼀个或⼀组相互关联的
    容器。 Pod 是 Kubernetes 的最⼩部署单元,可以包含⼀个或多个容
    器,这些容器共享存储、⽹络和运⾏配置。
    容器之间可以使⽤ localhost:port 相互访问,可以使⽤ volume 等实
    现数据共享。根据 Docker 的构造, Pod 可被建模为⼀组具有共享命
    令空间、卷、 IP 地址和 Port 端⼝的容器。
    Pod 的主要特点包括:
  18. 共享存储: Pod 中的所有容器都可以访问同⼀个存储卷
    ( Persistent Volume ),实现数据共享。
  19. 共享⽹络: Pod 中的所有容器都共享同⼀个⽹络命名空间,可
    以相互通信。
  20. 共享运⾏配置: Pod 中的所有容器都共享相同的运⾏配置,例
    如容器的启动参数、环境变量等。
    Pause 容器:
    Pod 的⽗容器,它主要负责僵⼫进程的回收管理,同时通过 Pause
    容器可以使同⼀个 Pod ⾥⾯的不同容器进⾏共享存储、⽹络、
    PID 、 IPC 等。
    九、 Kubernetes ⼯作流程 九、 Kubernetes ⼯作流程
  21. 运维⼈员使⽤ kubectl 命令⼯具向 API Server 发送请求, API
    Server 接收请求后写⼊到 Etcd 中。
  22. API Server 让 Controller-manager 按照预设模板去创建 Pod 。
  23. Controller-manager 通过 API Server 读取 Etcd 中⽤户的预设信
    息,再通过 API Server 找到 Scheduler ,为新创建的 Pod 选择
    最合适的 Node ⼯作负载节点。
  24. Scheduler 通过 API Server 在 Etcd 找到存储的 Node 节点元信
    息、剩余资源等,⽤预选和优选策略选择最优的 Node 节点。
  25. Scheduler 确定 Node 节点后,通过 API Server 交给这个 Node
    节点上的 Kubelet 进⾏ Pod 资源的创建。
  26. Kubelet 调⽤容器引擎交互创建 Pod ,同时将 Pod 监控信息通
    过 API Server 存储到 Etcd 中。
  27. 当⽤户访问时,通过 Kube-proxy 负载、转发,访问相应的
    Pod 。
  28. 注: 决定创建 Pod 清单的是 Controller-manager 控制器,
    Kubelet 和容器引擎只是⼲活的。

    ⼗、 K8S 创建 Pod 流程
    1. 详细流程
    ⾸先 Kubectl 创建⼀个 Pod ,在提交时转化为 json 。
    再经过 auth 认证 ( 鉴权 ) ,然后传递给 API Server 进⾏处理。
    API Server 将请求信息存储到 Etcd 中。 Scheduler 和 Controller-manager 会监听 API Server 的请求。
    在 Scheduler 和 Controller-manager 监听到请求后, Scheduler
    会提交给 API Server ⼀个 list 清单 ------ 包含的是获取 node 节点信
    息。
    当 API Server 从 Etcd 获取后端 Node 节点信息后,会同时被
    Scheduler 监听到,然后 Scheduler 进⾏优选打分制,最后将评
    估结果传递给 API Server 。
    ⽽后, API Server 会提交清单给对应节点的 Kubelet (代理)。
    Kubelet 代理通过 K8S 与容器的接⼝ ( 例如 containerd) 进⾏交
    互,假设是 docker 容器,那么此时 kubelet 就会通过
    dockershim 以及 runc 接⼝与 docker 的守护进程 docker-server
    进⾏交互,来创建对应的容器,再⽣成对应的 Pod 。
    Kubelet 同时会借助 Metric Server 收集本节点的所有状态信
    息,然后提交给 API Server 。
    最后 API Server 将该节点的容器和 Pod 信息存储到 Etcd 中。
    2. 简化流程
    ⽤户通过 kubectl 或其他 API 客户端提交 Pod Spec 给 API
    Server 。
    API Server 尝试将 Pod 对象的相关信息存⼊ etcd 中,待写⼊操
    作执⾏完成, API Server 即会返回确认信息⾄客户端。 Controller 通过 API Server 的 Watch 接⼝发现新的 Pod ,将
    Pod 加⼊到任务队列,并启动 Pod Control 机制创建与之对应的
    Pod 。
    所有 Controler 正常后,将结果存⼊ etcd 。
    Scheduler 通过 API Server 的 Watch 接⼝监测发现新的 Pod ,
    经过给主机打分之后,让 Pod 调度到符合要求的 Node 节点,
    并将结果存⼊到 etcd 中。
    Kubelet 每隔⼀段时间向 API Server 通过 Node name 获取⾃身
    Node 上要运⾏的 Pod 并通过与⾃身缓存⽐较,来创建新
    Pod 。
    Containerd 启动容器。
    最后 API Server 将本节点的容器和 Pod 信息存储到 etcd 。
相关推荐
昌sit!1 小时前
K8S node节点没有相应的pod镜像运行故障处理办法
云原生·容器·kubernetes
A ?Charis3 小时前
Gitlab-runner running on Kubernetes - hostAliases
容器·kubernetes·gitlab
wclass-zhengge4 小时前
Docker篇(Docker Compose)
运维·docker·容器
茶馆大橘4 小时前
微服务系列五:避免雪崩问题的限流、隔离、熔断措施
java·jmeter·spring cloud·微服务·云原生·架构·sentinel
北漂IT民工_程序员_ZG4 小时前
k8s集群安装(minikube)
云原生·容器·kubernetes
coding侠客5 小时前
揭秘!微服务架构下,Apollo 配置中心凭啥扮演关键角色?
微服务·云原生·架构
梦魇梦狸º7 小时前
腾讯轻量云服务器docker拉取不到镜像的问题:拉取超时
docker·容器·github
南猿北者10 小时前
docker镜像仓库常用命令
运维·docker·容器
2301_8061313611 小时前
Kubernetes的基本构建块和最小可调度单元pod-0
云原生·容器·kubernetes
SilentCodeY12 小时前
containerd配置私有仓库registry
容器·kubernetes·containerd·镜像·crictl