4 创建 EKS 平台
4.1 创建 EKS 集群
Amazon EKS 是 AWS 上托管的 K8S 容器管理平台，关于 EKS 这里不做过多描述了，具体的可以参考 AWS 的官方文档： https://docs.aws.amazon.com/zh_cn/eks/latest/userguide/what-is-eks.html
这里我们采用 CDK 来创建 EKS 集群，具体的代码和解释如下：
里面的参数都可以按照需要修改，在添加 node 节点时也可以选择添加 spot instance。
4.2 向 EKS 的 node group 授予 policy
有些情况下，我们要向 EKS 的节点授予一定权限，比如我们需要 node 上的应用从 System Manager 的 parameter store 中取信息，那我们需要向 node group 授予 SSM 的 policy，通过以下代码实现：
通常在用 CDK 创建 EKS 集群时会默认创建一个 AutoScalingGroup，然后在 add capacity 的时候会创建第二个 AutoSacalingGroup，所以在授予 policy 时需要向两个 ASG 中的 node 都授予。代码里也有两个部分。在我们的应用中我们设置了 default capacity 为 0，所以禁止了创建默认 ASG 的行为，就只有一个 ASG，不需要向默认创建的 ASG 授予 policy。这时候如果执行第一部分代码会报错，所以前面两行代码注释掉了。在实际使用中要注意这两者的差别，两个 ASG 需要分别控制和管理。
所有 Policy 都可以采用这种方式授予 node group，包括 AWS 托管的 Policy 和自定义的 policy。
4.3 创建 K8S 资源
通过以上步骤我们创建了一个具有 control plan 控制平面、node group 和 ASG 的 Amazon EKS 集群，除了自身的 coredns 外不具有其他的 Kubernetes 资源。但是我们知道 K8S 中有很多 Kubernetes 资源包括 deployment、services、RBAC、ingress 等是典型云原生应用运行必不可少的部分。由于这类资源对 CloudfFormation 来说并不属于 AWS 托管的服务，无法投过 CDK 提供的 L2 construct library 直接部署，因此在 AWS CDK 中会透过 @aws-cdk/aws-cloudformation 的 CustomerResource Class 来实现，也就是 @aws-cdk/aws-eks 里面的 KubernetesResource Class，而它背后是通过 AWS Lambda 调度 lambda-layer-kubectl Lambda Layer 来运行 kubectl 客户端创建出 K8S 资源，详细可以参考 @aws-cdk/aws-ek/lib/k8s-resource.ts ).
但是 CDK 中现在还不支持以 YAML 文件定义的资源，而只能添加一组 JSON Array。因此我单独实现了一个小工具用来将 YAML 文件转换为需要的 JSON Array。
现在，我们可以将转换好的 JSON Array 提供给 cluster 作为资源。比如说，在以下的示例代码中为该 EKS 集群增加了 RBAC 和 Ingress controller 资源：
在应用运行的时候，这些资源会重新组装成为 manifest.yaml，通过 kubectl 的方式在该 EKS 平台上运行，创建出需要的 K8S 资源。
所有需要的资源都可以采用这种方式添加到 cluster 中。
4.4 定义 EKSStack 的入口
我们在 app.py 中定义 EKS Stack 的执行入口
这里我们还用 dependency 表示 EKS 依赖于 Landingzone，也就是先要创建 AWS 上基础的网络架构，在创建 EKS 平台。
4.5 查看 Stack
现在我们在命令行中运行 ls，可以看到两个 Stack，他们之间是有相互依赖关系的。
同样我们也可以通过 cdk synth 查看生成的 CloudFormation 模板。
5. 运行 Stack
我们通过 cdk deploy 依次运行 Landingzone Stack 和 EKS Stack，分别创建基础网络和 EKS 平台。当然我们也可以直接运行 EKS stack，因为它对 Landingzone stack 有依赖，所以 cdk 会先检查 Landingzone 是否创建了，如果没有的话会先创建 Landingzone。
可以看到，对于一些 IAM 和安全组相关的资源创建 / 删除 / 更改，CDK 会提示要求确认。其他资源则不会有提示。在选择了“y”之后，就会创建 cloudformation changeset，然后通过 cloudformation 创建资源，同时在 console 上输出 Cloudformation 的运行过程。
这时我们也可以在 AWS console 中的 Cloudformation 查看运行状态。
创建过程中，如果我们把 CDK 运行的命令行窗口关掉也不要紧，Cloudformation 仍然会继续执行。
执行好后，我们在命令行和 console 里都可以看到运行结果。
我们也可以采用同样的方式创建 EKS Stack。可以在 AWS console 中查看创建的结果：
可以看到有两个 stack，其中一个带有 nested 字样的是嵌套 stack，是用来运行 kubectl 客户端的 lambda layer。
我们再在 EKS 的界面看一下：
现在我们就可以登入 EKS 里玩一下啦！~
总结
这篇文章是我们云原生专栏的开篇。在这篇文章里，我们了解了如何采用 CDK 轻松快速地在一个全新的 AWS 账号下构建基础网络架构，并在其上构建 EKS 平台及需要的 K8S 资源。
AWS CDK 对底层 CloudFormation 进行了更高级别抽象，针对一些常用的架构设计方式，比如每个 AZ 中几个子网、子网的类型、安全组设置、IAM 权限设置等提供了高级别的方法，可以更加方便和高效地创建 AWS 资源，而且多语言支持简单易上手。
但是 CDK 的 L2 construct 在对 CloudFormation 资源封装的同时也缺失了一些底层属性，所以可以满足大部分使用场景但不能满足所有。如果有需要的属性缺失的话，可以基于 L1 construct 实现，也可以在 github 上提交 Issue 或者自己提交 PR 修改 L2。AWS CDK 是一个非常活跃的开源项目，更新很快，也欢迎大家贡献维护。
感谢
感谢解决方案架构师专家 Pahud Hsieh (謝洪恩)、解决方案架构师经理薛军和安全顾问 Kelvin Medina 对本文章提出的宝贵意见。
下一篇介绍
下一篇中，我们会了解如何采用 CDK 构建应用所需要的日志收集和展示系统，
评论