k8s docker总结特殊点

前言

多点docker、k8s了解与某些参数配置的异同点，出现问题便于排查,有助于学习。

一、docker 的驱动。

看一个/etc/docker/daemon.json
显而易见的driver有cgroupdriver、log-driver
优先看他俩:

1、cgroup:（Control Groups）

查看本地所使用的

docker info | grep "Cgroup Driver"

概念： cgroup 是 Linux 内核提供的一种机制，用于限制、账户和隔离进程组。目前使用最多的systemd，次cgroupfs。其他作为了解

错误：最常见的是当你k8s某些服务器资源重启后加入不了集群时，一看报错驱动问题

cgroupfs： cgroupfs 是 Docker 最早支持的 cgroup 驱动，它使用 cgroup 文件系统进行资源管理和隔离。这是 Docker 1.13 之前版本的默认 cgroup 驱动。

systemd： systemd 是 Linux 上的一个系统和服务管理器，也是一种 cgroup 驱动。Docker 可以通过配置使用 systemd 作为 cgroup 驱动，这种方式通常与运行 systemd 的系统集成得更好。

unified（Unified Control Group）： 统一的 cgroup 驱动是 Linux 4.5 及以上内核引入的，它将 cgroup v1 和 cgroup v2 合并为一个单一的层次结构。Docker 从版本 20.10 开始默认使用 unified cgroup 驱动。这种驱动对 cgroup v2 的支持更为完整，但仍然保留对 cgroup v1 的兼容性。

{
  "data-root": "/var/lib/docker",
  "exec-opts": ["native.cgroupdriver=systemd"],
  "registry-mirrors": [
    "https://docker.mirrors.ustc.edu.cn",
    "http://hub-mirror.c.163.com"
  ], 
  "insecure-registries": ["127.0.0.1/8","k8s.harbor.com"],
  "max-concurrent-downloads": 10,
  "live-restore": true,
  "log-driver": "json-file",
  "log-level": "warn",
  "log-opts": {
    "max-size": "50m",
    "max-file": "1"
    },
  "storage-driver": "overlay2"
}

2、日志驱动（log driver）

**概念：**用于处理和存储容器的日志。以下是一些常见的 Docker 日志驱动：最常用的json-file、syslog。其他作为了解

错误：当某些开源软件部署方面遇到syslog错误时，那可能就是你开源软件自定义了log驱动与你本地docker环境log驱动不匹配导致。

json-file： 默认的日志驱动，将容器的标准输出和标准错误输出保存到 JSON 格式的文件中。可以使用 docker logs 命令查看容器的日志。

syslog： 将容器日志发送到 syslog（系统日志）中，使其可由宿主机上的 syslog 守护程序处理。这对于集中管理日志非常有用。

journald： 将容器日志发送到 systemd-journald，适用于运行 systemd 的系统。可以使用 journalctl 命令查看容器的日志。

fluentd： 使用 Fluentd 进行日志收集。Fluentd 是一款开源的日志收集工具，支持灵活的日志传输和处理。

gelf： 将容器日志发送到 Graylog Extended Log Format（GELF）兼容的日志收集器。GELF 是一种结构化的日志格式，适用于分布式日志系统。

awslogs： 将容器日志发送到 Amazon CloudWatch Logs，适用于在 AWS 上运行的容器。

etwlogs： 仅适用于 Windows 容器，将容器日志发送到 Windows Event Tracing for Windows (ETW)。

splunk： 将容器日志发送到 Splunk，适用于使用 Splunk 进行日志分析的环境。

logentries： 将容器日志发送到 Logentries，适用于集中管理和分析日志。

可以通过在运行容器时使用 --log-driver 选项来指定日志驱动。例如：

docker run --log-driver=json-file my-container

要查看系统上可用的日志驱动，可以运行以下命令：

docker info | grep "Logging Driver"

3、存储驱动

概念：存储驱动负责实现镜像和容器存储的组件。基本选用默认overlay2。其他作为了解

overlay2： overlay2 是 Docker 默认的存储驱动，适用于大多数 Linux 发行版。它提供了高性能的联合文件系统，支持镜像分层和容器存储。

aufs： aufs（Advanced Multi-Layered Unification Filesystem）是一个老化的存储驱动，已被 overlay2 取代。aufs 适用于较早版本的 Docker，但在新的内核版本中可能不再受支持。

overlay： overlay 是 overlay2 的前身，也是一个联合文件系统，但相对于 overlay2，它在性能和功能上有一些限制。

btrfs： btrfs 是一种先进的文件系统，Docker 可以使用它作为存储驱动。btrfs 支持快照、复制等高级功能。

devicemapper： devicemapper 是一种基于设备映射技术的存储驱动。它提供了块设备的级别的存储，支持快照和写时复制。

vfs（Virtual File System）： vfs 是一种简单的存储驱动，适用于测试和开发环境。它是 Docker 最基本的存储驱动，性能较差，不建议在生产环境中使用。

要查看当前 Docker 实例正在使用的存储驱动，可以运行以下命令：

docker info | grep "Storage Driver"

4、网络驱动：

概念： 允许用户根据应用程序的需求选择合适的网络模式。

bridge： bridge 是 Docker 默认的网络驱动，用于创建容器默认的桥接网络。每个容器都连接到这个默认的桥接网络，可以通过容器名称或 IP 地址直接相互通信。

docker run --network bridge my-container

host： host 网络模式允许容器共享主机的网络命名空间，即与主机相同的网络。这样容器可以直接使用主机的网络配置，适用于性能敏感的场景。

docker run --network host my-container

none： none 网络模式会禁用容器的网络栈，使其无法访问网络。适用于特定安全场景或仅需要本地 IPC 通信的容器。

docker run --network none my-container

overlay： overlay 网络模式用于创建多主机之间的覆盖网络。适用于跨多个主机的容器通信，通常与 Docker Swarm 结合使用。

docker run --network overlay my-container

macvlan： macvlan 允许容器直接映射到物理网络，每个容器都有唯一的 MAC 地址。适用于需要容器直接暴露到物理网络的场景。

docker run --network macvlan my-container

ipvlan： ipvlan 类似于 macvlan，但允许多个容器共享相同的 MAC 地址。适用于需要在物理网络上分配 IP 地址的场景。

docker run --network ipvlan my-container

bridge、host、none 的自定义桥接网络： 可以使用 bridge、host 或 none 模式创建自定义桥接网络，通过 docker network create 命令。

docker network create my-bridge-network
docker run --network my-bridge-network my-container

二、k8s中网络插件（常用calico，次flannel）

**网络插件：**用于配置容器间的通信和网络策略。这些网络插件负责实现 Kubernetes 群集中 Pod 之间的网络通信。

Flannel:

特点： Flannel 是一个简单且易于部署的网络插件，使用基于层级的虚拟网络（Overlay Network）实现容器间的通信。
工作原理： 使用 VXLAN 或 UDP 封装技术在不同节点上创建虚拟网络，允许 Pod 通过该虚拟网络进行通信。
适用场景： 适用于需要快速部署和简单网络配置的场景。

Calico:

特点： Calico 是一个开源的网络插件，提供了强大的网络策略和安全性功能。它支持 BGP 协议用于路由。
工作原理： 使用路由表来处理容器之间的通信，支持网络隔离和安全策略。
适用场景： 适用于需要强大网络策略和安全性的场景，特别是多租户环境。

Weave:

特点： Weave 是一个轻量级的网络插件，支持容器的动态发现和路由。它通过 DNS 提供服务发现功能。
工作原理： 使用虚拟网络技术，包括 Overlay Network 和路由。
适用场景： 适用于需要轻量级网络插件和服务发现的场景。

Cilium:

特点： Cilium 是一个强大的网络和安全插件，支持容器的负载均衡、网络隔离和安全策略。
工作原理： 使用 eBPF（Extended Berkeley Packet Filter）技术，允许对网络数据包进行高级的处理。
适用场景： 适用于需要强大网络功能和安全性的场景，尤其是具有复杂网络需求的环境。

Antrea:

特点： Antrea 是一个基于 Open vSwitch（OVS）的网络插件，提供网络策略和安全性功能。
工作原理： 使用 OVS 技术来处理容器之间的通信，并支持网络策略。
适用场景： 适用于需要基于 OVS 的网络插件的场景。

三、Dockerfile中极个别字段作用、区别

ADD、COPY

COPY： 用于将本地文件或目录复制到容器中。它是比较基础的文件复制指令，不做任何解压或处理。

COPY <src> <dest>

ADD： 类似于 COPY，但具有一些额外的功能，如自动解压缩 tar 文件和从 URL 复制文件。由于 ADD 具有更多功能，建议在不需要这些额外功能时使用 COPY。

ADD <src> <dest>

CMD 、RUN、ENTRYPOINT

RUN： 用于在构建时执行命令，通常用于安装软件包、更新系统等。每个 RUN 指令都会在新的镜像层中执行，并在构建期间对镜像进行修改。

RUN apt-get update && apt-get install -y nginx

CMD： 用于定义容器启动时执行的默认命令。它可以在 Dockerfile 中出现多次，但只有最后一次有效。如果用户在启动容器时提供了命令，则会覆盖 CMD。

CMD ["nginx", "-g", "daemon off;"]

ENTRYPOINT： 用于配置容器启动时执行的默认命令，并且这个命令不会被覆盖。如果用户在启动容器时提供了命令，则会被附加到 ENTRYPOINT 后面。ENTRYPOINT 经常与 CMD 结合使用，以提供默认参数。

ENTRYPOINT ["nginx", "-g", "daemon off;"]

四、k8s中pv回收策略的异同点

Retain：

特点： PV 的数据在释放后不会被删除，而是保留在存储中。管理员需要手动处理这些资源。
适用场景： 适用于需要手动处理 PV 数据回收的场景，例如希望保留数据以便进一步分析的情况。

Recycle：

特点： PV 的数据在释放后会被删除，但不同于 Delete 策略，它会尝试简单地清除数据，而不是进行安全擦除。
适用场景： 适用于不需要进行安全擦除、可以简单清除数据的场景。

Delete：

特点： PV 的数据在释放后会被删除，同时 Kubernetes 会尝试使用 Volume 插件进行安全擦除。
适用场景： 适用于需要安全擦除数据的场景，以确保数据不被不相关的用户访问。

异同点：

手动处理 vs. 自动处理：

Retain： 需要管理员手动处理 PV 中的数据，确保数据的安全存储或进一步使用。
Recycle 和 Delete： Kubernetes 会自动处理 PV 中的数据，但它们的处理方式不同。

数据处理方式：

Recycle： 简单地清除 PV 中的数据，不进行安全擦除。
Delete： 尝试使用 Volume 插件进行安全擦除，以确保数据不被不相关的用户访问。

数据安全性：

Retain 和 Delete： 提供更高水平的数据安全性，特别是在涉及敏感数据时。
Recycle： 提供较低水平的数据安全性，因为它不执行安全擦除。

适用场景：

Retain： 适用于需要手动处理数据的场景，如进一步分析或备份。
Recycle： 适用于不需要安全擦除、可以简单清除数据的场景。
Delete： 适用于需要安全擦除数据的场景，以确保数据不被不相关的用

五、k8s如何管控一个有状态集从开始创建到卷挂载绑定再到svc，最后到容器正常运行

在 Kubernetes 中，有状态服务集（StatefulSet）的创建和管理涉及多个组件的协同工作。以下是从创建开始到 StatefulSet 中的 Pod 正常运行的主要过程：

用户创建 StatefulSet 对象：

用户通过定义 StatefulSet 对象来描述有状态服务集的规模、模板和其他配置。StatefulSet 中包含有关每个 Pod 的模板以及 PVC 模板。
kube-apiserver 接收 StatefulSet 配置：

用户提交 StatefulSet 配置时，kube-apiserver 接收并验证配置信息，然后将其保存到 etcd 中。这将触发后续的控制器和调度过程。

kube-controller-manager 创建 StatefulSet 控制器：

kube-controller-manager 中包含 StatefulSet 控制器，该控制器监视 etcd 中的 StatefulSet 配置。
控制器检测到 StatefulSet 的创建后，根据规模信息开始创建 Pod。

kube-scheduler 调度 Pod：

kube-scheduler 负责将新创建的 Pod 分配到集群中的节点上。对于有状态服务，调度时需要考虑 Pod 的唯一性、亲和性和反亲和性规则。
每个 Pod 根据 StatefulSet 中定义的模板和 PVC 模板进行创建。

创建 PersistentVolumeClaim（PVC）：

StatefulSet 中的每个 Pod 都有一个对应的 PersistentVolumeClaim（PVC）。PVC 描述了 Pod 对存储的需求。PVC 根据模板创建，并绑定到可用的 PersistentVolume（PV）上。

Pod 启动及 Volume 挂载：

kubelet 接收到 Pod 的配置信息后，在节点上创建容器，并根据 PVC 中定义的 Volume 挂载到指定的路径。这使应用程序可以使用这个持久化存储。

创建 Headless Service：

StatefulSet 通常与 Headless Service 结合使用。这个服务的 Cluster IP 为 None，每个 Pod 都有唯一的 DNS 记录，例如 web-0.service-name.namespace.svc.cluster.local。
Headless Service 为有状态服务提供唯一的网络标识符，确保每个 Pod 具有独特的 DNS 记录。
Pod 正常运行：

控制器负责监控 StatefulSet 中的 Pod，并确保它们按照定义正常运行。每个 Pod 具有唯一的标识符和关联的 PVC 和 PV。
Pod 的唯一性、持久化存储和网络标识符等特性使有状态服务能够保持稳定和可靠的运行状态。
整个过程中，kube-apiserver 接收和存储配置信息，kube-controller-manager 创建和监控控制器，kube-scheduler 负责调度 Pod，kubelet 负责在节点上创建和监控容器。同时，Headless Service 提供唯一的网络标识符，PersistentVolume 和 PersistentVolumeClaim 提供持久化存储，确保有状态服务集的正确运行。