Ready, set, client-go

This post will detail a number of (I think at least) awesome use-cases for client-go. Some of these are use-cases that are similar or may almost be identical to the examples that already exist, but with some additional text that details what some of these terms actually mean and when it makes sense to use them.

Why Client-Go?

Kubernetes exposes everything through an API (all managed by the active API server) from the control-plane, the API is rest based and is the sole way of controlling the a cluster. This means that things like CI/CD pipelines, various dashboards and even kubectl will all use the API through an endpoint (network address) with the credentials (key) in order communicate with a cluster.

As this is just a standard REST over http(s) then there are a myriad of methods that can be used in order to communicate with the Kubernetes API. We can demonstrate this in a quick example:

Check health of Kubernetes API

$ curl -k https://control-plane01:6443/healthz
ok

The above example is an endpoint that requires no authentication, however if we try to use another endpoint without the correct authentication we’ll receive something like the following:

$ curl -k https://control-plane01:6443/api
{
  “kind”: “Status”,
  “apiVersion”: “v1”,
  “metadata”: {
    
  },
  “status”: “Failure”,
  “message”: “forbidden: User \”system:anonymous\” cannot get path \”/api\””,
  “reason”: “Forbidden”,
  “details”: {
    
  },
  “code”: 403
}

Note: Under most circumstances the authentication a user would need to speak with a cluster will live within a $home/.kube/config file. Tooling like kubectl will automatically look for this file in order to communicate with the API endpoint.

I wouldn’t recommend interacting with the raw endpoints as shown above, they’re mainly shown as an example of what is possible. To make life far simpler for developers to interact with the Kubernetes API then there are a number of wrappers/SDKs that provide:

• Control and management of both the SDK <-> API versions
• Language specific objects and methods to provide sane interfaces to Kubernetes objects
• Helper functions for logging in and managing cluster access
• (A plethora of additional features to make your life easier)

As mentioned this post will cover client-go, but there are numerous SDKs in various languages that are covered in varying levels of detail here.

Accessing a cluster, either In-Cluster or Outside cluster

This can be confusing for the first time an end-user will attempt to authenticate with a cluster using client-go.