ServiceEntry 跨命名空间

说在前面:本文主要测试 service entry 是否可以跨命名空间可见。istio 版本为 1.8.1 k8s 版本为 1.17 网络插件为 calico。

部署示例

详情:创建命名空间 entry1、entry2 部署一个 sleep 服务然后注入 sidecar,创建命名空间 entry3 部署一个 httpbin 服务不注入 sidecar 。然后通过 service entry 的方式将 httpbin 注册到 istio 中。

部署详情:

[root@dev-10 mesh_test]# kubectl get pod -n entry1
NAME                    READY   STATUS    RESTARTS   AGE
sleep-bb5f59fb6-d29mr   2/2     Running   0          29m
[root@dev-10 mesh_test]# kubectl get pod -n entry2
NAME                     READY   STATUS    RESTARTS   AGE
sleep-78458b8cfc-pdsp5   2/2     Running   0          30m
[root@dev-10 mesh_test]# kubectl get pod -n entry3
NAME                       READY   STATUS    RESTARTS   AGE
httpbin-7589dbf6bf-l845z   1/1     Running   0          34m

测试,这时无论通过 entry1 或 entry2 中的 sleep 访问 entry3 中的 httpbin 都不会通过。注意:istio 默认可以访问所有外部服务,需要在部署时将这个特性修改为只允许访问注册服务 ,否则只要网络可达那就可以随意访问

    # REGISTRY_ONLY or ALLOW_ANY
    outboundTrafficPolicy:
      mode: REGISTRY_ONLY 

无论从 entry1 还是 entry2 访问都是失败的。

[root@dev-10 mesh_test]# kubectl exec -it sleep-78458b8cfc-pdsp5 -n entry2 -c sleep -- curl 10.20.21.19:30263/ip
curl: (56) Recv failure: Connection reset by peer
command terminated with exit code 56
[root@dev-10 mesh_test]# kubectl exec -it sleep-bb5f59fb6-d29mr -n entry1 -c sleep -- curl 10.20.21.19:30263/ip
curl: (56) Recv failure: Connection reset by peer
command terminated with exit code 56

创建 ServiceEntry

apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: access-httpbin
  namespace: entry1
spec:
  endpoints:
  - address: 10.20.21.19
    ports:
      http: 30263
  exportTo:
  - .
  hosts:
  - 10.20.21.19
  ports:
  - name: http
    number: 30263
    protocol: http
  resolution: DNS

在 entry1 命名空间创建 service entry,再次测试,这时从 entry1 命名空间访问是可以通过的。而 entry1 中的 service entry 对 entry2 是不可见的。所以 entry2 访问 httpbin 失败。

[root@dev-10 mesh_test]# kubectl exec -it sleep-bb5f59fb6-d29mr -n entry1 -c sleep -- curl 10.20.21.19:30263/ip
{
  "origin": "10.20.21.19"
}
[root@dev-10 mesh_test]# kubectl exec -it sleep-78458b8cfc-pdsp5 -n entry2 -c sleep -- curl 10.20.21.19:30263/ip
curl: (56) Recv failure: Connection reset by peer
command terminated with exit code 56

entry2 命名空间创建 service entry 再次测试。entry2 的 yaml 内容基本与 entry1 内容基本相同,更新 ns 即可。

[root@dev-10 mesh_test]# kubectl exec -it sleep-78458b8cfc-pdsp5 -n entry2 -c sleep -- curl 10.20.21.19:30263/ip
{
  "origin": "10.20.21.19"
}

ok,这下 entry2 命名空间中的 sleep 服务也可以访问 httpbin。

但是此时,不管 entry1 还是 entry2 命名空间都是单独的 service entry。也就是说此时我有两个 service entry 彼此独立。现在删除两个 service entry 创建一个全局的对全部命名空间可见的 service entry。

创建 global service entry

apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: access-httpbin-global
  namespace: istio-system
spec:
  endpoints:
  - address: 10.20.21.19
    ports:
      http: 30263
  exportTo:
  - '*'
  hosts:
  - 10.20.21.19
  ports:
  - name: http
    number: 30263
    protocol: http
  resolution: DNS

直接在 istio-system 创建 service entry。这时 istio 中只有一个 service entry 就是刚刚创建的。

测试访问

[root@dev-10 mesh_test]# kubectl exec -it sleep-bb5f59fb6-d29mr -n entry1 -c sleep -- curl 10.20.21.19:30263/ip
{
  "origin": "10.20.21.19"
}
[root@dev-10 mesh_test]# kubectl exec -it sleep-78458b8cfc-pdsp5 -n entry2 -c sleep -- curl 10.20.21.19:30263/ip
{
  "origin": "10.20.21.19"
}

这时,虽然只有一个 service entry 但是不论 entry1 还是 entry2 访问都可以通过。

注意 service entry 中的 exportTo 字段,查看官网看一下原文解释

A list of namespaces to which this service is exported. Exporting a service allows it to be used by sidecars, gateways and virtual services defined in other namespaces. This feature provides a mechanism for service owners and mesh administrators to control the visibility of services across namespace boundaries.

If no namespaces are specified then the service is exported to all namespaces by default.

The value “.” is reserved and defines an export to the same namespace that the service is declared in. Similarly the value “*” is reserved and defines an export to all namespaces.

NOTE: in the current release, the exportTo value is restricted to “.” or “*” (i.e., the current namespace or all namespaces).

内容大意如下:
当前服务暴露的命名空间列表,暴露出的服务允许其他命名空间中定义的 sidecar、gateway、virtual services 使用。这个服务提供了一种机制:控制跨命名空间边界的服务的可见性。

如果没有指定命名空间,则默认情况下将该服务暴露到所有命名空间。

“.” 定义了暴露在当前命名空间的服务。类似地,“*” 定义了暴露在所有命名空间的服务。

注意:在当前版本 exportTo 的值为 “.” 或者 “*”

结尾:ServiceEntry 可以通过 exportTo 来控制是否跨命名空间可见。即:当前命名空间、指定命名空间、所有命名空间。

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Istio支持多种网络的主从集群配置方案,其中最常用的方案是使用Istio的多集群网格(Multi-Cluster Mesh)功能。该功能利用了Istio的分布式控制平面和数据平面,通过Istio Gateway和VirtualService对象将多个Kubernetes集群连接在一起。 具体来说,您需要在每个Kubernetes集群中部署一个Istio控制平面和一个Istio数据平面。然后,您可以使用Istio Gateway将多个Kubernetes集群连接在一起,通过Istio VirtualService对象定义流量路由和策略控制规则。 在多集群部署中,还需要考虑网络的主从集群配置问题。Istio提供了多种网络的主从集群配置方案,如以下两种: 1. 外部负载均衡器(External Load Balancer)方案:使用外部负载均衡器将请求路由到不同的Kubernetes集群中。在每个Kubernetes集群中,使用Istio Gateway将外部负载均衡器的流量路由到正确的Istio数据平面。 2. 多云服务网格(Multi-Cloud Service Mesh)方案:使用多云服务网格将不同云厂商的Kubernetes集群连接在一起。在每个云厂商的Kubernetes集群中,使用Istio Gateway将流量路由到正确的Istio数据平面。 无论采用何种方案,都需要对Istio的流量路由和策略控制进行配置。您可以使用Istio的VirtualService、DestinationRule和ServiceEntry等对象来定义流量路由和策略控制规则。同时,还需要考虑网络的身份验证和授权问题,Istio提供了多种身份验证和授权机制,如基于JWT的身份验证、RBAC授权等,您可以根据需要进行选择和配置。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值