Don't use the exit code of NewChain() to decide if the chain exists or
not as it doesn't appear to be consistent between nftables and legacy
iptables implementations.
I found that without taking a brief pause between iptables cleanup and
ipset deletion, sometimes the system still thought that there were
iptables references to the ipsets and would error instead of cleaning
the ipsets.
Errors can happen here for a lot of reasons, the user may not have been
running the controller, the definitions may have already been deleted,
the ipset may not be around to be referenced because the user already
cleaned up before.
Reduced the logging to trim user confusion over error statements in the
logs.
Use existing cleanupStale*() methods to cleanup NPC based iptables and
ipsets. This provides a more consistent method of cleanup, consolidates
the logic, and updates it for all of the changes NPC has gone through.
* remove IPVS metrics
Remove metrics for IPVS services when the IPVS service is deleted so
that the number of metrics does not grow without bound.
Fixes#734
* delete metricsMap key when IPVS service is removed
Delete the key in NetworkServicesController.metricsMap when the
respective IPVS configuration is removed.
Remove a period from a comment to conform to kube-router norms
* cleanup stale metrics in a distinct method
* remove unnecessary error return value on cleanupStaleMetrics
This also makes the call that happens upon path withdrawl safer, by
checking to see if the route exists before deleting it.
One departure here is that we used to only log errors, now we return
errors as soon as they are encountered, this may cause some routes to
persist even if they had been cleaned before by stopping at the first
error. However, I think that it makes for more consistent and expected
behavior if this needs to be called in another place.
Refactor this logic so that it can be more easily tested and expanded
without cluttering the pod.go file. Additionally, add some safe guards
around the pod cast to ensure that we're working with pods before we
pass them.
Previously, kube-router would do a full sync on a new pod whether or not
the pod was in an actionable state. This led to needless syncs as many
pods were missing PodIP addresses or other items necessary to apply
policy.
If a pod is missing these items it is better to wait for the next
message that comes via the UpdateFunc below so that we know that the pod
has all of the necessary items to apply policy to it.
With the previous logic, if a pod changed from having HostNetwork =
False to HostNetwork = True, NPC would not trigger a refresh to clear
out the rules that once applied. Now this check has been moved lower in
the fullPolicySync() logic so that it accounts for these pods naturally.
Check if the Pod is actionable before taking NetworkPolicy actions which
includes both adding KUBE-POD-FW and KUBE-NWPLCY chains for it.
Checks have now been consolidated to a single isNetPolActionable()
function which checks for pod phases that we don't want NetworkPolicy
for like: Failed, Completed, and Succeeded, missing pod IP addresses,
and pods with HostNetwork enabled.
fixes#1056
Previously, this section was commented out and full testing to ensure
that the policies matched was not performed. Now the unit tests are more
complete and actually test that the expected policies are present.
Use startBgpServer() rather than doing things individually, so that we
can follow the logic path of how kube-router actually works better. This
allows us to use annotations rather than set stuff manually and allows
us to test more of the code-path of the NRC.
Additionally, this change allows us to actually test some errors better
such as, make sure that startBgpServer() actually throws the error we
expect when only one part of the prepend ASN annotation is present.
Previously, we were not actually testing this code path.
