Failed to validate networking configuration. Please ensure iptables rules are rewriting traffic as expected. about linkerd2 HOT 7 CLOSED

See also #11073 and #11699. We also experienced this issue on AWS after upgrading linkerd-control-plane from v1.16.4. It does not reproduce in v1.16.4 (stable-2.14.3). We've witnessed it in all of the stable versions released after that.

from linkerd2.

It's possible that this setup doesn't leave enough time for the linkerd-cni DaemonSet to become ready before the linkerd control plane in deployed, which is addressed by #11699. However, even with that fix in, you might bump into the Talos issue #7945, for which an fix is being looked at in linkerd/linkerd2-proxy-init#264. Please check if you don't have access to the nsenter binary in your system to see if that's indeed the case.

from linkerd2.

However, even with that fix in, you might bump into the Talos issue #7945, for which an fix is being looked at in linkerd/linkerd2-proxy-init#264. Please check if you don't have access to the nsenter binary in your system to see if that's indeed the case.

For us, I don't believe we're hitting the Talos issue described in the link. We're able to get the linkerd-network-validator to start by deleting the pod that is stuck in the crash loop. In almost all circumstances, the pod starts successfully when it's recreated.

from linkerd2.

@wibed Please note that you posted issuer private key credentials:

          keyPEM: |
            -----BEGIN EC PRIVATE KEY-----
            MHcCAQEEIFJn8Sq4KD1RYRIatP8DFyqxzbP+CjHrksQ6M3abPdl6oAoGCCqGSM49
            AwEHoUQDQgAEEsmkb8EdoCdLL0bMXpP8zvmn3iSwJGJk7LwdqOBeUu0NpSvrnIZd
            wf+WPBQiJ2QSb98KBC8lSjfQ1ThNbj0V4A==
            -----END EC PRIVATE KEY-----

These credentials could be used to forge certificates for your cluster. You should make sure to regenerate these credentials before using them in a real environment.

from linkerd2.

@wibed Please note that you posted issuer private key credentials:

          keyPEM: |
            -----BEGIN EC PRIVATE KEY-----
            MHcCAQEEIFJn8Sq4KD1RYRIatP8DFyqxzbP+CjHrksQ6M3abPdl6oAoGCCqGSM49
            AwEHoUQDQgAEEsmkb8EdoCdLL0bMXpP8zvmn3iSwJGJk7LwdqOBeUu0NpSvrnIZd
            wf+WPBQiJ2QSb98KBC8lSjfQ1ThNbj0V4A==
            -----END EC PRIVATE KEY-----

These credentials could be used to forge certificates for your cluster. You should make sure to regenerate these credentials before using them in a real environment.

i know, this is for you to avoid the necessity to google openssl commands... again.
these arent production credentials. (its play-dough man =))

from linkerd2.

@jdinsel-xealth for your specific case, that's gonna get addressed with the cni-repair controller (#11699), that should be included in an edge release as soon as that merges.

from linkerd2.

i dont think either, as i believe the cni has not correctly been dispatched on the host as assumed.
i am not sure how to approach this on talos and am no longer interested in looking for a solution.

kindly reopen if someone wants to take my place.

from linkerd2.