本文基于istio 1.10版本。
service entry
istio默认是使用k8s作为注册中心,使用k8s的svc dns作为注册发现的机制。
在实际的生产环境下,可能用户的服务并不是部署在k8s上,而是在传统的容器中,针对这些服务,如何进行治理,是istio需要解决的问题。
istio给出的答案是 service entry。
ServiceEntry可以在Istio的内部服务注册表中添加额外的条目,这样网格中自动发现的服务就可以访问/路由到这些手动指定的服务。
一个服务条目描述了一个服务的属性(DNS名称、VIP、端口、协议、端点)。这些服务可以是mesh以外的服务(如Web API),也可以是不属于平台服务注册表的Mesh内部服务(如访问Kubernetes服务的一组虚拟机)。此外,服务条目的端点也可以通过使用workloadSelector字段动态选择。这些端点可以是使用WorkloadEntry对象声明的虚拟机工作负载或Kubernetes pods。
在单一服务下同时选择pod和VM的能力允许将服务从VM迁移到Kubernetes,而不必改变与服务相关的现有DNS名称。
访问集群外的服务
如下,将集群外的一台虚拟机上部署的nginx,集成到服务网格中,供网格中的客户端进行访问。
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: nginx-x
namespace: istio-demo
spec:
hosts:
- xxx.example.com
location: MESH_INTERNAL
ports:
- name: http
number: 80
protocol: HTTP
resolution: STATIC
workloadSelector:
labels:
app: hello2-deploy
选择的workload entry
apiVersion: networking.istio.io/v1alpha3
kind: WorkloadEntry
metadata:
name: vm204
namespace: istio-demo
spec:
address: 192.168.0.204
labels:
app: hello2-deploy
class: vm
version: v1
域名解析
istio 默认不会自动解析service entry的域名,所以需要在客户端pod上手动配置其 /etc/hosts 文件,增加hosts记录 1.1.1.1 xxx.example.com ,其中地址可以随意指定,目的是完成域名解析后,请求报文会被iptables劫持给envoy,由envoy基于hosts进行转发。
这里有一个疑问,不是说envoy接管了所有流量吗?为什么DNS解析的没有通过envoy解析呢?默认istio只是劫持了tcp流量,而DNS默认是通过udp发送的,所以不会经过envoy处理。
istio(1.10版本)支持了dns流量的劫持,会将DNS请求劫持给pilot-

本文详细介绍了如何通过Istio Service Entry将集群外虚拟机上的服务接入到服务网格中,包括DNS解析、流量治理和从VM迁移到K8s的过程。内容涉及Istio 1.10版本特性,如通过pilot-agent分配E类地址解决DNS解析,并讨论了流量切换与服务迁移的实践。
最低0.47元/天 解锁文章
1421

被折叠的 条评论
为什么被折叠?



