如何在Google Cloud Kubernetes节点操作系统镜像上默认启用内核模块

35次阅读

问题描述

在使用Google Cloud Kubernetes节点操作系统镜像时遇到了问题。问题是节点上的一个Pod是NFS服务器，但节点在启动时没有启用nfs和nfsd内核模块。因此，每当节点重新启动时，用户需要通过SSH登录并运行以下命令来启用所需的内核模块：

sudo modprobe nfs
sudo modprobe nfsd

用户想知道如何在节点重新启动时默认启用这些内核模块。

解决方案

请注意以下操作注意版本差异及修改前做好备份。

方案1

为了在节点重新启动时默认启用内核模块，可以创建一个initContainers块，允许在Pod的主容器启动之前运行任何容器。
由于我们实际上是在主机操作系统上运行命令，所以需要在initContainers容器中以privileged模式运行（可能需要添加额外的特权参数）。
此外，我们还需要将主机操作系统的/lib/modules目录挂载到容器中，以便modprobe命令可以修改主机的内核模块。
在尝试过程中，initContainers的busybox容器可能会失败，可以使用以下命令查看其失败输出：

kubectl logs --container='load-nfs' [YOUR_POD_FULL_NAME_HERE]

以下是一个可行的示例YAML文件：

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: ch1
  name: deployment-test
  namespace: default
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: test
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: test
    spec:
      containers:
        - image: strm/helloworld-http
          imagePullPolicy: Always
          name: test
          ports:
            - containerPort: 3000
              protocol: TCP
          resources:
            limits:
              cpu: "1"
              memory: 1Gi
            requests:
              cpu: 200m
              memory: 256Mi
      initContainers:
        - name: load-nfs
          image: busybox
          command: ["sh", "-c", "modprobe nfs && modprobe nfsd"]
          volumeMounts:
            - mountPath: /lib/modules
              name: host-modules
          securityContext:
            runAsUser: 0
            privileged: true
            allowPrivilegeEscalation: true
            capabilities:
              add:
                - SYS_ADMIN
      volumes:
        - name: host-modules
          hostPath:
            path: /lib/modules
            type: Directory

在上面的示例中，我们创建了一个名为load-nfs的initContainers容器，使用busybox镜像，并运行modprobe nfs && modprobe nfsd命令。我们还将主机操作系统的/lib/modules目录挂载到容器中。
请注意，runAsUser应该是0（root用户），因为使用用户1000会导致权限问题。

方案2

使用脚本或工具来管理容器的启动顺序可能会增加复杂性，并且需要确保容器A和容器B之间的依赖关系正确设置。
另一种方法是编写脚本或使用工具来控制容器的运行顺序。你可以使用docker run命令来手动控制容器的启动顺序，或者使用一些第三方工具来管理容器的依赖关系。

示例：

以下是一个简单的bash脚本示例，可以在容器A启动后启动容器B：

#!/bin/bash
# 启动容器A
docker run -d --name container_a your_image_a
# 等待容器A完全启动
while ! docker exec container_a echo "Container A is ready"; do
  sleep 1
done
# 启动容器B
docker run -d --name container_b your_image_b

在这个示例中，我们首先使用docker run命令启动容器A，并将其命名为container_a。然后，使用一个循环来等待容器A完全启动（这里是通过在容器内运行echo命令来测试）。一旦容器A就绪，我们再使用docker run命令启动容器B，并将其命名为container_b。

正文完