好像我正在用这个打墙,没有太多关于此事的文件也无济于事.

我定期向CRM运行大型自定义导入作业,所有这些都涉及从自定义客户端调用组织服务以将记录推送到CRM.记录通过自定义沙盒插件.

导入需要相当长的时间,我正在尝试通过在多个服务器上设置沙盒处理服务来提高导入速度.

这是我到目前为止所尝试的:

1. 使用沙盒处理服务添加另一台服务器.

                             / Sandbox Processing Service (crmsb1)
   Client > Front End (crm) <
                             \ Sandbox Processing Service (crmsb2)
   

   Run Code Online (Sandbox Code Playgroud)

   使用沙盒处理服务添加另一台服务器没有帮助.前端服务器没有将负载分配到两台服务器上,它继续使用原始服务器.仅当在第一个后端服务器上禁用沙盒处理服务时,第二个服务器才开始处理插件请求.(带回第一个在线没有帮助.)

2. 两个具有所有角色的负载均衡服务器

                           / Full Server (crm1)
   Client > IIS ARR (crm) <
                           \ Full Server (crm2)
   

   Run Code Online (Sandbox Code Playgroud)

   我将本指南(以及许多其他人)写入了这封信,并让Web应用程序通过反向代理工作,但是通过组织服务执行请求失败了.通过不断更改另一个设置消除了无数的WCF错误后,我遇到了这个错误,The security context token is expired or is not valid. The message was not processed.让我认为负载平衡只适用于Web App.

3. 在多台服务器上手动调用组织服务.

           / Full Server (crm1)
   Client <
           \ Full Server (crm2)
   

   Run Code Online (Sandbox Code Playgroud)

   我成功地设置了导入客户端,将导入作业拆分为多个块,并以循环方式同时为每个块调用所有组织服务端点.正如我所希望的那样,这大大加快了进口过程,并且如果需要的话,我还能够进一步扩展.

我阅读了有关此事的任何内容,但我仍然对CRM 2011中的负载均衡如何工作以及可能的配置感到困惑.

这两个 指南广泛使用了负载平衡,但它们没有详细描述它们如何设置.

在我上线之前,这些都是在测试环境中设置的.我为所有服务使用了域帐户,设置了正确的SPN,并且没有使用SSL.我在ARR中尝试使用和不使用Client Affinity(它适用于cookie,所以我假设WCF服务没有锁定到一个后端).

我的问题如下:

1. 是否可以在主动/主动设置(负载平衡)中的多个服务器上设置沙箱处理服务本身(上面的1),还是仅支持主动/被动(HA)？

2. 如果使用多个Sandbox处理服务实例的唯一方法是通过设置具有前端和后端角色的多个服务器(上面的2个),是否有任何方法可以为组织服务使用负载均衡器,如NLB或ARR …

我有两个使用NLB运行的IIS服务器.不幸的是,我无法使用共享会话服务器,因此每个服务器都使用自己的会话.如何确保来自同一用户的所有请求都转发到同一IIS服务器？

我正在按照 kOps 教程在 AWS 上设置集群。我能够创建一个集群

kops create cluster
kops update cluster --yes

但是，在验证我的集群是否正确设置时

kops validate cluster

我陷入了错误：

unexpected error during validation: error listing nodes: Unauthorized

在许多其他 kOps 操作中也会发生同样的错误。

我检查了我的 kOps/K8s 版本，它是 1.19：

> kops version
Version 1.19.1 (git-8589b4d157a9cb05c54e320c77b0724c4dd094b2)

> kubectl version
Client Version: version.Info{Major:"1", Minor:"20" ...
Server Version: version.Info{Major:"1", Minor:"19" ...

我怎样才能解决这个问题？

我尝试了以下方法来让 HTTP 重定向到 HTTPS。我不确定我哪里出错了。

ingress-nginx 目的：

apiVersion: v1
kind: Service
metadata:
  name: ingress-nginx
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: nlb
    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
    service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:...
    service.beta.kubernetes.io/aws-load-balancer-ssl-ports: https
spec:
  type: LoadBalancer
  selector:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
  ports:
    - name: http
      port: 80
      targetPort: http
    - name: https
      port: 443
      targetPort: http

my-ingress 目的：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-ingress
  namespace: my-namespace
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/secure-backends: "true"
spec:
  tls:
   - hosts:
     - app.example.com …

根据 AWS，

网络负载均衡器将流量路由到 Amazon Virtual Private Cloud (Amazon VPC) 内的目标，并且能够每秒处理数百万个请求，同时保持超低延迟

此外，NLB 支持静态/弹性 IP 地址。我的印象是，AWS 通常不推荐 IP 地址，而是要求客户使用 DNS 名称，以便底层硬件可以扩展（并且 IP 地址可以更改）。在 NLB 中，IP 可以保持静态并仍可扩展，但 ALB 上不提供相同的功能，这怎么可能？- AWS 在 NLB 中改进了 ALB 的设计限制吗？或者在 ALB 情况下保留静态 IP 有何技术挑战？

我一直在使用 ALB，直到我意识到我无法将私有 ALB 连接到 API 网关……所以我现在正在尝试 NLB。

到目前为止我有

• 私人NLB
• API 网关 VPC 链接以连接到 NLB

但我不确定如何正确配置 API 网关。我做了：

• 创建了测试路径 GET /test
• 使用 VPC Link，尝试代理和非代理类型
• 但我不确定我应该为端点 URL 放置什么。现在我做了一些类似的事情：虚拟域http://dummydomain.com/api在哪里dummydomain.com，/api我的状态检查 URL 应该可以工作

这是我第一次尝试 NLB。有什么我想念的吗？

目前，当我测试我的 API 网关功能时：我得到 HTTP500

{
  "message": "Internal server error"
}

日志：

Execution log for request 2d5e2e51-b04c-11e8-b9fe-97b354c20146
Tue Sep 04 14:09:45 UTC 2018 : Starting execution for request: 2d5e2e51-b04c-11e8-b9fe-97b354c20146
Tue Sep 04 14:09:45 UTC 2018 : HTTP Method: GET, Resource Path: /test
Tue Sep 04 …

我正在尝试通过 API 网关建立 EC2 管理的 Websocket 连接，以进行授权并限制主机的暴露表面积。

目前，EKS 中运行着一项服务，其私有节点位于内部 NLB 后面。我可以直接通过 NLB 启动 websocket 会话（在网络内部）。如何将 API Gateway 置于此设置之前？

我尝试按照https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-nlb-for-vpclink-设置 RESTful API 网关，并将 NLB 作为 VPC 链接代理资源使用-console.html。但是，尝试建立 wss:// 连接会返回 301。

Websockets 类型的 API 网关似乎想要处理 websocket 连接本身，并独立处理每个新消息/请求。我无法找到一种方法让我的服务管理连接和所有传入消息/请求。

有没有办法实现这一点，或者我是否必须公开公开我的负载均衡器？

问题

有没有办法确保访问仅来自特定的 NLB？在目前NLB的限制下，不知道有没有办法。

局限性

• AWS Network Load Balancer (NLB) 没有安全组 (SG)，因此无法使用 SG 来验证源是否为 NLB。

• NLB（实例 ID 目标）保留外部客户端的源 IP 地址，因此无法使用源 IP 来验证源是否为 NLB。

参考

• 网络负载均衡器没有安全组
• 源IP保护

  如果您使用实例 ID 指定目标，则会保留客户端的源 IP 地址并将其提供给您的应用程序。

我有一个 EKS Kubernetes 1.16.x。具有三个标记为 的公共子网kubernetes.io/role/elb: 1和三个标记为 的私有子网的集群kubernetes.io/role/internal-elb: 1

我正在尝试创建一个内部 NLB LoadBalancer 服务。在内部，我希望它托管在三个私有子网而不是三个公共子网上。

我正在关注https://docs.aws.amazon.com/eks/latest/userguide/load-balancing.html 上的文档

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: nlb
    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
    service.beta.kubernetes.io/aws-load-balancer-internal: true
  name: grafana-nlb
  namespace: prometheus
spec:
  ports:
    - name: service
      port: 80
      protocol: TCP
      targetPort: 3000
  selector:
    app.kubernetes.io/instance: prom
    app.kubernetes.io/name: grafana
  type: LoadBalancer

如果我省略service.beta.kubernetes.io/aws-load-balancer-internal: true注释，一切似乎都可以完美运行，并且完全符合我的预期。我得到一个仅托管在三个公共子网上的公共 NLB。我可以通过 AWS cli 看到这一点，带有aws elbv2 describe-load-balancers, 带有"Scheme": "internet-facing", "Type": "network",。

如果使用service.beta.kubernetes.io/aws-load-balancer-internal: true注释创建它，我会得到一个经典的 ELB 而不是 NLB，而且它仍然是公开的。它"Scheme": …

Kubernetes服务文档显示了以下有关如何为每个 NLB 服务更新节点安全组的说明。

不幸的是，我的 VPC 有 3 个不同的 CIDR。这意味着对于服务上的每个端口，节点的安全组中都会添加 4 条新规则。有一个团队拥有带有 5 个端口的 NLB 服务，这意味着它会向节点的安全组添加 20 条新规则。其他团队通常有 2 个端口，这会导致节点安全组中添加 8 条规则。最终结果是我们有时会达到一个安全组允许的最大数量 64 条规则。

围绕此进行设计的想法是什么，以便团队可以根据需要创建具有任意数量端口的 NLB 服务？