A good way to "sanity check" connectivity, policy enforcement, and DNS L7-visibility in an environment is to use the connectivity check yaml as described at the end of our getting started guides: https://docs.cilium.io/en/v1.7/gettingstarted/minikube/#deploy-the-connectivity-test
However, this connectivity check tool should also be mentioned in our troubleshooting "connectivity problems" section, but is not: https://docs.cilium.io/en/v1.7/troubleshooting/#connectivity-problems
One suggestion that is particularly important if people will be deploying this into existing environments is that this YAML will only work if deployed in a "clean" namespace with no existing network policies. By default, the instructions currently deploy it in the default namespace, but it might be safer to create it is a special standalone namespace to avoid conflicts with any existing policies. Note: it will also not be compatible with the use of "cluster-wide-network-policies" and we might want to call that out.
A good way to "sanity check" connectivity, policy enforcement, and DNS L7-visibility in an environment is to use the connectivity check yaml as described at the end of our getting started guides: https://docs.cilium.io/en/v1.7/gettingstarted/minikube/#deploy-the-connectivity-test
However, this connectivity check tool should also be mentioned in our troubleshooting "connectivity problems" section, but is not: https://docs.cilium.io/en/v1.7/troubleshooting/#connectivity-problems
One suggestion that is particularly important if people will be deploying this into existing environments is that this YAML will only work if deployed in a "clean" namespace with no existing network policies. By default, the instructions currently deploy it in the default namespace, but it might be safer to create it is a special standalone namespace to avoid conflicts with any existing policies. Note: it will also not be compatible with the use of "cluster-wide-network-policies" and we might want to call that out.