使用OpenShift Validated Reference Design中的Routes将服务迁移到Citrix ADC

OpenShift集群中的静态路由和自动路由

静态路由(默认)-通过静态路由将OpenShift主机子网映射到外部ADC

静态路由在使用HAProxy的旧OpenShift部署中很常见。当将服务从一个服务代理迁移到另一个服务代理时，静态路由可以与Citrix节点控制器(CNC)、Citrix入口控制器(CIC)和CPX并行使用，而不会干扰正常运行的集群中部署的名称空间。

Citrix ADC静态路由配置示例:

c get hostsubnet (Openshift Cluster) snippet oc311-master.example.com 10.x.x。X 10.128.0.0/23 oc311-node1.example.com 10.x.x。X 10.130.0.0/23 oc311-node2.example.com 10.x.x。show route (external Citrix VPX) snippet 10.128.0.0 255.255.254.0 10.x.x。静态10.129.0.0 255.255.254.0静态10.130.0.0 255.255.254.0 10.x.x。x静态

自动路由-使用CNC (Citrix节点控制器)自动外部路由到定义的路由分片

您可以通过两种方式集成Citrix ADC和OpenShift，这两种方式都支持OpenShift路由器分片。

路线类型

• 外部负载均衡器到CIC路由器，HTTP流量不加密。
• 外部负载均衡器到CIC路由器终止TLS。
• secure -passthrough - external load balancer to destination terminating TLS
• 外部负载均衡器到CIC路由器终止TLS。使用TLS将CIC路由器加密到目的地。

查看更多关于不同的路由类型Citrix入口控制器部署方案．

部署支持OpenShift路由器分片的Citrix Ingress控制器

Citrix Ingress Controller (CIC)充当路由器，将流量重定向到不同的pod，以便在不同的可用pod中分配传入的流量。

这个迁移过程也可以是集群升级过程的一部分，从遗留的OpenShift拓扑升级到使用Citrix CNC、CIC和CPX组件的自动化部署，用于集群迁移和升级过程。

这个解决方案可以通过两种方法实现:

• CIC路由器插件(Pod)
• CPX路由器内部OpenShift (Sidecar)

下面将介绍这两种方法以及迁移示例。

OpenShift路由器分片允许在多个OpenShift路由器之间分配一组路由。默认情况下，OpenShift路由器从所有命名空间中选择所有路由。在路由器分片中，标签被添加到路由或命名空间中，标签选择器被添加到路由器中用于过滤路由。每个路由器碎片只选择与标签选择参数匹配的特定标签的路由。

要为OpenShift上的Citrix ADC部署配置路由器分片，每个分片需要一个Citrix入口控制器实例。根据分片所需的条件，将Citrix入口控制器实例部署为路由或名称空间标签或两者都作为环境变量。当Citrix进入控制器处理路由时，它会将路由的标签或路由的名称空间标签与在其上配置的选择标准进行比较。如果路由满足条件，则对Citrix ADC应用相应的配置，否则不应用该配置。

在路由器分片中，从整个路由池中选择一个路由子集是基于选择表达式的。选择表达式是多个值和操作的组合。有关表达式、值和操作的更多信息Citrix的博客．

Bookinfo部署

Bookinfo应用程序的体系结构如下图所示。在第一层部署一个CIC作为OpenShift路由器插件，配置Citrix ADC VPX将南北流量路由到Product Page。在第二层，Citrix ADC CPX被部署为OpenShift路由器，在细节和产品页面微服务之间路由东西流量，而产品页面、评论和评级微服务之间的东西流量则通过默认的HAProxy路由器路由。

Citrix组件

• VPX -向DNS提供集群服务的入口ADC。
• CIC -通过CNC路由向外部Citrix ADC提供ROUTE_LABELS和NAMESPACE_LABELS。
• CPX -在OpenShift集群内提供OpenShift路由。

部署步骤

1. 为部署创建一个名称空间。Oc创建ns SML

2. 将Bookinfo应用程序部署到名称空间中。Oc应用-f bookinfo.yaml

   ################################################################################################## # 细节服务  ################################################################################################## apiVersion: v1:服务元数据:名称:细节标签:应用:细节服务:细节规范:港口:-端口:9080名:http选择器:app: details——apiVersion: extensions/v1beta1 kind:部署元数据:name: details-v1 labels: app: details version: v1 spec: replicas: 1 template: metadata: annotation: sidcar .istio。Io /inject: "false"标签:app: details version: v1 spec: containers: "bookinfo. "yaml“224 l, 5120 c

3. 部署映射到我们产品页面服务的路由文件。指定frontend-ip(这是一级ADC上的内容切换vip)使用-f routes-productpage.yaml

   apiVersion: v1 kind: Route metadata: name: productpage- Route namespace: sml annotations: ingress.citrix.com/frontend-ip: "X.X.X.X" labels: name: productpage spec: host: bookinfo.com path: / port: targetPort: 80 to: kind: Service name: productpage- Service

4. 为sml名称空间部署RBAC文件，该名称空间为CIC提供运行所需的权限。RBAC文件已经有了命名空间。使用-f rbac.yaml

   kind: ClusterRole apiVersion: rbac.authorization.k8s。io/v1beta1 metadata: name: cpx rules: - apiGroups: [""] resources: ["endpoints"， "ingress "，" services"， "pods"， "secrets"， "nodes"， "routes"， "namespaces"，"tokenreviews"，"subjectaccessreview"] verbs:[“获得”,“列表”,“看”)#服务/状态需要更新loadbalance IP服务状态为集成#服务类型loadbalance external-dns - apiGroups:["]资源:“服务/地位”动词。(“补丁”)- apiGroups:["扩展"]资源:[“入口”,“入口/状态”)动词:[“获得”,“列表”,“看”)——apiGroups:[" apiextensions.k8s。apiGroups: ["get"， "list"， "watch"] - apiGroups: ["apps"] resources:["部署"]verbs: ["get"， "list"， "watch"] - apiGroups: ["citrix.com"] resources: ["rewritepolicies"， "canarycrds"， "authpolicies"， "ratelimits"] verbs: ["get"， "list"， "watch"] resources: ["vip "] verbs:apiGroups: ["get"， "list"， "watch"， "create"， "delete"]——kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s. io"] resources: ["routes"] verbs: ["get"， "list"， "watch"]——kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s。io/v1beta1 metadata: name: cpx roleRef: apiggroup: rbac.authorization.k8s。—kind: ServiceAccount name: cpx namespace: sml——apiVersion: v1 kind: ServiceAccount metadata: "rbac. io "。yaml“51 l, 1513 c

5. 部署您的CIC，推动路由配置到您的VPX。将参数ROUTE_LABELS匹配到route-productpage.yaml．有关ROUTE_LABELS语法的更多信息，请参见此博客．Oc应用-f cic-productpage-v2.yaml

   apiVersion: v1:豆荚元数据:名称:中投标签:应用:中投公司规范:serviceAccount: cpx容器:-名称:中投公司形象:“quay.io / citrix / citrix-k8s-ingress-controller: 1.7.6”securityContext:特权:真正的env: -名称:“EULA”价值:“是的”# NetScaler NSIP /剪,剪断的HA(管理必须启用)名称:“NS_IP”价值:X.X.X.X #设置接收流量的NetScaler VIP # - name: "NS_VIP" #值:"X.X.X.X" - name: "NS_USER" value: "nsroot" - name: "NS_PASSWORD" value: "nsroot" - name: "NS_APPS_NAME_PREFIX" value: "BOOK" - name: "ROUTE_LABELS" value: " (productpage) name "# -名称:“NAMESPACE_LABELS”#价值:“程序= hellogalaxy”#为硝基#设置用户名-名称:“NS_USER”# valueFrom: # secretKeyRef: #名称:nslogin #键:nsroot硝基# # #设置用户密码——名字:“NS_PASSWORD”# valueFrom: # secretKeyRef: #名称:nslogin #键:nsroot参数:# -——default-ssl-certificate # default/default-cert imagePullPolicy: Always ~ "cic-productpage-v2. "yaml”48 l, 1165 c

6. 现在，我们必须创建一个无头服务，通过集群中的DNS荚将查找CPX详细信息的用户指向CPX。使用-f detailheadless .yaml

   ################################################################################################## # 细节服务  ################################################################################################## apiVersion: v1:服务元数据:名称:细节规范:港口:-端口:9080姓名:http选择器:应用:cpx

7. 部署新服务以公开详细信息容器。使用-f detailsservice.yaml

   ################################################################################################## # 细节服务  ################################################################################################## apiVersion: v1:服务元数据:名称:详细信息服务标签:应用程序:详细信息服务服务:详细信息服务规范:clusterIP:无port:—port: 9080 name: http selector: app: details

8. 部署一个位于我们创建的详细信息服务前面的新路由定义。注意标签是“name: details”。使用-f detailsroutes.yaml

   apiVersion: v1 kind: Route metadata: name: details- Route namespace: sml annotations: ingress.citrix.com/insecure-port: "9080" labels: name: details spec: host: details path: / port: targetPort: 9080 to: kind: Service name: details- Service

9. E/W流量部署CPX。CIC被部署为sidecar，并配置了一个ROUTE_LABEL参数来匹配detailsroutes.yaml中的标签。Oc应用-f cpx.yaml

   apiVersion:扩展/ v1beta1:部署元数据:名称:cpx标签:应用:cpx服务:cpx规范:副本:1模板:元数据:名称:cpx标签:应用:cpx服务:cpx注释:NETSCALER_AS_APP:“真正”的规范:serviceAccountName: cpx容器:-名称:cpx形象:“quay.io / citrix / citrix-k8s-cpx-ingress: 13.0 -36.28”securityContext:privilege: true env: - name: "EULA" value: "yes" - name: "KUBERNETES_TASK_ID" value: "" - name: "MGMT_HTTP_PORT" value: "9081" ports: - name: http containerPort: 9080 - name: https containerPort: 443 - name: nitro-http containerPort: 9081 - name: nitro-https containerPort: 9443 # readiness probe?imagePullPolicy: Always # Add cic as a sidecar - name: cic image: "quay.io/citrix/citrix-k8s-ingress-controller:1.7.6" env: - name: "EULA" value: "yes" - name: "NS_IP"yaml“75 l, 1939 c

微服务环境中的持续交付选择

持续集成(Continuous Integration, CI)是一种开发实践，它要求开发人员每天多次将代码集成到共享存储库中。

持续交付(CD)是持续集成的自然扩展:在这种方法中，团队确保对系统的每个更改都是可发布的，并且我们可以在按下按钮后发布任何版本。

不同的CD选择及其优缺点如下:

• 重新创建-终止版本1 (V1)，然后推出版本2 (V2)。
  • 优点
    • 易于设置。
    • 应用程序状态完全更新。
  • 缺点
    • 对用户影响较大。预计停机时间取决于关闭和引导持续时间。
• 增加/滚动更新V2慢慢推出，取代V1。
  • 优点
    • 易于设置。
    • 版本在实例间缓慢发布。
    • 便于处理数据重新平衡的有状态应用程序。
  • 缺点
    • Rollout/rollback可能需要一些时间。
    • 支持多个api很困难。
    • 对交通几乎没有控制。
• 蓝色绿色V2和V1一起发布，然后流量会切换到V2。
  • 优点
    • 即时推出/回滚。
    • 避免版本问题，因为整个应用程序是一次更改。
  • 缺点
    • 因为它需要双倍的资源。
    • 在发布到产品之前，应该对整个平台进行适当的测试。
    • 处理多个有状态应用程序可能很困难。
• 金丝雀V2向一部分用户发布，然后进行全面的发布。
  • 优点
    • 为用户子集发布的版本。
    • 便于错误率和性能监控。
    • 快滚。
  • 缺点
    • 缓慢的推出。
    • 处理多个有状态应用程序可能很困难。
• A / B测试V2是在特定条件下发布给用户的子集。
  • 优点
    • 几个版本并行运行。
    • 完全控制流量分配。
  • 缺点
    • 需要智能负载均衡器。
    • 对于给定的会话很难排除错误，因此分布式跟踪成为必需。
• 影子- V2与V11一起接收真实的流量，不影响响应。
  • 优点
    • 使用生产流量对应用程序进行性能测试。
    • 对用户无影响。
    • 在应用程序的稳定性和性能满足要求之前，不得推出。
  • 缺点
    • 因为它需要双倍的资源。
    • 不是真正的用户测试，可能会误导用户。
    • 设置起来很复杂。
    • 在某些情况下需要模拟服务。

参考资料

Citrix GitHub:“OpenShift routes and ingress”

Citrix开发人员文档:“部署解决方案”

Citrix博客:“使用Citrix ADC启用OpenShift路由器分片支持”

OpenShift路线文档: