亚马逊AWS官方博客

使用 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

svc_list_pods_after_install

权限

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

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

confirm_sqs_queue

绑定预配置服务以供使用

现在,服务已完成预配置,我们需要绑定它以便访问队列。在绑定过程中,代理将创建一组新的 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

confirm_sqs_binding

将 secret 附加到任意 pod

现在您已拥有绑定的 secret,像其他任何 secret 一样,您可以将它映射到 Kubernetes 集群中的任意 pod。以下示例会将 pod 内的 QUEUE_URL QUEUE_ARN 环境变量映射至 QueueURLQueueARN 键(位于 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 服务的工作流程以及如何在您的应用程序中使用它有所了解。关注我们的开源博客,我们将与大家分享客户采用的某些模式,包括示例应用程序和演练。