linkerd2: ip tables error when initializing the pod in OpenShift 3.7
I’m deploying conduit to openshift 3.7. the step for my deployment can be found here: https://github.com/raffaelespazzoli/openshift-enablement-exam/tree/master/misc/conduit
I get an error when the init container initializes the pod’s iptables. here is the log:
[rspazzol@rspazzol conduit]$ oc logs emoji-svc-3777961096-ws7nv -c conduit-init
2018/01/15 15:07:50 Tracing this script execution as [1516028870]
2018/01/15 15:07:50 State of iptables rules before run:
2018/01/15 15:07:50 > iptables -t nat -vnL
2018/01/15 15:07:50 < Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain CONDUIT_REDIRECT (0 references)
pkts bytes target prot opt in out source destination
0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 /* conduit/ignore-port-80/1516028824 */
0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:4190 /* conduit/ignore-port-4190/1516028824 */
2018/01/15 15:07:50 > iptables -t nat -F CONDUIT_REDIRECT
2018/01/15 15:07:50 <
2018/01/15 15:07:50 > iptables -t nat -X CONDUIT_REDIRECT
2018/01/15 15:07:50 <
2018/01/15 15:07:50 Will ignore port 80 on chain CONDUIT_REDIRECT
2018/01/15 15:07:50 Will ignore port 4190 on chain CONDUIT_REDIRECT
2018/01/15 15:07:50 Will redirect all INPUT ports to proxy
2018/01/15 15:07:50 > iptables -t nat -F CONDUIT_OUTPUT
2018/01/15 15:07:50 < iptables: No chain/target/match by that name.
2018/01/15 15:07:50 > iptables -t nat -X CONDUIT_OUTPUT
2018/01/15 15:07:50 < iptables: No chain/target/match by that name.
2018/01/15 15:07:50 Ignoring uid 2102
2018/01/15 15:07:50 Redirecting all OUTPUT to 4140
2018/01/15 15:07:50 Executing commands:
2018/01/15 15:07:50 > iptables -t nat -N CONDUIT_REDIRECT -m comment --comment conduit/redirect-common-chain/1516028870
2018/01/15 15:07:50 <
2018/01/15 15:07:50 > iptables -t nat -A CONDUIT_REDIRECT -p tcp --destination-port 80 -j RETURN -m comment --comment conduit/ignore-port-80/1516028870
2018/01/15 15:07:50 <
2018/01/15 15:07:50 > iptables -t nat -A CONDUIT_REDIRECT -p tcp --destination-port 4190 -j RETURN -m comment --comment conduit/ignore-port-4190/1516028870
2018/01/15 15:07:50 <
2018/01/15 15:07:50 > iptables -t nat -A CONDUIT_REDIRECT -p tcp -j REDIRECT --to-port 4143 -m comment --comment conduit/redirect-all-incoming-to-proxy-port/1516028870
2018/01/15 15:07:50 < iptables: No chain/target/match by that name.
2018/01/15 15:07:50 Aborting firewall configuration
2018/01/15 15:07:50 exit status 1
Any suggestions? It doesn’t seem OCP dependent to me.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 18 (12 by maintainers)
I agree that it will take a long time. And I don’t have a good answer to your question. But I work in consulting and I am skeptical that the customers I deal with (especially the large ones) will allow pods with CAP_NET_ADMIN to run in production environment.
2018-02-14 20:17 GMT-07:00 Brian Smith notifications@github.com:
– ciao/bye Raffaele
@raffaelespazzoli I agree in the long term (see https://github.com/kubernetes/kubernetes/issues/55435#issuecomment-365469675 for example). However, what should we do in the short- to mid- term? Realistically I would expect it might take a year or more for Kubernetes to spec out an interface like you suggest and for CNI implementations to implement it.
I have been thinking about this issue and I am believe that we should start considering a different approach (quoting from my proposal to istio, you can replace istio with conduit):
"We could define a CRD that describes how connections should be routed inside a pod. These rules would be expressed in a technology agnostic manner, so that they could be implemented not only with iptables but with other means. This CRD would also have a pod selector to specify which pods should get those rule. The Istio control plane would create these CRD objects. The CNI driver would honor them when the pod is created, but before any container is started.
I believe this way no specific privileges would be required by the pod. Also this approach is probably general enough that other service mesh implementations could leverage it."
Keep in mind that this is my opinion and does not reflect redhat thinking.
2018-02-14 14:02 GMT-07:00 William Morgan notifications@github.com:
– ciao/bye Raffaele