一、 来源

bilibili尚硅谷Kubernetes（新版）视频：链接
哔哩哔哩汪洋老师旧版
中文官网：https://kubernetes.io/zh
中文社区：https://www.kubernetes.org.cn/
K8S就是Kubernetes，中间一共有8个字母，简称K8s
推荐技术路线：民工哥2021最新k8s学习路线

需要了解

  • Linux操作系统（需要总结Linux常用命令）

  • Docker（详见狂神docker笔记）

    详情

  • K8s概念和架构

  • 从零搭建K8s集群
    • 基于客户端工具kubeadm搭建（命令方式）
    • 基于二进制包方式（太长没看）
  • K8s核心概念
    • Pod：K8s管理的最小单位级，是所有业务类型的基础
    • Controller：控制器，有状态，无状态，一次任务，定时任务，守护进程
    • Service Ingress：对外暴露端口
    • RBAC：安全机制，权限模型
    • Helm：下载机制
    • 持久化存储
  • 搭建集群监控平台系统
  • 从零搭建高可用K8s集群
  • 在集群环境部署项目

    二、 K8S概念和特性

    2.1 部署发展历程

    我们的项目部署也在经历下面的这样一个历程

    传统部署 -> 虚拟化部署时代 -> 容器部署时代

Kubernetes简介 - 图1

  • 传统部署时代：早期，组织在物理服务器上运行应用程序。无法为物理服务器中的应用程序定义资源边界，这会导致资源分配问题。例如，如果在物理服务器上运行多个应用程序，则可能会出现一个应用程序占用大部分资源的情况，结果可能导致其他应用程序的性能下降。一种解决方案是在不同的物理服务器上运行每个应用程序，但是由于资源利用不足而无法扩展，并且组织维护许多物理服务器的成本很高。

tip：资源分配不均，许多服务器的话成本很高！

  • 虚拟化部署时代：作为解决方案，引入了虚拟化功能，它允许您在单个物理服务器的CPU上运行多个虚拟机（VM）。虚拟化功能允许应用程序在VM之间隔离，并提供安全级别，因为一个应用程序的信息不能被另一应用程序自由地访问。因为虚拟化可以轻松地添加或更新应用程序、降低硬件成本等等，所以虚拟化可以更好地利用物理服务器中的资源，并可以实现更好的可伸缩性。每个VM是一台完整的计算机，在虚拟化硬件之上运行所有组件，包括其自己的操作系统。

tip： 引入虚拟化，单个服务器上运行多个虚拟机，在虚拟机直接做隔离！

  • 容器部署时代：容器类似于VM，但是它们具有轻量级的隔离属性，可以在应用程序之间共享操作系统 （OS），因此，容器被认为是轻量级的。容器与VM类似，具有自己的文件系统、CPU、内存、进程空间等。由于它们与基础架构分离，因此可以跨云和OS分发进行移植。

tip： 轻量级隔离属性，可以共享操作系统

容器因具有许多优势而变得流行起来。下面列出了容器的一些好处：

  • 敏捷应用程序的创建和部署：与使用VM镜像相比，提高了容器镜像创建的简便性和效率。
  • 持续开发、集成和部署：通过简单的回滚（由于镜像不可变性），提供可靠且频繁的容器镜像构建和部署。
  • 关注开发与运维的分离：在构建/时而不是在部署时创建应用程序容器镜像，将应用程序与基础架构分离。
  • 可观察性：不仅可以显示操作系统级别的信息和指标，还可以显示应用程序的运行状况和其他指标信号。
  • 跨开发、测试和生产的环境一致性：在便携式计算机上与在云中相同地运行。
  • 云和操作系统分发的可移植性：可在Ubuntu、RHEL、RHEL、CoreOS、本地、Google Kubernetes Engine和其它任何其它地方运行。
  • 以应用程序为中心的管理：提高抽象级别，从在虚拟硬件上运行OS到使用逻辑资源在OS上运行应用程序。
  • 松散耦合、分布式、弹性、解放的微服务：应用程序被分解成较小的独立部分，并且可以动态部署和管理，而不是在一台大型单机上器体运行。
  • 资源隔离：可预测的应用程序性能。

tip ：说了一堆，体会不到，慢慢看吧！

2.2 K8S概述

  1.      kubernetes，简称K8s，是用8 代替8 个字符“ubernete”而成的缩写。是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes 的目标是让部署容器化的应用简单并且高效（powerful）,Kubernetes 提供了应用部署，规划，更新，维护的一种机制。
  2.     传统的应用部署方式是通过插件或脚本来安装应用。这样做的缺点是应用的运行、配置、管理、所有生存周期将与当前操作系统绑定，这样做并不利于应用的升级更新/回滚等操作，当然也可以通过创建虚拟机的方式来实现某些功能，但是虚拟机非常重，并不利于可移植性。
  3.     新的方式是通过部署容器方式实现，每个容器之间互相隔离，每个容器有自己的文件系统，容器之间进程不会相互影响，能区分计算资源。相对于虚拟机，容器能快速部署，由于容器与底层设施、机器文件系统解耦的。

总结：

  • K8s是谷歌在2014年发布的容器化集群管理系统
  • 使用k8s进行容器化应用部署
  • 使用k8s利于应用扩展
  • k8s目标实施让部署容器化应用更加简洁和高效
  • 通过Kubernetes 能够进行应用的自动化部署和扩缩容。

    2.3 K8S功能

    1. 自动装箱

    基于容器对应用运行环境的资源配置要求自动部署应用容器

    2. 自我修复(自愈能力)

    当容器失败时，会对容器进行重启
    当所部署的Node节点有问题时，会对容器进行重新部署和重新调度（👍！）
    当容器未通过监控检查时，会关闭此容器直到容器正常运行时，才会对外提供服务
    Kubernetes简介 - 图2
    如果某个服务器上的应用不响应了，Kubernetes会自动在其它的地方创建一个
    Kubernetes简介 - 图3

    3. 水平扩展

通过简单的命令、用户UI 界面或基于CPU 等资源使用情况，对应用容器进行规模扩大或规模剪裁

当我们有大量的请求来临时，我们可以增加副本数量，从而达到水平扩展的效果

当黄色应用过度忙碌，会来扩展一个应用
Kubernetes简介 - 图4

4. 服务发现

用户不需使用额外的服务发现机制，就能够基于Kubernetes 自身能力实现服务发现和负载均衡

对外提供统一的入口，让它来做节点的调度和负载均衡， 相当于微服务里面的网关？ 我也不知道

Kubernetes简介 - 图5

5. 滚动更新

可以根据应用的变化，对应用容器运行的应用，进行一次性或批量式更新

添加应用的时候，不是加进去就马上可以进行使用，而是需要判断这个添加进去的应用是否能够正常使用

6. 版本回退

可以根据应用部署情况，对应用容器运行的应用，进行历史版本即时回退

类似于Git中的回滚

7. 密钥和配置管理

在不需要重新构建镜像的情况下，可以部署和更新密钥和应用配置，类似热部署。

8. 存储编排

自动实现存储系统挂载及应用，特别对有状态应用实现数据持久化非常重要
存储系统可以来自于本地目录、网络存储(NFS、Gluster、Ceph 等)、公共云存储服务

9. 批处理

提供一次性任务，定时任务；满足批量数据处理和分析的场景

三、K8S架构组件

完整架构图

k8s总架构图：
Kubernetes简介 - 图6

Kubernetes 遵循非常传统的客户端/服务端的架构模式，客户端可以通过 RESTful 接口或者直接使用 kubectl 与 Kubernetes 集群进行通信，这两者在实际上并没有太多的区别，后者也只是对 Kubernetes 提供的 RESTful API 进行封装并提供出来。每一个 Kubernetes 集群都是由一组 Master 节点和一系列的 Worker 节点组成，其中 Master 节点主要负责存储集群的状态并为 Kubernetes 对象分配和调度资源。

就是说
Kubernetes简介 - 图7
一个和总框架图一样的图，更美观，表达的意思是一样的！
Kubernetes简介 - 图8

架构细节

K8S架构主要包含两部分：Master（主控节点）和 node（工作节点）
k8s 集群控制节点，对集群进行调度管理，接受集群外用户去集群操作请求；

master节点：主控节点

  • API Server：集群统一入口，以restful风格进行操作，同时交给etcd存储
    • 提供认证、授权、访问控制、API注册和发现等机制
    • 负责处理来自用户的请求，其主要作用就是对外提供 RESTful 的接口，包括用于查看集群状态的读请求以及改变集群状态的写请求，也是唯一一个与 etcd 集群通信的组件。
  • scheduler：节点的调度，选择node节点应用部署
    • 主节点上的组件，该组件监视那些新创建的未指定运行节点的 Pod，并选择节点让 Pod 在上面运行。调度决策考虑的因素包括单个 Pod 和 Pod 集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置、工作负载间的干扰和最后时限。
  • controller-manager：处理集群中常规后台任务，一个资源对应一个控制器
    • 在主节点上运行控制器的组件，从逻辑上讲，每个控制器都是一个单独的进程，但是为了降低复杂性，它们都被编译到同一个可执行文件，并在一个进程中运行。这些控制器包括：节点控制器(负责在节点出现故障时进行通知和响应)、副本控制器(负责为系统中的每个副本控制器对象维护正确数量的 Pod)、端点控制器(填充端点 Endpoints 对象，即加入 Service 与 Pod))、服务帐户和令牌控制器(为新的命名空间创建默认帐户和 API 访问令牌)。
  • etcd：存储系统，用于保存集群中的相关数据
    • 是兼具一致性和高可用性的键值数据库，可以作为保存 Kubernetes 所有集群数据的后台数据库。

Kubernetes简介 - 图9

Node节点：工作节点

其他的 Worker 节点实现就相对比较简单了，它主要由 kubelet 和 kube-proxy 两部分组成。
Kubernetes简介 - 图10

  • Kubelet：master派到node节点代表，管理本机容器
    • 一个集群中每个节点上运行的代理，它保证容器都运行在Pod中
    • 负责维护容器的生命周期，同时也负责Volume(CSI) 和 网络(CNI)的管理
    • 是工作节点执行操作的 agent，负责具体的容器生命周期管理，根据从数据库中获取的信息来管理容器，并上报 pod 运行状态等。
  • kube-proxy：提供网络代理，负载均衡等操作
    • 是一个简单的网络访问代理，同时也是一个 Load Balancer。它负责将访问到某个服务的请求具体分配给工作节点上同一类标签的 Pod。kube-proxy 实质就是通过操作防火墙规则(iptables或者ipvs)来实现 Pod 的映射。
    • Kubernetes简介 - 图11

其他：容器运行环境+fluentd

  • 容器运行环境【Container Runtime】
    • 容器运行环境是负责运行容器的软件
    • Kubernetes支持多个容器运行环境：Docker、containerd、cri-o、rktlet以及任何实现Kubernetes CRI (容器运行环境接口) 的软件。

  • fluentd：是一个守护进程，它有助于提升 集群层面日志

    四、 K8S核心概念

    Pod

  • Pod是K8s中最小的单元

  • 一组容器的集合
  • 共享网络【一个Pod中的所有容器共享同一网络】

  • 生命周期是短暂的（服务器重启后，就找不到了）

    Volume

  • 声明在Pod容器中可访问的文件目录

  • 可以被挂载到Pod中一个或多个容器指定路径下

  • 支持多种后端存储抽象【本地存储、分布式存储、云存储】

    Controller

  • 确保预期的pod副本数量【ReplicaSet】

  • 无状态应用部署【Depoltment】
    • 无状态就是指，不需要依赖于网络或者ip
  • 有状态应用部署【StatefulSet】
    • 有状态需要特定的条件
  • 确保所有的node运行同一个pod 【DaemonSet】

  • 一次性任务和定时任务【Job和CronJob】

    Deployment

  • 定义一组Pod副本数目，版本等

  • 通过控制器【Controller】维持Pod数目【自动回复失败的Pod】
  • 通过控制器以指定的策略控制版本【滚动升级、回滚等】

Kubernetes简介 - 图12

Service

  • 定义一组pod的访问规则
  • Pod的负载均衡，提供一个或多个Pod的稳定访问地址
  • 支持多种方式【ClusterIP、NodePort、LoadBalancer】

Kubernetes简介 - 图13
可以用来组合pod，同时对外提供服务

Label

label：标签，用于对象资源查询，筛选
image.png

Namespace

命名空间，逻辑隔离

  • 一个集群内部的逻辑隔离机制【鉴权、资源】
  • 每个资源都属于一个namespace
  • 同一个namespace所有资源不能重复

  • 不同namespace可以资源名重复

    API

    我们通过Kubernetes的API来操作整个集群
    同时我们可以通过 kubectl 、ui、curl 最终发送 http + json/yaml 方式的请求给API Server，然后控制整个K8S集群，K8S中所有的资源对象都可以采用 yaml 或 json 格式的文件定义或描述
    如下：使用yaml部署一个nginx的pod
    Kubernetes简介 - 图15

    五 、 完整流程

    Kubernetes简介 - 图16

  • 通过Kubectl提交一个创建RC（Replication(复制） Controller）的请求，该请求通过APlserver写入etcd

  • 此时Controller Manager通过API Server的监听资源变化的接口监听到此RC事件
  • 分析之后，发现当前集群中还没有它所对应的Pod实例
  • 于是根据RC里的Pod模板定义一个生成Pod对象，通过APIServer写入etcd
  • 此事件被Scheduler发现，它立即执行执行一个复杂的调度流程，为这个新的Pod选定一个落户的Node，然后通过API Server讲这一结果写入etcd中
  • 目标Node上运行的Kubelet进程通过APiserver监测到这个”新生的Pod.并按照它的定义，启动该Pod直到Pod的生命结束
  • 随后，通过Kubectl提交一个新的映射到该Pod的Service的创建请求
  • ControllerManager通过Label标签查询到关联的Pod实例，然后生成Service的Endpoints（端点）信息，并通过APIServer写入到etcd中
  • 接下来，所有 Node 上运行的Proxy进程通过API Server查询并监听Service对象与其对应的 Endpoints 信息，建立一个软件方式的负载均衡器来实现 Service 访问到后端 Pod 的流量转发功能

写的太复杂了,简单来说就是：（emmm。。。）
Kubernetes简介 - 图17
复杂，不看了！