您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
使用 AWS Service Broker 通过 Kubernetes 配置 AWS 服务
 
作者:AWS Localization
  651  次浏览      
 2020-3-30
 
编辑推荐:
本文主要介绍使用 AWS Service Broker 通过 Kubernetes 预配置新 AWS 服务的工作流程以及如何在您的应用程序中使用它,希望对您的学习有所帮助。
本文来自于亚马逊AWS官方博客,由火龙果软件Alice编辑、推荐。

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

因此,社区需要拿出一种方法来确保无论您的容器在何处运行,您都能始终以简单、可预测的方式来控制您的外部依赖项。解决方案: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 绑定。

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

您需要的工具

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

1.具有创建 IAM 权限的 AWS 账户

2.kops 集群 (Kubernetes v1.9.3)

3.Helm v2.9.0-rc5

4.AWS CLI v1.15.11

5.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

将 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

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

创建新角色并附加策略

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

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

记下角色 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

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

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

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

确认 AWS Service Broker 已向 Service Catalog 注册

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

kubectl plugin svcat get brokers
kubectl plugin svcat get classes

预配置新的 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

您还可以确认已使用 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

 
   
651 次浏览       
相关文章

DevOps转型融入到企业文化
DevOps 能力模型、演进及案例剖析
基于 DevOps 理念的私有 PaaS 平台实践
微软开发团队的DevOps实践启示
相关文档

DevOps驱动应用运维变革与创新
运维管理规划
如何实现企业应用部署自动化
运维自动化实践之路
相关课程

自动化运维工具(基于DevOps)
互联网运维与DevOps
MySQL性能优化及运维培训
IT系统运维管理
 
最新课程计划
 
最新文章
DevOps 道法术器,立体化实施框架
DevOps 中高效测试基础架构的最佳实践
DevOps 在公司项目中的实践落地
如何基于 Kubernetes 构建完整的 DevOps 流水线
阿里云Kubernetes实战
最新课程
DevOps体系实践、工具与平台
基于Kubernetes的DevOps实践
互联网运维与DevOps
基于Kubernetes构建企业容器云
企业级DevOps工作体系与平台
更多...   
成功案例
北京 DevOps体系实践、工具与平台
神龙汽车 DevOps体系实践、工具与平台
中国移动通信 网络规划与管理
某航空公司 IT规划与企业架构
某金融公司 IT服务管理(ITIL V3)
更多...