Currently, the Submariner Engine is a deployment with nodeSelector
(for submariner.io/gateway=true). It is seen that when the label
is removed from the node after SM engine is deployed, SM engine
continues to run on that node. This behavior is not in Sync with
the DaemonSet (used by GlobalnetController) behavior where the POD
is immediately terminated when the label is removed from the node.
This PR updates SM engine as DaemonSet so that we have consistent
behavior between the SM Engine POD and GlobalnetController POD.
Signed-off-by: Sridhar Gaddam <sgaddam@redhat.com>
Added a chart for the globalnet controller which uses the global CIDR.
Also added the global CIDR to the submariner engine pod env so it can
utilize it.
The controller will only be deployed if the CIDR is specified.
Submariner-route-agent daemonset pod needs to query the list of other sm-route-agent
pods in the cluster for their hostIP addresses. The ipaddress will be used as remote
VxLAN Vtep IPs. Currently, sm-route-agent pod does not have the necessary privileges
to list the pods in the submariner namespace of local cluster. This patch addresses
this issue by adding the necessary role.
Error seen:
Failed to list *v1.Pod: pods is forbidden: User
"system:serviceaccount:submariner:submariner-routeagent" cannot list resource "pods"
in API group "" in the namespace "submariner"
Both iptables and nftables use netfilter framework in the kernel for
packet filtering. Many distributions are moving in the direction of
using nftables over iptables. Although, nftables uses a new command
line utility (named nft), starting from iptables >=1.8, it uses
nftables under the hood while continuing to support the same iptables
syntax from the user.
Quoting from Dan's comment [#]
"In iptables 1.8, the maintainers have "deprecated" the classic ip_tables:
the iptables tool now does userspace translation from the legacy UI/UX,
and uses nf_tables under the hood. So, the commands look and feel the
same, but they're now programming a different kernel subsystem.
The problem arises when you mix and match invocations of iptables 1.6
(the previous stable) and 1.8 on the same machine, because although they
look identical, they're programming different kernel subsystems.
Empirically, this causes weird and wonderful things to happen - things
like if you trace a packet coming from a pod, you see it flowing through
both ip_tables and nf_tables, but even if both accept the packet, it then
vanishes entirely and never gets forwarded"
So, as long as we are programming either nf_tables or iptables, we would
not have any issues. Currently, there is no easy way to identify what type
of rules are programmed on the host. This patch follows the same approach
(as described here [*]) that is taken in OpenShift where the host file
system is mounted inside the docker container and iptables utility on the
host is exec'ed for programming any firewall rules.
[#] https://github.com/kubernetes/kubernetes/issues/71305#issuecomment-448052889
[*] https://github.com/kubernetes/kubernetes/issues/71305#issuecomment-521978797
Normally in a vanilla kubernetes deployment, there is a single endpoint for kubernetes.
However, in some deployments (like OpenShift), there could be multiple endpoints.
This patch updates the SUBMARINER_BROKER_URL to use the appropriate "https" endpoint.
Miguel Angel Ajo PelayoandGitHub
Sridhar Gaddam
Mike Kolesnik
Dmitry GroismanandGitHub
Chris KimandGitHub
Thomas PantelisandGitHub
Chris Kim