下午好，我想与大家分享我为 Windows 容器设置和使用 AWS EKS（Elastic Kubernetes Service）服务的经验，或者更确切地说，关于使用它的不可能性，以及在 AWS 系统容器中发现的错误。谁对 Windows 容器的这项服务感兴趣，请在 cat 下。
我知道 Windows 容器不是一个热门话题，很少有人使用它们，但我仍然决定写这篇文章，因为 Habré 有几篇关于 kubernetes 和 Windows 的文章，而且仍然有这样的人。
开始
这一切都是从决定将我们公司的服务迁移到kubernetes开始的，其中70%是Windows，30%是Linux。 为此，AWS EKS 云服务被认为是可能的选择之一。 直到8年2019月1.11日，AWS EKS Windows处于公共预览版，我开始使用它，那里使用旧的XNUMX版本的kubernetes，但我决定无论如何检查一下，看看这个云服务处于什么阶段，是否正常工作事实证明，不，在删除 Pod 的过程中存在一个错误，而旧的 Pod 则停止通过与 Windows 工作节点位于同一子网的内部 IP 进行响应。
因此，我们决定放弃使用 AWS EKS，转而在同一 EC2 上的 kubernetes 上使用我们自己的集群，只是我们必须通过 CloudFormation 自己描述所有平衡和 HA。
Amazon EKS Windows 容器支持现已全面推出
作者：马丁·比比 | 08 年 2019 月 XNUMX 日
在我有时间为自己的集群向 CloudFormation 添加模板之前，我看到了这条新闻
当然，我把所有的工作放在一边，开始研究他们为 GA 做了什么，以及公共预览版如何改变一切。 是的，AWS 做得很好，将 Windows 工作节点的镜像更新到了 1.14 版，并且 EKS 中的集群本身（1.14 版）现在支持 Windows 节点。 项目公开预览于 他们掩盖了它并说现在使用这里的官方文档：
将EKS集群集成到当前VPC和子网中
在所有来源中，在公告的上述链接以及文档中，建议通过专有的 eksctl 实用程序或通过 CloudFormation + kubectl 部署集群，仅使用 Amazon 中的公共子网，并创建一个为新集群提供单独的 VPC。
此选项并不适合很多人；首先，单独的 VPC 意味着其成本 + 当前 VPC 的对等流量会产生额外费用。 那些已经在 AWS 中拥有现成基础设施并拥有自己的多个 AWS 账户、VPC、子网、路由表、中转网关等的人应该做什么？ 当然，您不想破坏或重做这一切，您需要将新的 EKS 集群集成到当前的网络基础设施中，使用现有的 VPC，并且为了分离，最多为集群创建新的子网。
在我的例子中，选择了这条路径，我使用了现有的VPC，只为新集群添加了2个公共子网和2个私有子网，当然，根据文档考虑了所有规则 .
还有一个条件：公共子网中没有使用 EIP 的工作节点。
eksctl 与 CloudFormation
我会立即预约，我尝试了两种部署集群的方法，在这两种情况下，情况都是一样的。
我将展示一个仅使用 eksctl 的示例，因为这里的代码会更短。 使用eksctl，分3步部署集群：
1. 我们创建集群本身 + Linux 工作节点，稍后将托管系统容器和同样不幸的 vpc 控制器。
eksctl create cluster
--name yyy
--region www
--version 1.14
--vpc-private-subnets=subnet-xxxxx,subnet-xxxxx
--vpc-public-subnets=subnet-xxxxx,subnet-xxxxx
--asg-access
--nodegroup-name linux-workers
--node-type t3.small
--node-volume-size 20
--ssh-public-key wwwwwwww
--nodes 1
--nodes-min 1
--nodes-max 2
--node-ami auto
--node-private-networking为了部署到现有的 VPC，只需指定子网的 ID，eksctl 将确定 VPC 本身。
为了确保工作节点仅部署到私有子网，您需要为节点组指定 --node-private-networking。
2. 我们在集群中安装 vpc-controller，然后它将处理我们的工作节点，计算空闲 IP 地址的数量以及实例上 ENI 的数量，并添加和删除它们。
eksctl utils install-vpc-controllers --name yyy --approve3.系统容器在 Linux 工作节点（包括 vpc-controller）上成功启动后，剩下的就是使用 Windows 工作节点创建另一个节点组。
eksctl create nodegroup
--region www
--cluster yyy
--version 1.14
--name windows-workers
--node-type t3.small
--ssh-public-key wwwwwwwwww
--nodes 1
--nodes-min 1
--nodes-max 2
--node-ami-family WindowsServer2019CoreContainer
--node-ami ami-0573336fc96252d05
--node-private-networking当您的节点成功连接到集群并且一切似乎都正常后，它处于就绪状态，但事实并非如此。
vpc 控制器错误
如果我们尝试在 Windows 工作节点上运行 pod，我们将收到错误：
NetworkPlugin cni failed to teardown pod "windows-server-iis-7dcfc7c79b-4z4v7_default" network: failed to parse Kubernetes args: pod does not have label vpc.amazonaws.com/PrivateIPv4Address]如果我们深入观察，我们会发现 AWS 中的实例如下所示：
它应该是这样的：
由此可见，vpc-controller 由于某种原因没有履行其职责，无法向实例添加新的 IP 地址以便 Pod 可以使用它们。
让我们看一下 vpc-controller pod 的日志，我们看到的是：
kubectl 日志-n kube 系统
I1011 06:32:03.910140 1 watcher.go:178] Node watcher processing node ip-10-xxx.ap-xxx.compute.internal.
I1011 06:32:03.910162 1 manager.go:109] Node manager adding node ip-10-xxx.ap-xxx.compute.internal with instanceID i-088xxxxx.
I1011 06:32:03.915238 1 watcher.go:238] Node watcher processing update on node ip-10-xxx.ap-xxx.compute.internal.
E1011 06:32:08.200423 1 manager.go:126] Node manager failed to get resource vpc.amazonaws.com/CIDRBlock pool on node ip-10-xxx.ap-xxx.compute.internal: failed to find the route table for subnet subnet-0xxxx
E1011 06:32:08.201211 1 watcher.go:183] Node watcher failed to add node ip-10-xxx.ap-xxx.compute.internal: failed to find the route table for subnet subnet-0xxx
I1011 06:32:08.201229 1 watcher.go:259] Node watcher adding key ip-10-xxx.ap-xxx.compute.internal (0): failed to find the route table for subnet subnet-0xxxx
I1011 06:32:08.201302 1 manager.go:173] Node manager updating node ip-10-xxx.ap-xxx.compute.internal.
E1011 06:32:08.201313 1 watcher.go:242] Node watcher failed to update node ip-10-xxx.ap-xxx.compute.internal: node manager: failed to find node ip-10-xxx.ap-xxx.compute.internal.在谷歌上的搜索没有得到任何结果，因为显然还没有人发现这样的错误，或者还没有在上面发布问题，我必须首先自己考虑选项。 我首先想到的是，vpc-controller 可能无法解析 ip-10-xxx.ap-xxx.compute.internal 并访问它，因此会发生错误。
是的，确实，我们在 VPC 中使用自定义 DNS 服务器，原则上我们不使用 Amazon 的 DNS 服务器，因此甚至没有为此 ap-xxx.compute.internal 域配置转发。 我测试了这个选项，它没有带来结果，也许测试不干净，因此，进一步，在与技术支持沟通时，我屈服于他们的想法。
由于没有任何想法，所有安全组都是 eksctl 自己创建的，因此它们的可服务性毫无疑问，路由表也正确，nat、dns、工作节点的互联网访问也在那里。
此外，如果您在不使用 —node-private-networking 的情况下将工作节点部署到公共子网，则该节点会立即由 vpc-controller 更新，并且一切都像发条一样工作。
有两种选择：
- 放弃它，等到有人描述 AWS 中的这个错误并修复它，然后您就可以安全地使用 AWS EKS Windows，因为它们刚刚在 GA 中发布（在撰写本文时已经过去了 8 天），很多人可能会走和我一样的路。
- 写信给AWS Support，用来自各地的一大堆日志告诉他们问题的本质，并向他们证明他们的服务在使用你的VPC和子网时不起作用，我们有业务支持不是没有意义的，你应该使用至少一次:)
与AWS工程师沟通
在门户上创建票证后，我错误地选择通过网络 - 电子邮件或支持中心回复我，通过此选项，他们可以在几天后回复您，尽管我的票证严重程度 - 系统受损，这意味着在 12 小时内得到回复，并且由于业务支持计划有 24/7 支持，我希望得到最好的结果，但结果一如既往。
从周五到周一，我的票一直没有分配，然后我决定再次写信给他们并选择聊天回复选项。 等了一小会儿，哈沙德·马达夫被指定来见我，然后事情就开始了……
我们连续在线调试了3个小时，传输日志，在AWS实验室部署相同的集群来模拟问题，我自己重新创建集群等等，我们唯一得出的结果是日志很明显，resol 无法正常工作 AWS 内部域名（我在上面写过），Harshad Madhav 要求我创建转发，据称我们使用自定义 DNS，这可能是一个问题。
转发
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)事情就这样完成了，这一天结束了。哈沙德·马达夫回信检查了一下，应该可行，但是不，该决议根本没有帮助。
然后又和另外两个工程师进行了沟通，其中一个直接退出了聊天，显然他害怕复杂的情况，第二个又花了我一天的时间进行完整的调试，发送日志，在双方创建集群，在最后他只是说好，这对我有用，我在这里，我按照官方文档一步一步做所有事情，你和你都会成功。
如果您不知道在哪里寻找问题，我礼貌地请他离开并指派其他人来处理我的票。
压轴
第三天，我被分配了一位新工程师Arun B.，从一开始与他沟通就清楚这不是之前的三位工程师。 他阅读了整个历史记录，并立即要求在 ps3 上使用他自己的脚本收集日志，该脚本位于他的 github 上。 接下来又是创建集群、输出命令结果、收集日志的所有迭代，但从向我提出的问题来看，Arun B. 正在朝着正确的方向前进。
我们什么时候开始在他们的 vpc-controller 中启用 -stderrthreshold=debug ，接下来发生了什么？ 当然它不起作用）Pod 根本不使用此选项启动，只有 -stderrthreshold=info 起作用。
我们到这里就完成了，Arun B. 说他会尝试重现我的步骤以得到相同的错误。 第二天我收到了Arun B的回复，他并没有放弃这个case，而是拿起他们的vpc-controller的review代码，找到了它在哪里以及为什么不起作用：
因此，如果您在 VPC 中使用主路由表，那么默认情况下它不会与必要的子网关联，而这对于 vpc-controller 来说是非常必要的，在公共子网的情况下，它有一个自定义路由表有一个关联。
通过手动添加主路由表与必要子网的关联，并重新创建节点组，一切都可以完美运行。
我希望 Arun B. 能够真正向 EKS 开发人员报告此错误，我们将看到新版本的 vpc-controller，其中一切都可以开箱即用。 目前最新版本是：602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
有这个问题。
感谢所有读到最后的人，在实施之前测试您将在生产中使用的所有内容。
来源： habr.com