在Solo.io Gloo中使用EKS服务账户集成AWS Lambda的最佳实践

前言

在现代云原生架构中，将Kubernetes与无服务器计算服务（如AWS Lambda）结合使用已成为一种常见模式。Solo.io Gloo作为一款功能强大的API网关，提供了与AWS Lambda无缝集成的能力。本文将详细介绍如何在Amazon EKS集群中，通过服务账户(ServiceAccount)实现Gloo与AWS Lambda的安全集成。

核心概念解析

1. EKS服务账户与IAM角色集成

AWS EKS提供了一种创新机制，允许将Kubernetes服务账户直接映射到AWS IAM角色。这种集成通过以下组件实现：

• OpenID Connect Provider (OIDC): EKS集群的身份提供商
• WebIdentity: 代表Kubernetes服务账户的临时身份凭证
• IAM角色: 定义访问权限的AWS资源
• IAM策略: 具体的权限规则集

2. Gloo与Lambda集成架构

Gloo通过以下组件实现Lambda集成：

• Upstream: 定义Lambda函数作为上游服务
• VirtualService: 配置路由规则将请求转发到Lambda
• ServiceAccount: 提供访问Lambda所需的AWS凭证

详细配置步骤

第一步：配置EKS集群IAM角色

1. 关联OIDC提供商到EKS集群

   • 在AWS控制台创建OIDC提供商
   • 确保EKS集群已正确配置服务账户Webhook

2. 创建IAM策略

   • 策略需要包含以下Lambda相关权限：

     {
         "Version": "2012-10-17",
         "Statement": [
             {
                 "Effect": "Allow",
                 "Action": [
                     "lambda:ListFunctions",
                     "lambda:InvokeFunction",
                     "lambda:GetFunction",
                     "lambda:InvokeAsync"
                 ],
                 "Resource": "*"
             }
         ]
     }
     

3. 创建IAM角色并配置信任关系

   • 角色需要允许特定的服务账户担任该角色：

     {
       "Version": "2012-10-17",
       "Statement": [
         {
           "Effect": "Allow",
           "Principal": {
             "Federated": "arn:aws:iam::<ACCOUNT ID>:oidc-provider/oidc.eks.<REGION>.amazonaws.com/id/<OIDC-ID>"
           },
           "Action": "sts:AssumeRoleWithWebIdentity",
           "Condition": {
             "StringEquals": {
               "oidc.eks.<REGION>.amazonaws.com/id/<OIDC-ID>:sub": [
                 "system:serviceaccount:gloo-system:discovery",
                 "system:serviceaccount:gloo-system:gateway-proxy"
               ]
             }
           }
         }
       ]
     }
     

第二步：部署Gloo Gateway

根据使用场景选择开源版或企业版进行部署：

开源版部署示例:

helm install gloo gloo/gloo \
 --namespace gloo-system --create-namespace --values - <<EOF
settings:
  aws:
    enableServiceAccountCredentials: true
    stsCredentialsRegion: ${REGION}
gateway:
  proxyServiceAccount:
    extraAnnotations:
      eks.amazonaws.com/role-arn: ${AWS_ROLE_ARN}
discovery:
  serviceAccount:
    extraAnnotations:
      eks.amazonaws.com/role-arn: ${AWS_ROLE_ARN}
EOF

部署完成后，验证所有组件状态：

kubectl rollout status deployment -n gloo-system gateway-proxy
kubectl rollout status deployment -n gloo-system gloo
kubectl rollout status deployment -n gloo-system gateway
kubectl rollout status deployment -n gloo-system discovery

第三步：配置Lambda路由

1. 创建Upstream资源

   apiVersion: gloo.solo.io/v1
   kind: Upstream
   metadata:
     name: lambda
     namespace: gloo-system
   spec:
     aws: 
       region: ${REGION}
       roleArn: ${AWS_ROLE_ARN}
   

2. 验证Lambda函数发现 Gloo的Function Discovery Service(FDS)会自动发现可用的Lambda函数：

   kubectl get us -n gloo-system lambda -oyaml
   

3. 创建VirtualService路由

   apiVersion: gateway.solo.io/v1
   kind: VirtualService
   metadata:
     name: default
     namespace: gloo-system
   spec:
     virtualHost:
       domains:
       - '*'
       routes:
       - matchers:
         - prefix: /lambda
         routeAction:
           single:
             destinationSpec:
               aws:
                 logicalName: uppercase
             upstream:
               name: lambda
               namespace: gloo-system
   

第四步：测试Lambda调用

使用curl测试Lambda函数：

curl -v $(glooctl proxy url)/lambda --data '"abc"' -H"content-type: application/json"

首次调用可能会有延迟，因为需要获取STS凭证，后续调用会使用缓存凭证。

高级配置技巧

1. 使用备用IAM角色

可以通过修改Upstream配置来使用不同的IAM角色：

apiVersion: gloo.solo.io/v1
kind: Upstream
metadata:
  name: lambda
  namespace: gloo-system
spec:
  aws:
    region: us-east-1
    roleArn: $SECONDARY_AWS_ROLE_ARN

2. 处理Lambda冷启动

Lambda冷启动可能导致延迟增加，建议配置适当的超时和重试策略：

options:
  timeout: 35s  # 默认15秒
  retries:
    retryOn: '5xx'
    numRetries: 3
    perTryTimeout: '10s'

最佳实践建议

1. 最小权限原则：为服务账户配置仅需的最小权限
2. 凭证缓存：利用Gloo的凭证缓存机制提高性能
3. 监控与日志：密切监控Lambda调用指标和日志
4. 错误处理：合理配置重试策略处理临时性错误
5. 性能优化：考虑使用Lambda预置并发减少冷启动影响

通过本文介绍的配置方法，您可以在EKS环境中安全高效地使用Gloo Gateway集成AWS Lambda服务，构建灵活可靠的Serverless架构。