Dean Lewis walks through how to use the Cilium CLI from a workstation to inspect the health of a Cilium deployment and troubleshoot common issues. He covers status checks, configuration changes, connectivity tests, and sysdump collection, along with practical notes on Envoy, Hubble, and basic BGP troubleshooting. Introduction So let's use the Cilium CLI for monitoring and troubleshooting our environment. This is the CLI that you'd install on your own desktop and use to connect remotely to your platform. It's not the Cilium agent CLI that's installed inside the Cilium agent pods, which is typically used for more advanced use cases. You can check out some of the other videos on our Isovalent YouTube channel that cover that. For today, let's have a quick look at the arguments available in the Cilium CLI. We're going to look at things like viewing the Cilium configuration of our platform, with the ability to view, change, and unset values in place. We're also going to look at the connectivity test that we can run to validate that our platform is installed and configured as expected. Configure the Cilium CLI We'll have a look at commands like Cilium status and Cilium sysdump as well, which pull a lot of information for our platform. That's really useful if you need to open a GitHub issue on the Cilium repo, or if you're using Isovalent Enterprise and need to contact the support desk. One of the things I'm going to show you quickly is that we do have the ability to do some basic troubleshooting for Cilium BGP from the CLI. There's more inside the agent CLI itself, but even from here you can see peering state and debug timers and connectivity. I've got Cilium installed inside my platform, so let's use the status command to validate all of that. This checks that all of our pods are up and running as expected. I can see the operator is working. Deploy the Cilium CLI I've also deployed Envoy as a separate DaemonSet inside my environment. That means that when I upgrade Cilium, if there are no updates to Envoy, I'm not disrupting any traffic that's proxied through that data plane. We've got Hubble Relay set up, we're not doing Cluster Mesh today because we've only got a single cluster, and we also have Hubble UI deployed. Next, let's look at configuration. If I run Cilium config, we've got the ability to view all of our configuration. We can set new values, and if we use the Cilium CLI to do that it will restart the Cilium agent pods automatically. We can also delete key-value pairs, which will trigger the same restart. This configuration is kept in the ConfigMap in the namespace where Cilium is installed. It's called cilium-config, and we can correlate the CLI output with the ConfigMap directly. Here debug is disabled, so we're going to enable it because we're thinking about troubleshooting going forward. We run config set debug=true, patch the ConfigMap, and then the pods restart. If I grep for debug now I can see that it's set to true, and if I fetch the ConfigMap from kube-system and output it to YAML we see the same thing there as well. It makes it really easy to configure the platform using that CLI tool. The next command to call out is connectivity test. There are a number of configuration items here. We can choose the images used by the test pods, the namespace, whether to print all flows, which tests to run, how many retries to allow, and which tests to skip. Because these tests deploy resources into the cluster, they take up some capacity. Let's run a specific test, pod-to-cidr. This is a brand-new environment that I've spun up using TKS, so we'll see what happens. TKS deploys some advanced security permissions out of the box that I haven't disabled, so some of these tests may fail immediately. We could fix that by deploying a namespace with the right permissions and telling the connectivity test to use that namespace instead. We can see some failures because those pods won't run, and if I grep the help for namespace you can see that we can send the test to a particular namespace and also specify where Cilium itself is running. The last thing I want to call out is the ability to create a sysdump. If I run Cilium sysdump, we've got debug tool flags, namespace options, operator selection, how many Hubble flows to capture, and even a quick capture mode. the Cilium CLI observability We can also configure the output file name. I'm going to run that as the last command for this video. The first attempt fails because the file name is being escaped and I need to wrap it in quotation marks. Once that's fixed, the CLI collects the data for us. Because we're using the quick mode it only takes a couple of seconds, though some collections may fail depending on the environment. For example, I'm not getting GatewayClass because the Gateway API CRDs are not installed here. That's a really quick overview of using the Cilium CLI from your local machine to understand the health of your platform and start doing some basic troubleshooting. For more advanced troubleshooting, that's where you're going to use the Cilium agent CLI, which lives inside the agent pods themselves. To learn more about both the Cilium CLI and the Cilium agent CLI, download our Cilium cheat sheet from Isovalent.com. It covers topics like upgrading Cilium, configuring ConfigMaps, policy inspection, FQDN caches, layer 7 proxies, and more. Policy configuration Hopefully that makes life a lot easier when you're using the Cilium platform as well. Head on over to Isovalent.com, or use the short link below. Thank you very much.