Istio traffic management serviceEntry egress traffic management

Whether it is vs or dr, these are the ingress traffic. There will also be outgoing traffic for pods.

In addition to effective control of incoming traffic, it is also possible to control outgoing traffic. istio-egress is the egress gateway. When the pod goes out, it must go through the egress-gateway to reach a terminal outside.

hosts: - www.baidu.com This is the server to be accessed by the pod. The dnsPolicy:clusterFirst is set in the pod, which means to use the dns in the cluster first, which is the coredns under the kube-system namespace, and location: MESH_EXTERNAL means that hosts are hosts outside the grid.

MESH_EXTERNAL -- outside the grid Control the traffic going to the outside of the grid, Baidu is the traffic outside the grid
MESH_INTERNAL -- Mesh Internal Controls traffic to a host inside the mesh.

[root@k8s-master se]# cat se.yaml 
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: myse
  namespace: istio
spec:
  hosts:
  - www.baidu.com
  ports:
  - number: 443
    name: https
    protocol: HTTPS
  resolution: STATIC
  location: MESH_EXTERNAL
  endpoints:
  - address: 192.168.26.3

If resolution: STATIC address: 192.168.26.3 This is to resolve www.baidu.com to 192.168.26.3 (the address of the endpoint here is the IP of www.baidu.com)

This is to resolve the domain name Baidu to 192.168.26.3

Combined with VS for flow control

[root@k8s-master ~]# netstat -tpnl | grep 80
          tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      91791/nginx: master 
tcp6       0      0 :::80                   :::*                    LISTEN      91791/nginx: master 


[root@k8s-master se]# cat se.yaml 
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: myse
  namespace: istio
spec:
  hosts:
  - xx.rhce.cc
  ports:
  - number: 80
    name: https
    protocol: HTTPS
  resolution: STATIC
  location: MESH_EXTERNAL
  endpoints:
  - address: 192.168.11.135

It is clearly pointed out here that it is going to xx.rhce.cc, that is, the traffic when going out. xx.rhce.cc is not clustered, and it is not in our grid. It has to be added to the grid through se.

# curl xx.rhce.cc
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="https://www.rhce.cc//">here</a>.</p>
</body></html>

If we want to control the export traffic through vs, then we must write the server side into the serviceEntry, if not, then vs will not take effect for him.

If you just add a domain name resolution in it, you can access machines outside the cluster without any problem, but you must use se + vs to achieve control

# cat /etc/hosts
# Kubernetes-managed hosts file.
127.0.0.1	localhost
::1	localhost ip6-localhost ip6-loopback
fe00::0	ip6-localnet
fe00::0	ip6-mcastprefix
fe00::1	ip6-allnodes
fe00::2	ip6-allrouters
10.244.169.156	pod1

If traffic wants to be exported to hosts outside the grid, it is to manage the hosts outside the grid into the grid and then control them.

If you want to control pods to hosts outside the grid, you need to create se for the hosts outside the grid, and then combine vs to control.

If we don't define se, by default, all outgoing traffic is allowed.

default policy

Is it possible to modify the default traffic control --- deny all outgoing traffic?

REGISTRY_ONLY: Only allow access to the grid, and only allow access to those registered in the grid.

exportTo

Pod1 is created under other namespaces, and se and vs defined under a certain namespace also take effect under other namespaces.

Export to is whether the se I defined will affect other namespaces.

The .dot stands for affecting the current namespace.