-
Bug
-
Resolution: Done
-
Major
-
maistra-1.1.1
-
None
-
+
-
MAISTRA 1.1.3
I am having an issue with OpenShift ServiceMesh 1.1 (Maistra, Istio) in combination with pods that have or should have an additionalNetwork with IPVLAN. The main goal is to have a namespace where all pods have the istio-proxy sidecar injected and to preserve the sourceIP (= clientIP) in the pod where the TLS offloading is happening.
In order to attach the additional interface to pod you have to annotate the pod accordingly.[1] In my case the needed annotation is "k8s.v1.cni.cncf.io/networks: ipvlan-net". Note that the sidecar injection is disabled:
apiVersion: v1
kind: Pod
metadata:
name: ip-pod
labels:
app: ip
annotations:
k8s.v1.cni.cncf.io/networks: ipvlan-net
sidecar.istio.io/inject: "false"
spec:
containers:
- resources:
name: ip-container
image: nginxinc/nginx-unprivileged
ports:
- name: http
containerPort: 8080
protocol: TCP
}
This creates the pod with the additional IPVLAN interface:
~ $ oc rsh -c ip-container ip-pod1 ~ $ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 3: eth0@if31: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1450 qdisc noqueue state UP link/ether 0a:58:0a:83:00:16 brd ff:ff:ff:ff:ff:ff inet 10.131.0.22/23 brd 10.131.1.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::1091:8eff:fefe:658a/64 scope link valid_lft forever preferred_lft forever 4: net1@if2: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UNKNOWN link/ether 00:1a:4a:16:01:e0 brd ff:ff:ff:ff:ff:ff inet 10.10.10.10/24 brd 10.10.10.255 scope global net1 valid_lft forever preferred_lft forever inet6 fe80::1a:4a00:116:1e0/64 scope link valid_lft forever preferred_lft forever
The next step is to enable the sidecar injection and re-create the pod. The creation of the pod and the sidecar is successful but the IPVLAN interface is not being created. In fact the sidecar injection process removes the "k8s.v1.cni.cncf.io/networks: ipvlan-net" annotation and puts it in another field:
kind: Pod
apiVersion: v1
metadata:
generateName: ip-pod1
annotations:
k8s.v1.cni.cncf.io/networks: v1-1-istio-cni
k8s.v1.cni.cncf.io/networks-status: ''
openshift.io/scc: restricted
sidecar.istio.io/inject: 'true'
sidecar.istio.io/status: >- {"version":"773f050195566e10249458ebfe7cbc78e3fd9b728f7fdeaa355ab0cbe171fc2a","initContainers":null,"containers":["istio-proxy"],"volumes":["istio-envoy","istio-certs"],"imagePullSecrets":null}
....
....
- name: ISTIO_METAJSON_ANNOTATIONS
value: >
{"k8s.v1.cni.cncf.io/networks":"[ { \"name\": \"ipvlan-net\" }
]","openshift.io/scc":"restricted","sidecar.istio.io/inject":"true"}
....
As a result, in fact i actually don't know the root cause, the additional IPVLAN interface is not being created:
~ $ oc rsh -c ip-container ip-pod1 ~ $ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 3: eth0@if39: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1450 qdisc noqueue state UP link/ether 0a:58:0a:83:00:1e brd ff:ff:ff:ff:ff:ff inet 10.131.0.30/23 brd 10.131.1.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::e0c2:5ff:fe51:b360/64 scope link valid_lft forever preferred_lft forever
This leads to my questions:
- Is the ServiceMesh (Maistra, Istio) behavior regarding IPVLAN as expected or is this a bug?
- Generally, is there another approach to preserve the clientIP in combination with Maistra?
- is related to
-
-
- Closed
-
