kubectl
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]]
gladiatr@s
:# gcloud container clusters list
NAME LOCATION MASTER_VERSION MASTER_IP MACHINE_TYPE NODE_VERSION NUM_NODES STATUS
revsys-production-deux us-central1-c 1.11.6-gke.6 23.24.25.26 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:]]
gladiatr@s
[~/git/revsys/revsys/src]
:#
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.
skeleton
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
clusters:
- name: cluster-x
cluster:
server: https://api.somewhere.on.the.internets
certificate-authority-data: (base64 PEM certificate string)
users:
- name: user-tokens:cluster-x-user
token: (service account token (**no base64**))
contexts:
- name: cluster-x
context:
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:]]
gladiatr@s
[~]
:# kubectl config rename-context gke_revsys-150116_us-central1-c_revsys-production revsys-prod-new
(revsys) [[revsys-prod-new:]]
gladiatr@s
[~]
:#
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
Epilogue
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!
-Stephen
