在 Kubernetes 中运行 pod 定义文件时出错答案

【问题标题】：error while running pod defination file in kubernetes在 Kubernetes 中运行 pod 定义文件时出错
【发布时间】：2020-02-08 02:12:41
【问题描述】：

创建“pod-defination.yml”时出错：

pods "myapp" 被禁止：pod 没有 “kubernetes.io/config.mirror”注解，节点 "ip-172-31-38-73.us-east-2.compute.internal" 只能创建镜像豆荚

apiVersion: v1  

kind: Pod 

metadata:
   labels:
     app: myapp
spec:
   containers:
      - name: nginx-container
      - image: nginx

【问题讨论】：

标签： amazon-web-services docker kubernetes amazon-ecs amazon-eks

【解决方案1】：

请在下面尝试，因为图像元素不是数组

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: nginx-container
    image: nginx

【讨论】：

【解决方案2】：

所以，这里有 3 个问题。不幸的是，这是部分答案。

1) @Dinesh 的图片绝对正确。

   containers:
      - name: nginx-container
      - image: nginx

通过您的配置，它会尝试使用 2 张图片 - nginx-container 和 nginx。而不是这个你只需要nginx 名称：nginx-container

正确的是

spec:
  containers:
  - name: nginx-container
    image: nginx

2) 您应该始终在元数据中设置name: - 这是必填字段。不指定 .metadata.name 你会得到resource name may not be empty

Object: &{map["apiVersion":"v1" "kind":"Pod" "metadata":map["annotations":map["kubectl.kubernetes.io/last-applied-configuration":""] "labels":map["app":"myapp"] "namespace":"default"] "spec":map["containers":[map["image":"nginx" "name":"nginx-container"]]]]}
from server for: "pod-defination.yml": resource name may not be empty

根据Understanding Kubernetes Objects

在您要创建的 Kubernetes 对象的 .yaml 文件中，您将需要为以下字段设置值：

apiVersion - 您使用哪个版本的 Kubernetes API 创建此对象

kind - 你想创建什么样的对象

元数据 - 有助于唯一标识对象的数据，包括名称字符串、UID 和可选命名空间

规范 - 您希望对象处于何种状态

同样根据metadata API Conventions

每个对象类型都必须在嵌套对象中具有以下元数据名为“元数据”的字段：

命名空间：命名空间是一个与 DNS 兼容的标签，对象被细分为。默认命名空间是“默认”。查看命名空间了解更多信息。

name：在当前命名空间中唯一标识此对象的字符串（请参阅标识符文档）。该值用于检索单个对象时的路径。

uid：时间和空间上的唯一值（通常是 RFC 4122 生成的标识符，请参阅标识符文档），用于区分在已删除的同名对象之间重新创建

3)pod 没有“kubernetes.io/config.mirror”注解

pods "blabla" 被禁止：pod 没有 “kubernetes.io/config.mirror”注解，节点“blablabla”只能创建镜像 pod

当您遇到 [NodeRestriction admission plugin]{https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction}

问题时，通常会出现上述错误

准入控制器是一段拦截请求的代码对象持久化之前的 Kubernetes API 服务器，但是请求经过身份验证和授权后。 […] 录取控制器可能是“验证”、“变异”或两者兼而有之。变异控制器可以修改他们承认的对象；验证控制器不得。 […] 如果任一阶段的任何控制器拒绝请求，整个请求立即被拒绝，并出现错误返回给最终用户。

NodeRestriction 准入控制器：

这个准入控制器将 Node 和 Pod 对象限制为 kubelet 可以修改。为了受这个准入控制器的限制， kubelets 必须使用 system:nodes 组中的凭证，并带有形式为 system:node: 的用户名。这样的 kubelet 只会允许修改自己的 Node API 对象，并且只修改 Pod 绑定到其节点的 API 对象。在 Kubernetes 1.11+ 中，不允许 kubelet 从其节点更新或删除污点 API 对象。

根据EKS kubernetes platform versions，我们可以看到NodeRestriction 是启用准入控制器的一部分。

命名空间生命周期、LimitRanger、ServiceAccount、DefaultStorageClass、 ResourceQuota、DefaultTolerationSeconds、NodeRestriction、 MutatingAdmissionWebhook、ValidatingAdmissionWebhook、PodSecurityPolicy

3 个月前已经有same question，但没有任何回复。

由于 EKS 由 AWS 控制平面管理 - 似乎无法修改内置准入控制器，但您可以查看动态准入控制器和准入 Webhook。更多信息可以在Dynamic Admission Control找到。

根据Amazon EKS Enables Support for Kubernetes Dynamic Admission Controllers - EKS 支持动态准入控制器，允许客户部署自定义 Webhook，从而启用其他开源工具来控制网络流量和监控 AWS 上的 Kubernetes 集群。

我建议您使用 kops 手动创建集群，并提供您需要的所有选项。

希望对你有帮助

【讨论】：