pydevops
commented
6 years ago My use case is sending the logstash and fluentd data over the VPC peered ELK cluster, which sits in its own GCP project (management project). With the changes from @vdavidoff made, I am able to add the CIDR range in masqueradeCIDRs. Verified working in this case. example configmap.yaml
apiVersion: v1
data:
config: |-
nonMasqueradeCIDRs:
- 10.0.0.0/8
- 172.16.0.0/12
- 192.168.0.0/16
masqueradeCIDRs:
- 10.10.0.0/20
resyncInterval: 60s
kind: ConfigMap
metadata:
creationTimestamp: null
name: ip-masq-agent
namespace: kube-systemiptables changes on the GKE node
Chain POSTROUTING (policy ACCEPT 24 packets, 1440 bytes)
pkts bytes target prot opt in out source destination
2953 188K KUBE-POSTROUTING all -- * * 0.0.0.0/0 0.0.0.0/0 /* kubernetes postrouting rules */
1600 99790 MASQUERADE all -- * * 0.0.0.0/0 !10.0.0.0/8 /* kubenet: SNAT for outbound traffic from cluster */ ADDRTYPE match dst-type !LOCAL
666 43411 IP-MASQ-AGENT all -- * * 0.0.0.0/0 0.0.0.0/0 /* ip-masq-agent: ensure nat POSTROUTING directs all non-LOCAL destination traffic to our custom IP-MASQ-AGENT chain */ ADDRTYPE match dst-type !LOCAL
Chain DOCKER (0 references)
pkts bytes target prot opt in out source destination
Chain IP-MASQ-AGENT (1 references)
pkts bytes target prot opt in out source destination
0 0 MASQUERADE all -- * * 0.0.0.0/0 10.10.0.0/20 /* ip-masq-agent: outbound traffic is subject to MASQUERADE */
0 0 RETURN all -- * * 0.0.0.0/0 169.254.0.0/16 /* ip-masq-agent: local traffic is not subject to MASQUERADE */
20 1200 RETURN all -- * * 0.0.0.0/0 10.0.0.0/8 /* ip-masq-agent: local traffic is not subject to MASQUERADE */
0 0 RETURN all -- * * 0.0.0.0/0 172.16.0.0/12 /* ip-masq-agent: local traffic is not subject to MASQUERADE */
0 0 RETURN all -- * * 0.0.0.0/0 192.168.0.0/16 /* ip-masq-agent: local traffic is not subject to MASQUERADE */
0 0 MASQUERADE all -- * * 0.0.0.0/0 0.0.0.0/0 /* ip-masq-agent: outbound traffic is subject to MASQUERADE (must be last in chain) */
fejta-bot
k8s-ci-robot
Let me preface this PR by indicating I realize there may be reasons this feature has already been considered and rejected, or never considered, but I can't find trace of that and don't want to assume anything.
Context:
I can think of a number of reasons this feature could be useful, but I'll describe my most straightforward use case.
I want to allow pods to masquerade to an explicit list of CIDRs. If that range of CIDRs is small and/or can be collapsed easily, using the existing nonMasqueradeCIDR list causes me to think a little bit backwards about what I'm trying to accomplish, but it's doable relatively easily.
However, if the CIDRs to which I want to allow masquerade are large in number and/or cannot be collapsed into a very small set of CIDRs, I run into two problems:
For more context on the use case, I would use the feature by creating an explicit list of masqueradeCIDRs, and a single entry of 0.0.0.0/0 for nonMasqueradeCIDRs, effectively disabling the end of chain MASQUERADE catch-all.
A pull request implementing this feature has already been opened.
Thanks for your consideration.