简介
在 Kubernetes 中管理卷权限对开发人员和系统管理员来说可能是一个挑战。当容器需要从持久卷读取或写入数据时，由于容器用户 ID 和卷所有权之间的不匹配，经常会出现权限问题。这些挑战可能导致应用程序故障和数据访问问题。
本实验（Lab）将指导你了解 Kubernetes 中常见的卷权限问题，并提供解决这些问题的实用方案。你将学习如何正确配置安全上下文（security contexts），使用初始化容器（init containers），以及在你的 Kubernetes 部署中实施卷权限管理的最佳实践。
了解 Kubernetes 卷
在这一步，我们将探索 Kubernetes 卷并了解它们的工作原理。Kubernetes 卷为容器提供了一种持久存储和访问数据的方式，即使容器被重启或重新调度也是如此。
Kubernetes 卷的类型
Kubernetes 支持几种卷类型：
- EmptyDir：一个简单的空目录，存在于 Pod 的生命周期内。
- HostPath：将主机节点文件系统中的文件或目录挂载到你的 Pod 中。
- PersistentVolume：由管理员配置的存储资源，其生命周期独立于任何 Pod。
- ConfigMap 和 Secret：提供了一种注入配置数据和敏感信息的方式。
创建你的第一个卷
让我们创建一个带有 EmptyDir 卷的简单 Pod：
- 为我们的 Pod 配置创建一个 YAML 文件：
cd ~/project/k8s-volume-demo
nano emptydir-pod.yaml
- 将以下内容复制到文件中：
apiVersion: v1
kind: Pod
metadata:
name: emptydir-pod
spec:
containers:
- name: container-1
image: ubuntu:22.04
command:
[
"/bin/bash",
"-c",
"while true; do echo $(date) >> /data/log.txt; sleep 10; done"
]
volumeMounts:
- name: data-volume
mountPath: /data
volumes:
- name: data-volume
emptyDir: {}
保存文件（按 Ctrl+X，然后按 Y，然后按 Enter）。
在你的 Kubernetes 集群中创建 Pod：
kubectl apply -f emptydir-pod.yaml
- 等待 Pod 准备就绪：
kubectl get pods
输出应该显示你的 Pod 处于运行状态：
NAME READY STATUS RESTARTS AGE
emptydir-pod 1/1 Running 0 30s
- 让我们检查一下我们卷的内容：
kubectl exec emptydir-pod -- cat /data/log.txt
你应该看到一个时间戳列表，表明我们的容器正在写入卷：
Mon Jan 1 12:34:56 UTC 2023
Mon Jan 1 12:35:06 UTC 2023
Mon Jan 1 12:35:16 UTC 2023
了解卷挂载
在上面的例子中：
- 我们定义了一个名为
data-volume的类型为emptyDir的卷 - 我们将此卷挂载到容器的路径
/data - 容器将时间戳写入此卷中的一个文件
这演示了 Kubernetes 卷的基本概念——它们提供了 Pod 中容器可以访问的存储。EmptyDir 卷存在于 Pod 的生命周期内，因此如果 Pod 被删除，数据将会丢失。
清理
让我们删除我们创建的 Pod：
kubectl delete pod emptydir-pod
在下一步中，我们将探讨在使用卷时如何出现权限问题以及如何识别它们。
识别卷权限问题
在这一步，我们将创建一个场景，演示 Kubernetes 中常见的卷权限问题。当使用 HostPath 卷或持久卷时，这些问题通常会发生，因为文件系统权限与容器中运行的用户 ID 不匹配。
了解问题
当容器以非 root 用户身份运行时，但尝试访问由 root（或其他用户）拥有的卷时，可能会发生权限被拒绝的错误。这在生产环境中是一个常见问题，在生产环境中，将容器作为非 root 用户运行是一种安全最佳实践。
创建具有权限问题的 HostPath 卷
让我们创建一个 Pod，它尝试访问具有 root 所有权的 HostPath 卷：
- 为我们的 Pod 配置创建一个 YAML 文件：
cd ~/project/k8s-volume-demo
nano hostpath-pod.yaml
- 将以下内容复制到文件中：
apiVersion: v1
kind: Pod
metadata:
name: hostpath-pod
spec:
containers:
- name: container-1
image: ubuntu:22.04
command:
[
"/bin/bash",
"-c",
"while true; do echo 'Trying to write' >> /data/output.txt; sleep 10; done"
]
volumeMounts:
- name: host-data
mountPath: /data
securityContext:
runAsUser: 1000 ## Run as non-root user
volumes:
- name: host-data
hostPath:
path: /home/labex/project/k8s-volume-demo/data
type: Directory
保存文件（按 Ctrl+X，然后按 Y，然后按 Enter）。
在你的 Kubernetes 集群中创建 Pod：
kubectl apply -f hostpath-pod.yaml
- 稍等片刻，然后检查 Pod 状态：
kubectl get pods
- 你应该看到 Pod 正在运行，但如果我们检查日志，可能会看到错误：
kubectl logs hostpath-pod
你可能会看到类似以下的权限被拒绝错误：
bash: /data/output.txt: Permission denied
- 让我们通过检查主机目录上的权限来确认问题：
ls -la ~/project/k8s-volume-demo/data
你应该看到类似以下的输出：
total 12
drwxr-xr-x 2 root root 4096 Jan 1 12:00 .
drwxr-xr-x 3 labex labex 4096 Jan 1 12:00 ..
-rw-r--r-- 1 root root 19 Jan 1 12:00 test.txt
目录和文件由 root 拥有，但我们的容器以用户 ID 1000 运行。这种不匹配会导致权限被拒绝的错误。
了解容器中的用户和组 ID
在 Kubernetes 中，容器可以通过 securityContext 配置以特定的用户 ID 运行。在我们的例子中：
securityContext:
runAsUser: 1000 ## Run as non-root user
这告诉 Kubernetes 将容器进程作为用户 ID 1000 运行，该用户没有写入 root 拥有的文件的权限。
清理
在我们进入下一步之前，让我们删除 Pod：
kubectl delete pod hostpath-pod
在下一步中，我们将探讨这些权限问题的解决方案。
使用 Security Context 修复权限问题
在这一步，我们将探讨如何使用 Kubernetes SecurityContext 来解决卷权限问题。SecurityContext 定义了 Pod 和容器的特权和访问控制设置。
使用 fsGroup 修复权限
SecurityContext 中的 fsGroup 设置可以帮助解决权限问题。指定后，Kubernetes 会将卷的组所有权更改为与指定的组 ID 匹配，并设置权限，以便该组可以读取和写入卷。
让我们创建一个具有正确安全上下文的 Pod：
- 为我们的 Pod 配置创建一个 YAML 文件：
cd ~/project/k8s-volume-demo
nano fixed-pod.yaml
- 将以下内容复制到文件中：
apiVersion: v1
kind: Pod
metadata:
name: fixed-pod
spec:
securityContext:
fsGroup: 2000 ## Set group ID for all containers in the pod
containers:
- name: container-1
image: ubuntu:22.04
command:
[
"/bin/bash",
"-c",
"while true; do echo $(date) >> /data/output.txt; cat /data/test.txt; sleep 10; done"
]
volumeMounts:
- name: host-data
mountPath: /data
securityContext:
runAsUser: 1000 ## Run as non-root user
volumes:
- name: host-data
hostPath:
path: /home/labex/project/k8s-volume-demo/data
type: Directory
保存文件（按 Ctrl+X，然后按 Y，然后按 Enter）。
在你的 Kubernetes 集群中创建 Pod：
kubectl apply -f fixed-pod.yaml
- 等待 Pod 准备就绪：
kubectl get pods
- 现在，让我们检查日志以查看我们的权限问题是否已解决：
kubectl logs fixed-pod
你应该看到时间戳被成功写入，表明容器现在可以写入卷：
This is a test file
Mon Jan 1 12:45:06 UTC 2023
This is a test file
Mon Jan 1 12:45:16 UTC 2023
- 让我们检查一下卷权限发生了什么变化：
## Get into the container
kubectl exec -it fixed-pod -- bash
## Inside the container, check the permissions
ls -la /data
## Exit the container
exit
你应该看到卷中的文件现在可以被容器访问，因为 Kubernetes 应用了 fsGroup 设置。
了解 Security Context 设置
- runAsUser：指定容器进程将作为其运行的用户 ID。
- fsGroup：控制用于卷访问的组 ID。Pod 中的所有进程都将成为此补充组的一部分。
- runAsGroup：指定容器内所有进程的主组 ID（可选）。
这些设置有助于确保你的容器可以正确访问卷数据，同时保持不以 root 身份运行的安全最佳实践。
清理
让我们删除我们创建的 Pod：
kubectl delete pod fixed-pod
在下一步中，我们将探讨使用 init 容器修复权限问题的另一种方法。
使用 Init 容器修复权限
在某些情况下，使用 fsGroup 可能不够用或不可行。例如，当使用某些卷类型或在较旧版本的 Kubernetes 上运行时。在这些情况下，可以使用 init 容器在主容器启动之前设置正确的权限。
什么是 Init 容器？
Init 容器在 Pod 中的主容器之前运行。它们可以执行初始化任务，例如设置权限、下载内容或等待依赖项。Init 容器对于权限管理特别有用，因为它们可以以提升的权限运行，以更改卷文件的所有权和权限。
创建一个带有 Init 容器的 Pod
让我们创建一个使用 init 容器来修复权限的 Pod：
- 为我们的 Pod 配置创建一个 YAML 文件：
cd ~/project/k8s-volume-demo
nano init-pod.yaml
- 将以下内容复制到文件中：
apiVersion: v1
kind: Pod
metadata:
name: init-pod
spec:
initContainers:
- name: permission-fixer
image: ubuntu:22.04
command:
["/bin/bash", "-c", "chown -R 1000:1000 /data && chmod -R 755 /data"]
volumeMounts:
- name: host-data
mountPath: /data
securityContext:
runAsUser: 0 ## Run as root to change permissions
containers:
- name: main-container
image: ubuntu:22.04
command:
[
"/bin/bash",
"-c",
"while true; do echo $(date) >> /data/init-output.txt; cat /data/test.txt; sleep 10; done"
]
volumeMounts:
- name: host-data
mountPath: /data
securityContext:
runAsUser: 1000 ## Run as non-root user
volumes:
- name: host-data
hostPath:
path: /home/labex/project/k8s-volume-demo/data
type: Directory
保存文件（按 Ctrl+X，然后按 Y，然后按 Enter）。
在你的 Kubernetes 集群中创建 Pod：
kubectl apply -f init-pod.yaml
- 等待 Pod 准备就绪。Pod 将保持在 "Init" 状态，直到 init 容器完成：
kubectl get pods
- 一旦 Pod 处于运行状态，检查主容器的日志：
kubectl logs init-pod
你应该看到时间戳被成功写入，表明容器现在可以写入卷：
This is a test file
Mon Jan 1 13:05:06 UTC 2023
This is a test file
Mon Jan 1 13:05:16 UTC 2023
- 让我们检查一下卷权限发生了什么变化：
## Check the content of the data directory
ls -la ~/project/k8s-volume-demo/data
你将注意到文件所有权已更改，以反映 init 容器命令中指定的用户 ID。
了解 Init 容器方法
在此示例中：
- init 容器以 root 权限运行 (
runAsUser: 0) - 它更改卷内容的所有权和权限
- 在 init 容器完成后，主容器启动
- 主容器以非 root 用户身份运行 (
runAsUser: 1000) - 主容器现在可以读取和写入卷
此技术特别有用，当：
- 你需要使用特定的所有权模式准备卷
- 你正在使用不支持
fsGroup的卷 - 你需要执行复杂的权限设置逻辑
清理
让我们删除我们创建的 Pod：
kubectl delete pod init-pod
在下一步中，我们将探讨最佳实践，并学习如何结合这些方法来实现强大的卷权限管理。
最佳实践和组合方法
在实际场景中，你可能需要结合多种方法来有效地处理卷权限。在最后一步中，我们将探讨最佳实践，并创建一个实现稳健解决方案的综合示例。
卷权限最佳实践
以下是在 Kubernetes 中管理卷权限的一些关键最佳实践：
- 尽可能以非 root 用户身份运行容器
- 使用应用程序运行所需的最低权限用户
- 在 Pod 和容器级别利用安全上下文
- 在你的组织中标准化 UID/GID 值
- 将 init 容器用于复杂的设置 场景
- 为权限问题实现适当的错误处理
创建一个综合解决方案
让我们创建一个将我们的学习内容结合成一个稳健解决方案的部署：
- 为我们的部署创建一个 YAML 文件：
cd ~/project/k8s-volume-demo
nano best-practice-deployment.yaml
- 将以下内容复制到文件中：
apiVersion: apps/v1
kind: Deployment
metadata:
name: volume-best-practices
labels:
app: volume-demo
spec:
replicas: 1
selector:
matchLabels:
app: volume-demo
template:
metadata:
labels:
app: volume-demo
spec:
## Pod-level security context
securityContext:
fsGroup: 2000
## Init container for advanced preparation
initContainers:
- name: volume-permissions
image: ubuntu:22.04
command:
- /bin/bash
- -c
- |
## Create directory structure if it doesn't exist
mkdir -p /data/app /data/logs /data/config
## Set appropriate permissions
chmod 755 /data
chmod 775 /data/app /data/logs
chmod 755 /data/config
## Set ownership (belt and suspenders approach)
chown -R 1000:2000 /data
echo "Volume prepared successfully"
volumeMounts:
- name: data-volume
mountPath: /data
securityContext:
runAsUser: 0 ## Run as root for setup
## Application containers
containers:
- name: app-container
image: ubuntu:22.04
command:
- /bin/bash
- -c
- |
echo "Starting application with user $(id)"
while true; do
echo "$(date) - Application running" >> /data/logs/app.log
echo "Writing to app directory" >> /data/app/status.txt
echo "Reading from config"
cat /data/config/test.txt || echo "No config found"
sleep 10
done
volumeMounts:
- name: data-volume
mountPath: /data
securityContext:
runAsUser: 1000 ## Run as non-root user
runAsGroup: 2000 ## Use the same group as fsGroup
allowPrivilegeEscalation: false ## Prevent privilege escalation
volumes:
- name: data-volume
hostPath:
path: /home/labex/project/k8s-volume-demo/data
type: Directory
保存文件（按 Ctrl+X，然后按 Y，然后按 Enter）。
在你的 Kubernetes 集群中创建部署：
kubectl apply -f best-practice-deployment.yaml
- 等待部署准备就绪：
kubectl get pods -l app=volume-demo
- 让我们检查 init 容器的日志：
## Get the pod name
POD_NAME=$(kubectl get pods -l app=volume-demo -o jsonpath='{.items[0].metadata.name}')
## Check the init container logs
kubectl logs $POD_NAME -c volume-permissions
你应该看到一条消息，表明卷已成功准备好。
- 现在，检查应用程序容器的日志：
kubectl logs $POD_NAME -c app-container
你应该看到应用程序正在运行，并且能够读取和写入卷。
- 让我们检查一下我们的部署创建的文件：
ls -la ~/project/k8s-volume-demo/data
你应该看到 init 容器创建的目录结构，具有适当的权限和所有权。
了解综合解决方案
此解决方案结合了多种最佳实践：
- Pod 级别安全上下文，使用
fsGroup设置基本权限 - Init 容器 用于复杂的目录结构设置
- 容器级别安全上下文 以非 root 身份运行
fsGroup和runAsGroup之间的适当组对齐- 使用
allowPrivilegeEscalation: false增强安全性
这种方法确保：
- 应用程序具有运行所需的功能权限
- 遵循最小权限原则
- 该解决方案在不同的环境中是稳健的
清理
让我们清理在本次实验中创建的所有资源：
kubectl delete deployment volume-best-practices
rm -rf ~/project/k8s-volume-demo/data/app ~/project/k8s-volume-demo/data/logs ~/project/k8s-volume-demo/data/config
你现在已经学习了多种解决 Kubernetes 中卷权限问题的方法，并实现了一个遵循最佳实践的综合解决方案。
总结
在本实验中，你已经学习了如何通过几种方法来识别和解决 Kubernetes 卷权限问题：
- 首先，你了解了 Kubernetes 卷的工作原理，并创建了一个简单的 EmptyDir 卷示例。
- 然后，你通过创建一个具有不匹配用户权限的 HostPath 卷，识别了常见的卷权限问题。
- 你使用 Kubernetes
SecurityContext和fsGroup实现了解决方案，以设置适当的卷权限。 - 你探索了一种替代方法，使用 init 容器在主容器启动之前显式设置权限。
- 最后，你将这些技术结合成一个全面的最佳实践解决方案，该方案提供了一种在 Kubernetes 中管理卷权限的稳健方法。
这些技能将帮助你确保你的容器化应用程序可以正确访问持久存储，同时保持安全最佳实践。通过应用安全上下文、init 容器和权限管理技术的正确组合，你可以避免 Kubernetes 部署中常见的权限问题。
