Boosting your kubectl productivity ♦︎ Learnk8s - 0 views
-
kubectl is your cockpit to control Kubernetes.
-
kubectl is a client for the Kubernetes API
-
Kubernetes API is an HTTP REST API.
- ...75 more annotations...
-
This API is the real Kubernetes user interface.
-
Kubernetes is fully controlled through this API
-
every Kubernetes operation is exposed as an API endpoint and can be executed by an HTTP request to this endpoint.
-
the main job of kubectl is to carry out HTTP requests to the Kubernetes API
-
Kubernetes maintains an internal state of resources, and all Kubernetes operations are CRUD operations on these resources.
-
Kubernetes is a fully resource-centred system
-
Kubernetes API reference is organised as a list of resource types with their associated operations.
-
This is how kubectl works for all commands that interact with the Kubernetes cluster.
-
kubectl simply makes HTTP requests to the appropriate Kubernetes API endpoints.
-
it's totally possible to control Kubernetes with a tool like curl by manually issuing HTTP requests to the Kubernetes API.
-
Kubernetes consists of a set of independent components that run as separate processes on the nodes of a cluster.
-
components on the master nodes
-
Storage backend: stores resource definitions (usually etcd is used)
-
API server: provides Kubernetes API and manages storage backend
-
Controller manager: ensures resource statuses match specifications
-
Scheduler: schedules Pods to worker nodes
-
component on the worker nodes
-
Kubelet: manages execution of containers on a worker node
-
triggers the ReplicaSet controller, which is a sub-process of the controller manager.
-
the scheduler, who watches for Pod definitions that are not yet scheduled to a worker node.
-
creating and updating resources in the storage backend on the master node.
-
The kubelet of the worker node your ReplicaSet Pods have been scheduled to instructs the configured container runtime (which may be Docker) to download the required container images and run the containers.
-
Kubernetes components (except the API server and the storage backend) work by watching for resource changes in the storage backend and manipulating resources in the storage backend.
-
However, these components do not access the storage backend directly, but only through the Kubernetes API.
-
-
double usage of the Kubernetes API for internal components as well as for external users is a fundamental design concept of Kubernetes.
-
All other Kubernetes components and users read, watch, and manipulate the state (i.e. resources) of Kubernetes through the Kubernetes API
-
The storage backend stores the state (i.e. resources) of Kubernetes.
-
command completion is a shell feature that works by the means of a completion script.
-
A completion script is a shell script that defines the completion behaviour for a specific command. Sourcing a completion script enables completion for the corresponding command.
-
kubectl completion zsh
-
/etc/bash_completion.d directory (create it, if it doesn't exist)
-
source <(kubectl completion bash)
-
source <(kubectl completion zsh)
-
autoload -Uz compinit compinit
-
the API reference, which contains the full specifications of all resources.
-
kubectl api-resources
-
displays the resource names in their plural form (e.g. deployments instead of deployment). It also displays the shortname (e.g. deploy) for those resources that have one. Don't worry about these differences. All of these name variants are equivalent for kubectl.
-
.spec
-
custom columns output format comes in. It lets you freely define the columns and the data to display in them. You can choose any field of a resource to be displayed as a separate column in the output
-
kubectl get pods -o custom-columns='NAME:metadata.name,NODE:spec.nodeName'
-
kubectl explain pod.spec.
-
kubectl explain pod.metadata.
-
browse the resource specifications and try it out with any fields you like!
-
JSONPath is a language to extract data from JSON documents (it is similar to XPath for XML).
-
with kubectl explain, only a subset of the JSONPath capabilities is supported
-
Many fields of Kubernetes resources are lists, and this operator allows you to select items of these lists. It is often used with a wildcard as [*] to select all items of the list.
-
kubectl get pods -o custom-columns='NAME:metadata.name,IMAGES:spec.containers[*].image'
-
a Pod may contain more than one container.
-
The availability zones for each node are obtained through the special failure-domain.beta.kubernetes.io/zone label.
-
kubectl get nodes -o yaml kubectl get nodes -o json
-
The default kubeconfig file is ~/.kube/config
-
with multiple clusters, then you have connection parameters for multiple clusters configured in your kubeconfig file.
-
Within a cluster, you can set up multiple namespaces (a namespace is kind of "virtual" clusters within a physical cluster)
-
overwrite the default kubeconfig file with the --kubeconfig option for every kubectl command.
-
Namespace: the namespace to use when connecting to the cluster
-
a one-to-one mapping between clusters and contexts.
-
When kubectl reads a kubeconfig file, it always uses the information from the current context.
-
just change the current context in the kubeconfig file
-
to switch to another namespace in the same cluster, you can change the value of the namespace element of the current context
-
kubectl also provides the --cluster, --user, --namespace, and --context options that allow you to overwrite individual elements and the current context itself, regardless of what is set in the kubeconfig file.
-
for switching between clusters and namespaces is kubectx.
-
kubectl config get-contexts
-
just have to download the shell scripts named kubectl-ctx and kubectl-ns to any directory in your PATH and make them executable (for example, with chmod +x)
-
kubectl proxy
-
kubectl get roles
-
kubectl get pod
-
Kubectl plugins are distributed as simple executable files with a name of the form kubectl-x. The prefix kubectl- is mandatory,
-
To install a plugin, you just have to copy the kubectl-x file to any directory in your PATH and make it executable (for example, with chmod +x)
-
krew itself is a kubectl plugin
-
check out the kubectl-plugins GitHub topic
-
The executable can be of any type, a Bash script, a compiled Go program, a Python script, it really doesn't matter. The only requirement is that it can be directly executed by the operating system.
-
kubectl plugins can be written in any programming or scripting language.
-
you can write more sophisticated plugins with real programming languages, for example, using a Kubernetes client library. If you use Go, you can also use the cli-runtime library, which exists specifically for writing kubectl plugins.
-
a kubeconfig file consists of a set of contexts
-
changing the current context means changing the cluster, if you have only a single context per cluster.