Anthos Service Mesh 允许您将网关部署和管理为服务网格的一部分。网关描述了在网格边缘运行的负载均衡器,用于接收传入或传出 HTTP/TCP 连接。网关是 Envoy 代理,可让您精确控制进出网格的流量。网关主要用于管理入站流量,但您也可以将网关配置为管理其他类型的流量。例如:
出站网关:通过出站流量网关,您可以为离开网格的流量配置专用退出节点,从而限制哪些服务可以或应该访问外部网络,或者启用安全控制出站流量的添加“网格安全”等。
东西网关:东西流量的代理,允许服务工作负载在不同网络上的多主网格中跨集群边界通信。默认情况下,此网关在互联网上为公开。
本页面介绍了部署和升级网关代理的最佳做法,以及配置自己的 istio-ingressgateway
和 istio-egressgateway
网关代理的示例。通过将 Gateway 配置应用于网关代理,可以实现流量拆分、重定向和重试逻辑。然后,您可以将虚拟服务绑定到网关,而不是将应用层流量路由 (L7) 添加到同一 API 资源。因此,您可以像管理服务网格中的任何其他数据层面流量一样管理网关流量。
您可以通过不同的方式部署网关,并且可以选择在同一集群中使用多个拓扑。如需详细了解这些拓扑,请参阅 Istio 文档中的网关部署拓扑。
部署网关的最佳做法
- 单独部署和管理控制层面和网关。
- 为保证安全性,我们建议您在与控制层面不同的命名空间中部署网关。
- 使用自动 Sidecar 注入(自动注入)来注入网关的代理配置,就像为服务注入 Sidecar 代理一样。
最佳做法包括:
- 您的命名空间管理员无需对整个集群授予较高权限,即可管理网关。
- 让您的管理员使用与管理 Kubernetes 应用相同的部署工具或机制来部署和管理网关。
- 使管理员能够完全控制网关 Deployment,同时简化操作。当新升级可用或配置更改时,管理员只需重启网关即可更新它们。这使得操作网关 Deployment 的体验与操作服务的 Sidecar 代理相同。
部署网关
为通过现有部署工具支持用户,Anthos Service Mesh 支持以与 Istio 相同的方式部署网关:IstioOperator
、Helm 和 Kubernetes YAML。每种方法都会产生相同的结果。虽然您可以选择自己最熟悉的方法,但我们建议您使用 Kubernetes YAML 方法,因为它更易于修改,而且您可以将混合清单存储在源代码控制系统中。
为网关创建命名空间(如果您还没有命名空间)。将
GATEWAY_NAMESPACE
替换为您的命名空间名称。kubectl create namespace GATEWAY_NAMESPACE
通过在网关命名空间中应用修订版本标签,在网关上启用自动注入功能。边车注入器网络钩子会使用修订版本标签将注入的代理与特定控制平面修订版本相关联。您使用的修订版本标签取决于您部署的是由 Google 管理的控制平面还是集群内控制平面。
根据您的安装类型(Google 管理的控制平面或集群内控制平面)选择下面的标签页。
由 Google 管理
对于 Google 管理的控制层面,修订版本标签对应于发布渠道:
修订版本标签 渠道 istio.io/rev=asm-managed
普通 istio.io/rev=asm-managed-rapid
快速 istio.io/rev=asm-managed-stable
稳定版 网关命名空间可以与服务位于同一发布渠道,也可以位于不同的发布渠道。我们建议您在集群上使用相同的发布渠道。如需查看命名空间正在使用的发布渠道,请执行以下操作:
kubectl get namespace NAMESPACE -L istio.io/rev
集群内
对于集群内控制层面,
istiod
Service 和 Deployment 具有一个类似于istio.io/rev=asm-1118-4
的修订版本标签,其中asm-1118-4
标识 Anthos Service Mesh 版本。修订版本将成为istiod
服务名称的一部分,例如istiod-asm-1118-4.istio-system
。使用以下命令在集群内控制层面的
istiod
上查找修订版本标签:kubectl get deploy -n istio-system -l app=istiod -o jsonpath="{.items[*].metadata.labels.'istio\.io\/rev'}"'{"\n"}'
启用用于注入的命名空间。将
REVISION
替换为修订版本标签的值。kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev=REVISION --overwrite
您可以忽略输出中的
"istio-injection not found"
消息。这意味着命名空间之前没有istio-injection
标签,对于 Anthos Service Mesh 的新安装或新部署,这是预期现象。如果命名空间同时具有istio-injection
和修订版本标签,自动注入将失败,因此 Anthos Service Mesh 文档中的所有kubectl label
命令都包含移除istio-injection
标签。如果您使用
asmcli
安装了 Anthos Service Mesh,请切换到您在--output_dir
中指定的目录,然后使用cd
转到samples
目录。如果您未使用
asmcli
进行安装,请从anthos-service-mesh
代码库中复制网关的配置文件。您可以按原样部署位于
samples/gateways/
目录中的示例网关配置,也可以根据需要对其进行修改。Ingress
kubectl apply -n GATEWAY_NAMESPACE -f samples/gateways/istio-ingressgateway
出站流量
kubectl apply -n GATEWAY_NAMESPACE -f samples/gateways/istio-egressgateway
创建部署后,验证新服务是否正常运行:
kubectl get pod,service -n GATEWAY_NAMESPACE
验证输出内容类似如下:
NAME READY STATUS RESTARTS AGE pod/istio-ingressgateway-856b7c77-bdb77 1/1 Running 0 3s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/istio-ingressgateway LoadBalancer 10.24.5.129 34.82.157.6 80:31904/TCP 3s
网关选择器
将网关配置应用于 istio-ingressgateway
和 istio-egressgateway
代理,以管理网格的入站和出站流量,从而指定要进入或离开网格的流量。网关部署的 Pod 上的标签供网关配置资源使用,因此,您的网关选择器必须与这些标签匹配。
例如,在上述部署中,istio=ingressgateway
是在网关 Pod 上设置的。如需将网关配置应用于这些部署,您需要选择相同的标签:
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
name: gateway
spec:
selector:
istio: ingressgateway
...
如需查看网关配置和虚拟服务的示例,请参阅 Online Boutique 示例应用中的 frontend.yaml。
正在升级网关
就地升级
对于大多数用例,您应该按照就地升级模式升级网关。由于网关利用 Pod 注入功能,因此创建新网关 Pod 将自动注入最新的配置(包括版本)。
如果要更改网关使用的控制层面修订版本,您可以在网关 Deployment 上设置 istio.io/rev 标签,该标签也将触发滚动重启。
Google 管理的控制层面
由于 Google 负责管理 Google 管理的控制层面升级,因此您只需重启网关 Deployment,即可自动注入新的 pod 最新配置和版本。
kubectl rollout restart deployment istio-ingressgateway \
-n GATEWAY_NAMESPACE
集群内控制层面
如需在集群内控制层面时将相同的模式应用于网关,您需要更改网关使用的控制层面修订版本。请在网关 Deployment 上设置 istio.io/rev
标签,以触发滚动重启。
- 更新命名空间或网关 pod 的修订版本标签。
- 如果您已为注入的命名空间添加标签,请执行以下操作:
- 将命名空间中的 istio.io/rev 标签设置为新的修订版本值
kubectl label namespace GATEWAY_NAMESPACE \
istio-injection- istio.io/rev=REVISION \
--overwrite
OR
- 如果您为网关 pod 启用了注入:
- 将 Deployment 上的 istio.io/rev 标签设置为新的修订版本值
- Kubernetes YAML
- 将 Deployment 上的 istio.io/rev 标签设置为新的修订版本值
cat <<EOF > gateway-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: istio-ingressgateway
namespace: GATEWAY_NAMESPACE
spec:
selector:
matchLabels:
istio: ingressgateway
template:
metadata:
annotations:
# This is required to tell Anthos Service Mesh to inject the gateway with the
# required configuration.
inject.istio.io/templates: gateway
labels:
istio: ingressgateway
istio.io/rev: REVISION
spec:
containers:
- name: istio-proxy
image: auto # The image will automatically update each time the pod starts.
EOF
kubectl apply -f gateway-deployment.yaml
Canary 升级(高级)
如果您使用的是集群内控制平面,并且希望更慢地控制新控制平面修订版本的发布,则可以遵循 Canary 升级模式。您可以运行网关 Deployment 的多个版本,并确保部分流量按预期正常运行。例如,如果要发布新的修订版本 Canary,请创建网关 Deployment 的副本,并将 istio.io/rev=REVISION
标签设置为新修订版本和新名称,例如istio-ingressgateway-canary
:
apiVersion: apps/v1
kind: Deployment
metadata:
name: istio-ingressgateway-canary
namespace: GATEWAY_NAMESPACE
spec:
selector:
matchLabels:
istio: ingressgateway
template:
metadata:
annotations:
inject.istio.io/templates: gateway
labels:
istio: ingressgateway
istio.io/rev: REVISION # Set to the control plane revision you want to deploy
spec:
containers:
- name: istio-proxy
image: auto
创建此 Deployment 后,您将有两个网关版本,这两个版本由同一 Service 选择:
kubectl get endpoints -o
"custom-columns=NAME:.metadata.name,PODS:.subsets[*].addresses[*].targetRef.name"
NAME PODS
istio-ingressgateway istio-ingressgateway-788854c955-8gv96,istio-ingressgateway-canary-b78944cbd-mq2qf
如果您确信应用按预期正常运行,请运行以下命令,通过删除使用旧 istio.io/rev 标签集的 Deployment 来转换为新版本:
kubectl delete deploy/istio-ingressgateway -n GATEWAY_NAMESPACE
如果您在使用新版网关测试应用时遇到问题,请运行以下命令,通过删除使用新 istio.io/rev 标签集的 Deployment,切换回旧版:
kubectl delete deploy/istio-ingressgateway-canary -n GATEWAY_NAMESPACE