I have multiple contexts and I want to be able to run commands against a context that I have access to but am not pointed to, while in another context.
How do I run a command, say $ kubectl get pods against context B while I'm currently pointed to context A?
--context is a global option for all kubectl commands. Simply run:
$ kubectl get pods --context <context_B>
For a list of all global kubectl options, run $ kubectl options
try this command
kubectl config set-context $(kubectl config current-context) --namespace=<namespace>
then run
kubectl get po
Related
I often run tasks like:
Read the log of the service X
or
Attach a shell inside the service Y
I always use something in my history like:
kubectl logs `kubectl get pods --no-headers -o custom-columns=":metadata.name" | grep <partial_name>`
or
kubectl exec -it `kubectl get pods --no-headers -o custom-columns=":metadata.name" | grep <partial_name>` bash
Do you know if kubectl has already something in place for this? Or should I create my own set of aliases?
Kubernetes instances are loosely coupled by the means of labels (key-value pairs). Because of that Kubernetes provides various functionalities that can help you to operate on sets of objects based on labels.
In case you have several pods of the same service good chances that they are managed by some ReplicaSet with the use of some specific label. You should see it if you run:
kubectl get pods --show-labels
Now for aggregating logs for instance you could use label selector like:
kubectl logs -l key=value
For more info please see: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/ .
added to my .zshconfig
sshpod () {
kubectl exec --stdin --tty `kubectl get pods --no-headers -o custom-columns=":metadata.name" | grep ${1} | head -n 1` -- /bin/bash
}
usage
sshpod podname
this
finds all pods
greps needed name
picks the first
sshs into the pod
You can go access a pod by its deployment/service/etc:
kubectl exec -it svc/foo -- bash
kubectl exec -it deployment/bar -- bash
Kubernetes will pick a pod that matches the criteria and send you to it.
You can enable shell autocompletion. Kubectl provides this support for Bash and Zsh which will save you a lot of typing (you will use TAB to get the suggestion/completion).
Kuberentes documentations has a great set of information about how to enable autocompletion under Optional kubectl configurations. It covers Bash on Linux, Bash on MacOS and Zsh.
I've created several resources using k8s Ansible module. Now I'd like to export the resources into Kubernetes manifests (so I don't need to use Ansible anymore). I've started by exporting a Service:
$ kubectl get svc myservice -o yaml --export > myservice.yaml
$ kubectl apply -f myservice.yaml
Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply
service/myservice configured
Why do I get the the warning? And why there's service/myservice configured and not service/myservice unchanged? Is there a better way to export resources?
You're doing right, don't worry about the warning.
If you want to get rid of it, you have to delete all the generation, selfLink and so on keys.
Yes, you are doing it right.
Let me show you small trick:
kubectl get svc myservice -o yaml --export | sed -e '/status:/d' -e '/creationTimestamp:/d' -e '/selfLink: [a-z0-9A-Z/]\+/d' -e '/resourceVersion: "[0-9]\+"/d' -e '/phase:/d' -e '/uid: [a-z0-9-]\+/d' > myservice.yaml
Will generate proper yaml file without status, creationTimestamp, selfLink, resourceVersion, phase and uid.
You get the warning because you're using kubectl apply on a resource that you previously created with kubectl create. If you create the initial Service with kubectl apply, you shouldn't get the warning.
The configured instead of unchanged might be because of some metadata or generated data that is also included in the output of kubectl get svc myservice -o yaml --export.
Consider a simple script:
kubectl create -f foo.yaml
kubectl expose deployment foo
There seems to be a race condition, and no way to guarantee that the context of the second command runs in the same context as the first. (Consider the user going to another shell and invoking kubectl config set-context while the script is running.) How do you resolve that? How can I ensure consistency?
I suggest to always use --context flag:
$ kubectl options | grep context
--context='': The name of the kubeconfig context to use
for each kubectl command in order to define a context and prevent an issue described in a question:
ENV=<env_name>
kubectl create --context=$ENV -f foo.yaml
kubectl expose --context=$ENV deployment foo
kubectl config view shows contexts and clusters corresponding to clusters that I have deleted.
How can I remove those entries?
The command
kubectl config unset clusters
appears to delete all clusters. Is there a way to selectively delete cluster entries? What about contexts?
kubectl config unset takes a dot-delimited path. You can delete cluster/context/user entries by name. E.g.
kubectl config unset users.gke_project_zone_name
kubectl config unset contexts.aws_cluster1-kubernetes
kubectl config unset clusters.foobar-baz
Side note, if you teardown your cluster using cluster/kube-down.sh (or gcloud if you use Container Engine), it will delete the associated kubeconfig entries. There is also a planned kubectl config rework for a future release to make the commands more intuitive/usable/consistent.
For clusters and contexts you can also do
kubectl config delete-cluster my-cluster
kubectl config delete-context my-cluster-context
There's nothing specific for users though, so you still have to do
kubectl config unset users.my-cluster-admin
Run command below to get all contexts you have:
$ kubectl config get-contexts
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
* Cluster_Name_1 Cluster_1 clusterUser_resource-group_Cluster_1
Delete context:
$ kubectl config delete-context Cluster_Name_1
Unrelated to question, but maybe a useful resource.
Have a look at kubectx + kubens: Power tools for kubectl.
They make it easy to switch contexts and namespace + have the option to delete
Change context:
kubectx dev-cluster-01
Change namespace:
kubens dev-ns-01
Delete context:
kubectx -d my-context
Is there something like:
kubectl get pods --project=PROJECT_ID
I would like not to modify my default gcloud configuration to switch between my staging and production environment.
kubectl saves clusters/contexts in its configuration. If you use the default scripts to bring up the cluster, these entries should've been set for your clutser.
A brief overview of kubectl config:
kubectl config view let you to view the cluster/contexts in
your configuration.
kubectl config set-cluster and kubectl config set-context modifies/adds new entries.
You can use kubectl config use-context to change the default context, and kubectl --context=CONTEXT get pods to switch to a different context for the current command.
You can download credentials for each of your clusters using gcloud container clusters get-credentials which takes the --project flag. Once the credentials are cached locally, you can use the --context flag (as Yu-Ju explains in her answer) to switch between clusters for each command.