为什么需要 K8s？

K8s 是一个容器编排平台，用于在集群中部署、扩展和管理容器化应用。

  • 最早的时候，没有虚拟机也没有容器，所有应用都是直接运行在物理机上；或者让一堆应用程序运行在不同目录里…不仅环境容易冲突，而且当宿主机死了，所有服务立刻中断。还得人（传统运维）来修，一修就是好久好久。
  • 后来 KVM 虚拟化出现了。一个服务器相当于(Node)可以运行多个虚拟机，一个虚拟机类似于(Pod，最小单元)，只运行一个应用程序实例。环境冲突的问题是解决了，但是太慢了太重了。启动一次得30s-1m甚至更久，一个Pod需要数GB，而且Pod完全有可能因为虚拟机操作系统的原因停止服务。
  • 最后，K8s 出现了，Pod 被缩小成了一个或多个容器，其虚拟机从本不应该的Pod层（最小单元层）变成了Node层。
  • K8s 还能自愈，完全不怕一个Pod死了全链路断裂。可以快速恢复，Node死了也不怕。不需要人类定位、修复。

基础学习

  • Pod：最小单元，是一个或多个容器。多容器一般是sidecar模式，目的可能是这么多个容器是模块化服务，耦合紧密，不能解藕。所以将多个容器组合成一个Pod。
    多容器特点：
    • 共享同一个网络命名空间（可以本地回环）
    • 共享存储卷
    • 生命周期一致（创建、销毁）
  • Node：节点，若干个Pods的容器运行在一台机器上，一般是一台机器属于Node，不能将多台机器拼成一个Node。
  • Service：服务，相当于中介，在Pod销毁后，新的Pod不会继承 IP 地址等信息，Service会将请求分发给其他Pod。不至于因为Pod销毁，导致链路断裂。
  • Cluster：集群，多个Node(节点；单机)组成一个集群，每个Node上可以运行多个Pod。当一个Node死了，其他Node上的Pod会继续运行。不会导致Pod中断。集群各个节点的生命周期都有 Control Plane(控制层) (不属于普通Node节点，运行在无业务Pod的节点上) 管理着。
  • 一个从上层到底层的架构如下：
graph TD
    A[应用程序代码] --> B[容器镜像
（打包好的运行环境）]
    B --> C[Pod
K8s最小调度单元
包含一个或多个容器]
    C --> D[Node节点
Pod运行的地方]
    
    D --> E1[物理机
裸金属服务器]
    D --> E2[虚拟机
云主机/VPS]
    
    E1 --> F[服务器集群
多个Node组成]
    E2 --> F
    
    F --> G[物理硬件
CPU/内存/硬盘/网卡]
  • ConfigMap：配置映射，用于将配置数据（如环境变量、配置文件等）从代码中分离出来，这样可以方便地修改配置，而不需要重新编译应用程序。
  • Secret：密钥，用于存储敏感信息（如密码、API密钥等），并将其加密存储在K8s集群中。
  • Volume：存储卷，用于将主机上的目录挂载到容器中，使数据不丢失。容器都是只读无状态的。Volume使其有状态。