In this step, we will test the connectivity of the ExternalName service created in the previous step. An ExternalName service allows pods in the Kubernetes cluster to resolve an internal service name to an external DNS name. By verifying connectivity, we ensure that the service functions as expected and allows communication with the external resource. ## Instructions To test the connectivity, we will use a temporary BusyBox pod. Launch the pod by running the following command in your terminal: ```bash kubectl run -it --rm busybox --image=busybox -- sh ``` This command creates a temporary BusyBox pod with an interactive shell (`sh`) and ensures that the pod is deleted (`--rm`) once you exit the session. BusyBox is a lightweight and versatile tool for debugging Kubernetes networking.
Once inside the BusyBox shell, use the `ping` command to test the connectivity to the ExternalName service. Replace `` with the name of the ExternalName service you created (e.g., `externalname-google`): ```bash ping externalname-google ``` The `ping` command sends ICMP echo requests to the service name, which is resolved by Kubernetes DNS to the external domain (`google.com` in this case). If the ExternalName service is working correctly, you should see responses indicating successful communication with the external resource.
You may see an output like this: ```bash / # ping externalname-google PING externalname-google (64.233.180.102): 56 data bytes ^C --- externalname-google ping statistics --- 17 packets transmitted, 0 packets received, 100% packet loss ``` > ⚠️ Note: In containerized environments, there's **no outbound internet access** from the pods unless it’s explicitly allowed. For example, you would see an output like this if you were running it a normal K8's cluster: ```bash PING google.com (142.250.182.14): 56 data bytes 64 bytes from 142.250.182.14: seq=0 ttl=115 time=14.3 ms 64 bytes from 142.250.182.14: seq=1 ttl=115 time=13.9 ms ... ``` This confirms that the service name `externalname-google` resolves to `google.com` and that the cluster can reach the external resource.
Let's go a step further and try to help you understand this better !
Since **ping uses ICMP**, and ICMP is often blocked in container networks, try using something TCP-based, like `wget`, `curl`, or `dig` instead. But BusyBox doesn’t include them by default. So try using another pod image, like this: ```bash kubectl run -it --rm testpod --image=curlimages/curl -- sh ``` Then inside: ```bash nslookup externalname-google curl http://externalname-google ``` - The `curl` command hit this URL: http://google.com/. - Google returned a **404 Not Found**, because hitting `http://google.com/` via raw HTTP (not HTTPS) often triggers that. - Google prefers HTTPS and may not serve basic pages over plain HTTP.
Let's try HTTPS this time: ```bash curl https://externalname-google ``` You might see an error like this now ```bash curl: (60) SSL: no alternative certificate subject name matches target hostname 'externalname-google' ``` This happens because:
- You’re requesting **`https://externalname-google`** - But the certificate returned by `google.com` is valid **only for `google.com`, `www.google.com`, etc.**, not for your internal alias `externalname-google` - So `curl` does an **SSL hostname verification**, and it **fails**
Let's use `-k` or `--insecure` (for testing only) to bypass SSL certificate verification: ```bash curl -k https://externalname-google ``` You will get an output saying: ```bash HTTP 404 from google.com ``` Which means:
- Your pod **resolved `externalname-google` to `google.com`** via Kubernetes DNS - Your pod **reached Google’s servers over HTTPS** - You used `-k` to bypass the SSL name mismatch - Google replied, but said **“I don’t have anything at `/` over raw HTTPS on that alias”** → that’s the 404 #### Why the 404? Google responds with 404 for some requests to `https://google.com/` with unusual headers or paths. It’s just how their infrastructure handles non-standard user agents or empty requests.
This **has nothing to do with Kubernetes** it proves your **ExternalName setup works**. ## Conclusion In this step, we tested the functionality of an `ExternalName` service in Kubernetes by creating a service that maps the internal name `externalname-google` to the external domain `google.com`. We launched a temporary pod using the `curlimages/curl` image to verify DNS resolution and connectivity.
Using the `nslookup` command, we confirmed that Kubernetes DNS correctly resolved `externalname-google` to multiple IP addresses associated with `google.com`. While `ping` failed due to ICMP being blocked or unsupported in the pod network (which is common in containerized environments), we verified actual connectivity using the `curl` command.
Initially, `curl https://externalname-google` failed due to an SSL certificate mismatch, since `google.com`'s certificate does not match the internal alias `externalname-google`. We resolved this by using the `-k` option to skip SSL verification: `curl -k https://externalname-google`. This returned a valid HTTP 404 response from Google, confirming that the service reached the external domain successfully.
This confirms that the ExternalName service is correctly set up and functioning, providing seamless access to external systems from within the Kubernetes cluster.

DNS & Service Discovery