1. ca-certificates, gnupg, lsb-release 三个包的解释

• ca-certificates：包含系统信任的根证书集合，用于验证 SSL/TLS 连接的安全性（如 HTTPS、容器镜像仓库通信等）。
• gnupg：GNU 隐私保护工具，用于加密、签名数据及验证签名，常用于软件包的密钥管理（如验证 Docker、K8s 软件源的合法性）。
• lsb-release：提供 Linux 标准基（LSB）相关的系统信息（如发行版名称、版本），许多脚本通过它判断系统环境。

2. docker-ce, docker-ce-cli, containerd.io, docker-compose-plugin 作用

• docker-ce：Docker 社区版引擎，核心组件，负责容器的创建、运行和管理。
• docker-ce-cli：Docker 命令行工具，提供docker命令接口，用于与 docker-ce 引擎交互。
• containerd.io：容器运行时（OCI 兼容），负责镜像管理、容器生命周期等底层操作，被 docker-ce 依赖。
• docker-compose-plugin：Docker Compose 的插件形式，用于通过 YAML 文件定义和管理多容器应用。

3. K8s 在 1.2 之后就不再支持 docker？解释对错

错误。
K8s 从 1.24 版本开始移除了对 Docker 的直接支持（移除dockershim组件），但并非完全不支持 Docker。Docker 仍可通过containerd作为中间层与 K8s 兼容（需启用 Docker 的containerd模式）。1.24 之前的版本（包括 1.2.x）均支持 Docker。

4. 举例说明创建容器以及以交互方式访问容器的命令

• 创建并启动容器（以 nginx 为例）：

  bash

  docker run -d --name my-nginx -p 8080:80 nginx  # -d：后台运行，--name：命名容器，-p：端口映射
  

• 以交互方式访问容器（进入 bash 终端）：

  bash

  docker exec -it my-nginx /bin/bash  # -it：交互式终端，my-nginx：容器名，/bin/bash：执行的命令
  

5. 部署安装 K8s 为什么要关闭 swap 分区？

K8s 要求关闭 swap 分区的主要原因是：

• 保证 Pod 资源限制（CPU / 内存）的准确性，避免节点将 Pod 内存交换到磁盘，导致性能不可预测。
• 确保 K8s 调度器基于实际可用内存进行决策，防止节点因 swap 使用而误判资源充足性。

6. 解释 br_netfilter

br_netfilter是 Linux 内核模块，用于在桥接网络中启用网络包的 iptables 过滤。在 K8s 中，它确保容器网络的数据包能被kube-proxy的 iptables 规则处理，实现 Service 的负载均衡、网络策略等功能。需手动加载并启用。

7. 解释 kubeadm, kubectl, kubelet

• kubeadm：K8s 集群部署工具，用于快速初始化控制平面、加入节点、升级集群等，简化集群搭建流程。
• kubectl：K8s 命令行工具，用于与集群 API 服务器交互，管理资源（如创建 Pod、查看节点状态等）。
• kubelet：运行在每个节点的代理程序，负责维护容器生命周期（如启动 Pod、监控容器健康状态），并向控制平面汇报节点状态。

8. 详细说明 K8s 集群的创建过程（单控制平面示例）

1. 环境准备（所有节点）：

   • 关闭防火墙（或配置规则）、SELinux、swap 分区。
   • 加载br_netfilter等内核模块，配置内核参数（如net.ipv4.ip_forward=1）。
   • 安装容器运行时（如 containerd）和依赖包（如ca-certificates）。

2. 安装 K8s 组件（所有节点）：

   • 添加 K8s 软件源，安装kubeadm、kubelet、kubectl并锁定版本。

3. 初始化控制平面（仅控制节点）：

   bash

   kubeadm init --pod-network-cidr=10.244.0.0/16  # --pod-network-cidr：指定Pod网络网段（需与网络插件匹配）
   

    
   • 按输出提示配置kubectl（复制 admin.conf 到用户目录）。

4. 部署网络插件（控制节点）：

   bash

   kubectl apply -f https://docs.projectcalico.org/v3.25/manifests/calico.yaml  # 以Calico为例
   

5. 加入工作节点（工作节点）：

   • 在控制节点执行kubeadm token create --print-join-command获取加入命令，在工作节点运行该命令。

6. 验证集群：

   bash

   kubectl get nodes  # 查看节点状态，确保所有节点为Ready
   

9. Calico 网络插件在 K8s 集群的作用

Calico 是 K8s 常用的网络插件，主要作用：

• 实现 Pod 间的跨节点通信（基于 BGP 路由协议或 IPIP 隧道）。
• 提供网络策略（NetworkPolicy），控制 Pod 间的流量访问（如允许 / 拒绝特定 Pod 的进出流量）。
• 支持网络隔离、加密通信（IPsec）等高级功能，确保容器网络的安全性和可扩展性。

10. kube-apiserver, etcd, kube-controller-manager, kube-scheduler 的作用

• kube-apiserver：所有操作的统一入口，提供 RESTful API，负责认证、授权、数据验证，是控制平面的核心。
• etcd：分布式键值存储，保存 K8s 集群的所有状态数据（如 Pod、Service 配置）。
• kube-controller-manager：运行各种控制器进程（如节点控制器、副本控制器），确保集群状态与期望状态一致（如维持 Pod 副本数）。
• kube-scheduler：负责 Pod 的调度决策，根据节点资源、亲和性等规则，选择最优节点运行 Pod。

11. kubelet, kube-proxy 作用

• kubelet：运行在每个节点，监听 API 服务器，确保 Pod 中的容器按 Pod 规范（Spec）运行（如启动、重启容器），并向控制平面汇报节点和容器状态。
• kube-proxy：运行在每个节点，通过 iptables 或 IPVS 规则实现 Service 的网络代理功能，包括负载均衡（将流量转发到后端 Pod）、会话保持等，确保 Service 的可用性。

12. 什么是 K8s 的 namespace？

Namespace 是 K8s 的资源隔离机制，用于在同一集群中划分多个虚拟 “子集群”。它可以：

• 隔离不同团队或项目的资源（如 Pod、Service），避免命名冲突。
• 通过资源配额（ResourceQuota）限制每个 namespace 的资源使用。
• 实现权限控制（如 RBAC），限制用户对特定 namespace 的操作。

13. 系统默认创建了哪几个 namespace？

K8s 默认创建 4 个 namespace：

• default：未指定 namespace 时的默认存储位置。
• kube-system：存放 K8s 系统组件（如 kube-proxy、Calico）的资源。
• kube-public：所有用户可访问（包括未认证用户），通常存放公共配置（如集群信息）。
• kube-node-lease：用于节点心跳检测（Lease 对象），提高集群稳定性。

14. 解释 Pod 是什么？

Pod 是 K8s 的最小部署单元，由一个或多个紧密关联的容器组成，共享网络命名空间（IP、端口）和存储卷（Volume）。

• 容器在 Pod 内可通过localhost通信，对外表现为一个独立的网络实体。
• Pod 是短暂的，生命周期结束后会被重新创建（如节点故障时），不具备自愈能力（需通过 Deployment 等控制器管理）。
• 适用于部署紧密协作的组件（如前端容器 + 日志收集容器）。