OpenSource | 使用 AWS Service Broker 通过 Kubernetes 配置 AWS 服务

毋庸置疑，容器已经改变了我们构建项目的方式。容器化工作流程方法的指导原则之一是将控制权交还给开发人员，让他们能够选择自己的依赖项以及使用依赖项的方式 – 最重要的是，他们需要依赖项的时间。如今，恐怕没人可以等待运营团队三周时间，让他们去预配置一个数据库。

因此，社区需要拿出一种方法来确保无论您的容器在何处运行，您都能始终以简单、可预测的方式来控制您的外部依赖项。解决方案：Open Service Broker (OSB) API。今天，我将向您介绍 AWS Service Broker，它是一款 OSB API 工具，允许您通过任何支持 OSB API 的平台直接预配置 RDS 和 EMR 等 AWS 服务。目前这些平台包括 Kubernetes、OpenShift 和 Cloud Foundry。我们在 re:Invent 2017 大会上发布了 AWS Service Broker 及其最初支持的 10 项服务。今年 4 月我们又增加了 8 项服务，并且我们会继续以正常节奏增加对更多 AWS 服务的支持。Kubernetes 中服务代理方法背后的架构非常简单。Kubernetes 的 Service Catalog 项目将允许兼容 OSB 的服务代理向目录注册可用服务列表。平台中具有正确权限的任何用户都可以针对任何可用服务计划向 Service Catalog 提出请求。代理将预配置服务并将返回的信息与一组 secret 绑定。

AWS Service Broker

我一直认为解释某种东西的最好方式就是展示它的工作原理。所以，让我们直接开始吧，这样您可以亲自尝试。

您需要的工具

为了跟随此博文进行操作，您需要做一些准备。我不会介绍这些依赖项的安装或部署，但是我们在线提供了可用资源的完整列表，以帮助您自行完成这些操作。

具有创建 IAM 权限的 AWS 账户
kops 集群 (Kubernetes v1.9.3)
Helm v2.9.0-rc5
AWS CLI v1.15.11
Python 2.7.13+

安装 Kubernetes Service Catalog

Kubernetes Service Catalog 是用于将所有服务通告给 Kubernetes 平台的机制。在管理 AWS 服务时，Service Catalog 与 AWS Service Broker 进行通信。安装 Service Catalog 的方法有很多，我个人认为使用 Helm 是最简单的。Service Catalog 有一个名为 svcat 的 CLI，可以使安装过程变得更加轻松。

下载 svcat CLI

这一步将下载适用于 Linux 的 svcat CLI，但对于每种主流操作系统，它都有适用的版本。要了解完整的安装说明，请参阅此处的文档。如果您使用 Linux，可以运行以下命令：

curl -sLo svcat https://download.svcat.sh/cli/latest/linux/amd64/svcat
chmod +x svcat
sudo mv svcat /usr/local/bin
svcat install plugin

svcat CLI install

将 Service Catalog 图表存储库添加到 Helm 并安装 Service Catalog

helm repo add svc-cat https://svc-catalog-charts.storage.googleapis.com
helm install svc-cat/catalog --name catalog --namespace catalog

要检查是否已成功安装，您可以列出启动至 catalog 命名空间的 pod：

kubectl get pods --namespace=catalog

权限

现在您已经部署了 Kubernetes Service Catalog，您需要确保 AWS Service Broker 具有正确的权限，以在您的 AWS 账户中启动 AWS 服务。AWS Service Broker 可以通过以下两种方式之一获取权限：

静态配置配置文件中的凭证（适用于本地部署）
使用 AWS SDK Credential Provider Chain（在 AWS 上部署时的最佳实践）

AWS Service Broker 使用 CloudFormation 来管理在您的 AWS 账户中创建的所有资源的生命周期，因此我们需要创建 CloudFormation 在创建服务时所承担的角色。

下载您将在本演练中使用的模板和定义

curl -kLO https://s3.amazonaws.com/awsservicebroker/assets/blog-templates.tar.gz
mkdir blogtemplates
tar -xvf blog-templates.tar.gz -C blogtemplates
cd blogtemplates

aws iam create-policy --policy-name "aws-service-broker-cfn-deploy-policy" \
--policy-document file://cfn-deployment-policy.json

create_cfn_policy

记下 ARN 的值；在我稍后提及以下内容的步骤中会用到： ${CFN_POLICY_ARN}

创建新角色并附加策略

在此部分中，我们将创建 CloudFormation 角色，该角色将由服务代理承担，并将新创建的策略附加到该角色。我们还将编辑 kops 配置以添加其他节点角色。

aws iam create-role --role-name "aws-servicebroker-cfn-deploy-role" \
--assume-role-policy-document file://cfn-role-trust-rel.json \
--description "AWS Service Broker Deployment Role"

create_cfn_role

记下角色 ARN。在我稍后提及以下内容的地方会用到： ${CFN_ROLE_ARN}。现在，将我们之前创建的策略附加到新角色：

aws iam attach-role-policy \
--role-name "aws-servicebroker-cfn-deploy-role" \
--policy-arn ${CFN_POLICY_ARN}

如果此命令可以运行，则 CLI 中将没有输出，因此如果没有返回任何内容，则表示创建成功。

使用附加的节点权限编辑 kops 集群配置

我们现在需要编辑 kops 集群配置，以向 kops 部署的节点添加额外的权限。我们使用 kops CLI 来完成此操作：

kops edit cluster ${CLUSTER_NAME}

这会将您的 $EDITOR 打开至 kops 集群清单文件。在此文件的 .spec下，我们需要添加以下内容：

# ...
additionalPolicies:
    node: |
      [
       {
            "Action": [
                "cloudformation:CancelUpdateStack",
                "cloudformation:ContinueUpdateRollback",
                "cloudformation:CreateStack",
                "cloudformation:CreateUploadBucket",
                "cloudformation:DeleteStack",
                "cloudformation:DescribeAccountLimits",
                "cloudformation:DescribeStackEvents",
                "cloudformation:DescribeStackResource",
                "cloudformation:DescribeStackResources",
                "cloudformation:DescribeStacks",
                "cloudformation:GetStackPolicy",
                "cloudformation:ListStackResources",
                "cloudformation:ListStacks",
                "cloudformation:SetStackPolicy",
                "cloudformation:UpdateStack",
                "iam:AddUserToGroup",
                "iam:AttachUserPolicy",
                "iam:CreateAccessKey",
                "iam:CreatePolicy",
                "iam:CreatePolicyVersion",
                "iam:CreateUser",
                "iam:DeleteAccessKey",
                "iam:DeletePolicy",
                "iam:DeletePolicyVersion",
                "iam:DeleteRole",
                "iam:DeleteUser",
                "iam:DeleteUserPolicy",
                "iam:DetachUserPolicy",
                "iam:GetPolicy",
                "iam:GetPolicyVersion",
                "iam:GetUser",
                "iam:GetUserPolicy",
                "iam:ListAccessKeys",
                "iam:ListGroups",
                "iam:ListGroupsForUser",
                "iam:ListInstanceProfiles",
                "iam:ListPolicies",
                "iam:ListPolicyVersions",
                "iam:ListRoles",
                "iam:ListUserPolicies",
                "iam:ListUsers",
                "iam:PutUserPolicy",
                "iam:RemoveUserFromGroup",
                "iam:UpdateUser",
                "ec2:DescribeVpcs",
                "ec2:DescribeSubnets",
                "ec2:DescribeAvailabilityZones"
            ],
            "Resource": [
                "*"
            ],
            "Effect": "Allow"
        },
        {
            "Action": [
                "iam:PassRole"
            ],
            "Resource": [
                "arn:aws:iam::*:role/aws-servicebroker-cfn-deploy-role"
            ],
            "Effect": "Allow"
        },
        {
            "Action": [
                "ssm:GetParameters"
            ],
            "Resource": [
                "arn:aws:ssm:*:*:parameter/asb-access-key-id-*",
                "arn:aws:ssm:*:*:parameter/asb-secret-access-key-*"
            ],
            "Effect": "Allow"
        }
      ]

在您下载的 tarball 中，有一个完整配置文件示例，保存为 kops-config-example.yaml.
在您的 $EDITOR 中使用写入文件命令保存文件，然后更新集群：

kops update cluster ${CLUSTER_NAME} –yes

完成更新后，确认额外的策略已附加到 kops 节点角色。此时您应该会看到一个名为 additional.nodes.${CLUSTER_NAME} 的策略。

aws iam list-role-policies --role-name nodes.${CLUSTER_NAME}

安装 AWS Service Broker

为了简化起见，我们创建了一些将 AWS Service Broker 部署到 Kubernetes 集群的脚本。首先，下载 zip 文件：

curl -kLO https://s3.amazonaws.com/awsservicebroker/assets/aws-service-broker-install.tar.gz
mkdir awssb
tar -xvf aws-service-broker-install.tar.gz -C awssb
cd awssb

在此新文件夹中，您将找到一个名为 k8s-variables 的 YAML 文件。打开该文件并编辑以下配置映射：

- aws_cloudformation_role_arn: ${CFN_ROLE_ARN}
- region: YOUR_REGION
- vpc_id: VPC_IN_WHICH_KOPS_IS_RUNNING

让配置文件的其余部分保持不变。

edit_variables

现在，运行安装程序脚本。

chmod +x install_aws_service_broker.sh
./install_aws_service_broker.sh

安装程序运行完毕后，请检查 AWS Service Broker pod 是否正在运行，服务是否已创建

kubectl get pods --namespace=aws-service-broker
kubectl get svc

list_sb_pods_svc

确认 AWS Service Broker 已向 Service Catalog 注册

现在 AWS Service Broker 已完成部署并正在运行，我们可以确认它已向 Service Catalog 注册，并可查看它提供的服务列表。

kubectl plugin svcat get brokers
kubectl plugin svcat get classes

list_broker_plans

预配置新的 SQS 队列

继续下一步，预配置一个简单的 SQS 队列，以便稍后向其发布消息。使用以下内容创建一个名为 provision-sqs.yaml 的文件：

apiVersion: servicecatalog.k8s.io/v1beta1
kind: ServiceInstance
metadata:
  name: opensource-blog-sqs-demo
spec:
  clusterServiceClassExternalName: dh-sqs
  clusterServicePlanExternalName: standard

现在，使用 kubectl 应用更改，并检查预配置是否成功

kubectl apply -f provision-sqs.yaml
kubectl plugin svcat get instances

provision_sqs_queue

您还可以确认已使用 AWS CLI 创建 SQS 队列。

aws --region YOUR_REGION sqs list-queues --queue-name-prefix AWSServiceBroker

绑定预配置服务以供使用

现在，服务已完成预配置，我们需要绑定它以便访问队列。在绑定过程中，代理将创建一组新的 secret，您可以在集群的任意 pod 中使用这些 secret。使用以下内容创建一个名为 sqs-demo-binding.yaml 的文件：

apiVersion: servicecatalog.k8s.io/v1beta1
kind: ServiceBinding
metadata:
  name: os-blog-sqs-binding
spec:
  instanceRef:
    name: opensource-blog-sqs-demo

现在，使用 kubectl 应用更改：

kubectl apply -f sqs-demo-binding.yaml

我们来确认一下是否已绑定成功：

kubectl plugin svcat get bindings
kubectl plugin svcat describe binding os-blog-sqs-binding

此时，应该有一个新创建的 secret，其中包含使用此服务所需的所有信息。

kubectl get secrets

将 secret 附加到任意 pod

现在您已拥有绑定的 secret，像其他任何 secret 一样，您可以将它映射到 Kubernetes 集群中的任意 pod。以下示例会将 pod 内的 QUEUE_URL 和 QUEUE_ARN 环境变量映射至 QueueURL 和 QueueARN 键（位于 os-blog-sqs-binding secret中）：

apiVersion: v1
kind: Pod
metadata:
  name: sqs-demo-app-pod
spec:
  containers:
  - name: psuedocontainer
    image: busybox
    env:
      - name: SQS_QUEUE_URL
        valueFrom:
          secretKeyRef:
            name: os-blog-sqs-binding
            key: QueueURL
      - name: SQS_QUEUE_ARN
        valueFrom:
          secretKeyRef:
            name: os-blog-sqs-binding
            key: QueueARN
  restartPolicy: Never

有关 Kubernetes 中 secret 映射如何运作的更多信息，我建议您阅读此处的官方文档。

我的介绍到此结束！

希望您现在已经对使用 AWS Service Broker 通过 Kubernetes 预配置新 AWS 服务的工作流程以及如何在您的应用程序中使用它有所了解。关注我们的开源博客，我们将与大家分享客户采用的某些模式，包括示例应用程序和演练。

亚马逊AWS官方博客