supplementalGroups: [ 65534 ] 的含义？

Question

我正在看这个 yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kube-dns-autoscaler
  namespace: kube-system
  labels:
    k8s-app: kube-dns-autoscaler
    kubernetes.io/cluster-service: "true"
spec:
  selector:
    matchLabels:
      k8s-app: kube-dns-autoscaler
  template:
    metadata:
      labels:
        k8s-app: kube-dns-autoscaler
    spec:
      priorityClassName: system-cluster-critical
      securityContext:
        seccompProfile:
          type: RuntimeDefault
        supplementalGroups: [ 65534 ]
        fsGroup: 65534
      nodeSelector:
        kubernetes.io/os: linux
      containers:
      - name: autoscaler
        image: k8s.gcr.io/cpa/cluster-proportional-autoscaler:1.8.4
        resources:
            requests:
                cpu: "20m"
                memory: "10Mi"
        command:
          - /cluster-proportional-autoscaler
          - --namespace=kube-system
          - --configmap=kube-dns-autoscaler
          # Should keep target in sync with cluster/addons/dns/kube-dns.yaml.base
          - --target=<SCALE_TARGET>
          # When cluster is using large nodes(with more cores), "coresPerReplica" should dominate.
          # If using small nodes, "nodesPerReplica" should dominate.
          - --default-params={"linear":{"coresPerReplica":256,"nodesPerReplica":16,"preventSinglePointFailure":true,"includeUnschedulableNodes":true}}
          - --logtostderr=true
          - --v=2

来源：https://kubernetes.io/docs/tasks/administer-cluster/dns-horizo​​ntal-autoscaling/#enablng-dns-horizo​​ntal-autoscaling

在哪里可以找到这些神奇数字的文档？

        supplementalGroups: [ 65534 ]
        fsGroup: 65534

Answer 1

在哪里可以找到这些神奇数字的文档？

它来自 systemd 系统上的用户、组、UID 和 GID。在这里，您可以使用不同的参数，还可以查看有关systemsUID/GID。

特殊的 Linux UID 理论上，C 类型的范围 uid_t 在 Linux 上是 32 位宽，即 0…4294967295。然而，Linux 上有四个 UID 比较特殊：

1. 0 → root 超级用户

2. 65534 → nobody UID，也称为“溢出”UID 或类似名称。它是各种子系统将不可映射的用户映射到的位置，例如仅支持 16 位 UID、NFS 或用户命名空间的文件系统。（后者可以在运行时使用 sysctl 进行更改，但不支持 systemd。如果您更改它，您的保修将失效。）因为 Fedora 有点混乱，所以 nobody 用户在那里被调用 nfsnobody （并且他们 nobody 在 UID 99 处有一个不同的用户）。我希望最终会纠正这个问题。（此外，一些发行版将该 nobody 组 称为nogroup。我希望他们不要这样做。）

3. 4294967295，又名“32 位 (uid_t) -1” → 此 UID 不是有效的用户 ID，因为 setresuid()和 chown() 朋友将 -1 视为不更改进程/文件的 UID 的特殊请求。因此，此 UID 无法分配给用户数据库中的用户。

4. 65535，又称“16 位 (uid_t) -1” → 在 Linux 内核 2.4 之前 uid_t 是 16 位的，因此为其编译的程序会假定它 (uid_t) -1 是 65535。因此这个 UID 也不可用。

好吧，我们在 Kubernetes 中拥有参数，让我们来描述一下它是什么：

补充组 - 控制容器添加哪些组 ID。

• 必须运行 - 至少需要 range 指定一个。使用第一个范围的最小值作为默认值。针对所有范围进行验证。
• 五月 - 至少需要 range 指定一个。允许 supplementalGroups 不设置而不提供默认值。如果 supplementalGroups 设置，则针对所有范围进行验证。
• 以任意方式运行 - 没有提供默认值。允许任意 supplementalGroups 指定。

FS集团 - 控制应用于某些卷的补充组。

• 必须运行 - 至少需要 range 指定一个。使用第一个范围的最小值作为默认值。针对所有范围进行验证。
• 五月 - 至少需要 range 指定一个。允许 FSGroups 不设置而不提供默认值。如果 FSGroups 设置，则针对所有范围进行验证。
• 以任意方式运行 - 未提供默认值。允许 fsGroup 指定任何 ID。