Tidbits | Feb. 3, 2019

Pro-Tip – GKE: part 2

by Stephen Spencer |   More posts by Stephen


kubectl should, ideally, match the server version. At the very least, the client binary should usually be within the minor version ballpark of the server.

NOTE: Sometimes, in the immortal words of Freddie Childress, "shit be broke!" An example can be found in the v1.10.x family. The only known work-around is to use a client binary from v1.11.x. The takeaway: your milleage may vary, but if using an off-version and receiving strange results, try using the version-equivalent client.

Client binary downloads for v1.11.6 can be found here

Authorizing the Client Environment (part 1)

It is neccessary to add the Kubernetes Engine Cluster-Admin role to the target (Google) userid. This is accomplished via the IAM & admin section of the GCP console.

  • click the pencil widget under the inheritance column
  • click Add Another Role
  • scroll or search to Kubernetes Cluster Admin

Authenticating the Client Environment

The Google Cloud SDK is required.

Once installed and configured for the desired Google account, the following commands are used to populate ~/.kube/config with the correct bits to authenticate with the new cluster:

(revsys) [[revsys-prod-cluster:revsys-com-playground]]
:# gcloud container clusters list
revsys-production-deux  us-central1-c  1.11.6-gke.6  n1-highmem-2   1.11.6-gke.6      2          RUNNING

:# gcloud container clusters get-credentials revsys-production-deux
Fetching cluster endpoint and auth data.
kubeconfig entry generated for revsys-production-deux.

(revsys) [[gke_revsys-150116_us-central1-c_revsys-production-deux:]]

Holy progenitor of mythological figure, Batman! That's ugly!

Later (post v1.9.x?) kubectl binaries added the very welcome feature of easily renaming kube contexts!

NOTE: ~/.kube/config is a YAML file. The outer structure is a map with most of the values expressed as lists of single-element maps.


apiVersion: v1
kind: Config
clusters: []
users: []
contexts: []
current-context: str
preferences: {}  <- I have no idea what this can be used for

meta-outline of a populated context + associated bits

apiVersion: v1
kind: Config
  - name: cluster-x
      server: https://api.somewhere.on.the.internets
      certificate-authority-data: (base64 PEM certificate string)
  - name: user-tokens:cluster-x-user
    token: (service account token (**no base64**))
  - name: cluster-x
      user: user-tokens:cluster-x-user
      cluster: cluster-x
      namespace: (configured default namespace)(_optional_)
current-context: cluster-x
preferences: {}

The following command simply changes the name of the context. (No cluster or user definitions were harmed in the filming of this episode):

(revsys) [[gke_revsys-150116_us-central1-c_revsys-production:]]
:# kubectl config rename-context gke_revsys-150116_us-central1-c_revsys-production revsys-prod-new

(revsys) [[revsys-prod-new:]]

Authorizing the Client Environment (part 2)

GCP IAM integration is ongoing. Currently, however, assinging the GCP IAM role (kubeneretes-cluster-admin) only gets you halfway to the proverbial church.

To complete the authorization of the target account requires creating a kubernetes cluster role binding that grants full access to 100% of the kube API.

Without this step, the target user account will be unable to create RBAC roles or cluster roles. The next few posts will involve the creation and/or manipulation of such roles.

kubectl create clusterrolebinding he-man --clusterrole=cluster-admin --user=googleid@googledomain


This post covered the steps for setting up a local environment to allow for interacting with the new GKE cluster.

Next up: the helm package manager

Thanks for reading!


gke   gcp   kubernetes   iam  

Accessing a New GKE Cluster{% else %}

2019-02-03T20:31:04.570946 2019-02-03T20:49:07.785440 2019 gke,gcp,kubernetes,iam