Kubernetes/Kubectl
kubectl
is the
Kubernetes
command-line tool to deploy and manage applications on a Kubernetes cluster.
For tasks like doing deployments
kubectl
should not be used. Instead please refer to
helm
and
helmfile
.
On Debian 9 (also known as Debian Stretch ) it is included in the package kubernetes-client .
kubectl
can be used to view and troubleshoot cluster components and to do certain maintenance tasks. See also the
kubectl cheatsheet/
.
Run
kubectl
from the deploy servers
Setting KUBECONFIG
kubectl
needs to know how to connect to the cluster and what credentials to use. This information can be stored in the kubeconfig file. By default
kubectl
uses a variable called
KUBECONFIG
to find this kubeconfig file. If the variable is not set, it looks in
~/.kube/config
.
[
1
]
In order to have
kubectl
working with your service the KUBECONFIG variable has to be set. This is of the form:
KUBECONFIG="/etc/kubernetes/${SERVICE}-${CLUSTER}.config"
It is easier to use kube_env for this purpose, see below.
Running kubectl Commands
For example to get a list of pods for a service:
KUBECONFIG="/etc/kubernetes/termbox-staging.config" kubectl get pods
Using kube_env
The tool
kube_env
(present on deploy hosts) simplifies the configuration of
kubectl
and the access to different clusters and services.
tl;dr
Use the following command to setup the environment to execute
kubectl
commands in the desired namespace (by convention named the same as the service):
kube_env $NAMESPACE $CLUSTER
Then you can use
kubectl
to access the resources in the service's namespace:
kubectl get pods
kube_env related helpers
kube_env
is aliased to
kube-env
for consistency with usual CLI tools
kube-environments
and
kube-services
will list for you the available environments and namespaces, which you can also access through the
$KUBERNETES_ENV_ENVIRONMENTS
and
$KUBERNETES_ENV_SERVICES
env variables.
What kube_env actually does
kube_env
sets up the
KUBECONFIG
environment variable to point to the right file for the desired service and user. By convention, for each service, we create an eponymous namespace, as well as two users with varying privilege. For example, for
mw-debug
in the
staging
cluster:
cgoubert@deploy2002:~$ ls -1 /etc/kubernetes/mw-debug*staging.config
# KUBECONFIG for the mw-debug-deploy user
/etc/kubernetes/mw-debug-deploy-staging.config
# KUBECONFIG for the mw-debug user
/etc/kubernetes/mw-debug-staging.config
cgoubert@deploy2002:~$ kube_env mw-debug staging
cgoubert@deploy2002:~$ echo $KUBECONFIG
/etc/kubernetes/mw-debug-staging.config
cgoubert@deploy2002:~$ kube_env mw-debug-deploy staging
cgoubert@deploy2002:~$ echo $KUBECONFIG
/etc/kubernetes/mw-debug-deploy-staging.config
We abuse this naming convention and tell users that the first argument to
kube_env
is the service or the namespace, when it is actually the user.
Privileged user (for admin access)
The "usual" users have restricted privileges. If more access is needed, root (on deploy hosts) has access to the
admin
user:
user@deploy1002:~$ sudo -i
root@deploy1002:~# kube_env admin $CLUSTER
There is also a slightly more privileged user than the default available to deployers:
user@deploy1002:~$ kube_env $NAMESPACE-deploy $CLUSTER
Describe a pod
If there is an issue with a pod not starting and logs don't say anything, use "describe" to get more info. For example:
kubectl describe pod P -n sessionstore