Is there a easy way to list all kubernetes objects related to an API version?
Lets say, API version apps/v1beta1 is getting deprecated and I want to know if I have any objects in my cluster using this version, how can I find such objects?
you can do something similar like this
kubectl get pod -o=custom-columns=NAME:.metadata.name,API-version:.metadata.owner_references[].api_version
by using kubectl just print respective data and api version
The reason I asked this question was that I was upgrading my kubernetes cluster from v1.15 to v1.16 and this brings a lot of breaking changes
The kubepug tool allowed me to easily find a list of resources that I need to change to be able to upgrade seamlessly from 1.15 to 1.16
Edit:
Another alternative is pluto command line tool to get information about resources which might have deprecated or removed API versions. This is helpful specially if you use helm extensively since pluto can look at helm state.
To list Kubernetes resource versions use this command:
kubectl api-resources
And if the you know what resource you are searching for then just filter it from the list using grep:
kubectl api-resources | grep the_resource_name_you_want
In the below example we search for the api version of 'persistentvolumes' resource:
kubectl api-resources | grep persistentvolumes
Result:
deployments deploy apps/v1 true Deployment
There are additional options to get the resource version:
Use the official documentation:
The official and updated with the newest versions is in the Kubernetes API documentation
The left navigation bar lists the resources, click on one & the version is the first row of the page.
Related
Instead of navigating a namespace via e.g. :service, then :pod etc, I would like to see everything that's in the namespace in a single view. As if you would type kubectl -n argocd get all.
Can't find the info in the docs. Is this even possible?
Thanks for any suggestion!
Posting community wiki answer based on GitHub topic - Show multiple resource types without having to switch. Feel free to expand it.
That's true, there is no information about this in the documentation because simply there is no such possibility. There is open issue with this request on the GitHub page of k9s:
Is your feature request related to a problem? Please describe.
Oftentimes I'm watching/working on multiple resource types at the same time and it's very helpful to not have to switch from one to another. This is something very like kubectl get pod,deploy,... or kubectl get-all commands allows
Describe the solution you'd like
Being able to see multiple or all resources in the same screen without having to switch between resource types like:
:pod,configmap shows all pods & configmaps in the current namespace
or
:all shows all resources in the current namespace (get-all like)
Last pinged November 4 2021.
You can try
kubectl get all -n argocd -o yaml
or
kubectl get all -n argocd -o json
to list all common resources in a particular namespace
Note: It will not list the CRD or other custom resources like helm
We are developing k8s CSI driver
Currently in order to upgrade driver we delete the installed operator pods, cdrs and roles and recreate them from new version images.
What is suggested way to do upgrade? Or is uninstall/install is the suggested method?
I couldn't find any relevant information
We also have support of installing from OpenShift. Is there any difference regarding upgrade from OpenShift?
You should start from this documentation:
This page describes to CSI driver developers how to deploy their
driver onto a Kubernetes cluster.
Especially:
Deploying a CSI driver onto Kubernetes is highlighted in detail in
Recommended Mechanism for Deploying CSI Drivers on Kubernetes.
Also, you will find there all the necessary info with an example.
Your question lacks some details regarding your use case but I strongly recommend starting from the guide I have presented you.
Please, let me know if that helps.
CSI drivers can differ, but I believe the best approach is to do rolling update of your plugin's DaemonSet. It will happen automatically once you apply the new DaemonSet configuration, e.g. newer docker image.
For more details, see https://kubernetes.io/docs/tasks/manage-daemon/update-daemon-set/
For example:
kubectl get -n YOUR-NAMESPACE daemonset YOUR-DAEMONSET --export -o yaml > plugin.yaml
vi plugin.yaml # Update your image tag(s)
kubectl apply -n YOUR-NAMESPACE -f plugin.yaml
A shorted way to update just the image:
kubectl set image ds/YOUR-DAEMONSET-NAME YOUR-CONTAINER-NAME=YOUR-IMAGE-URL:YOUR-TAG -n YOUR-NAMESPACE
Note: I found that I also needed to restart (kill) the pod with the external provisioner. There's probably a more elegant way to handle this, but it works in a pinch.
kubectl delete pod -n YOUR-NAMESPACE YOUR-EXTERNAL-PROVISIONER-POD
First off, I'm completely new with Kubernetes so I may have missed something completely obvious but the documentation is exactly helping, so I'm turning to you guys for help.
I'm trying to figure out just how many types of "deployment files" there are for Kubernetes. I call them "deployment files" because I really don't know what else to call them and they're usually associated with a deployment.
So far, every yml/yaml file I've seen start like this:
apiVersion:
kind: << this is what I'm asking about >>
metadata:
And so far I have seen this many "kind"(s)
ClusterConfig
ClusterRole
ClusterRoleBinding
CronJob
Deployment
Job
PersistentVolumeClaim
Pod
ReplicationController
Role
RoleBinding
Secret
Service
ServiceAccount
I'm sure there are many more. But I can't seem to find a location where they are listed and the contexts broken down.
So what I want to know is this,
Where can I find an explanation for these yaml files?
Where can I learn about the different kinds?
Where can I get a broken down explanation of the minimum required fields/values are for any of these?
Are there templates for these files?
Thanks
This question will need a blog to answer but still in short you can try these options and command to learn from your kubectl CLI.
Learn to use kubectl explain command which shows you a list of Kubernetes objects:
$ kubectl explain
You can get detailed information about any of listed resources using this syntax
`$ kubectl explain pod
$ kubectl explain pod.spec
$ kubectl explain pod.spec.containers`
Or you can get yam template of the object by adding --recursive flag to explain command.
$ kubectl explain pod --recursive
This will also give you official document link.
So in short running kubectl explain with recursive option will list every thing.
When you are talking about specific yaml file containing the definition of specific kubernetes object, you can call them yaml manifests or simply yaml definition files. Using word Deployment for all of them isn't a good idea as there is already specific resource type defined and called by this name in kubernetes. So it's better you don't call them all deployments for consistency.
I'm sure there are many more. But I can't seem to find a location
where they are listed and the contexts broken down.
Yes, there are a lot more of them and you can list those which are available by running:
kubectl api-resources
These different objects are actually called api-resources. As you can see they are listed in three columns: NAME, SHORTNAMES, APIGROUP, NAMESPACED and KIND
NAME SHORTNAMES APIGROUP NAMESPACED KIND
bindings true Binding
componentstatuses cs false ComponentStatus
configmaps cm true ConfigMap
endpoints ep true Endpoints
events ev true Event
limitranges limits true LimitRange
namespaces ns false Namespace
nodes no false Node
Note that the name of resource corresponds to its KIND but it is slightly different. NAME simply describes resource types as we are referring to them e.g. using kubectl command line utility. Just to give one example, when you want to list pods available in your cluster you simply type kubectl get pods. You don't have to use resource kind i.e. Pod in this context. You can but you don't have to. So kubectl get Pod or kubectl get ConfigMap will also return desired result. You can also refer to them by their shournames so kubectl get daemonsets and kubectl get ds are equivalent.
It's totally different when it comes to specific resource/object definition. In context of yaml definition file we must to use proper KIND of the resource. They are mostly start with capital letter and are written by co called CamelCase but there are exceptions from this rule.
I really recommend you to familiarize with kubernetes documentation. It is very user-friendly and nicely explains both key kubernetes concepts as well as all very tiny details.
Here you have even more useful commands for exploring API resources:
kubectl api-resources --namespaced=true # All namespaced resources
kubectl api-resources --namespaced=false # All non-namespaced resources
kubectl api-resources -o name # All resources with simple output (just the resource name)
kubectl api-resources -o wide # All resources with expanded (aka "wide") output
kubectl api-resources --verbs=list,get # All resources that support the "list" and "get" request verbs
kubectl api-resources --api-group=extensions # All resources in the "extensions" API group
As #wargre already suggested in his comment, kubernetes official documentetion is definitely the best place to start as you will find there very detailed description of every resource.
Understanding Kubernetes Objects
You may start from reading this article: Understanding Kubernetes Objects
Kubernetes Objects are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster. Specifically, they can describe:
What containerized applications are running (and on which nodes)
The resources available to those applications
The policies around how those applications behave, such as restart policies, upgrades, and fault-tolerance
A Kubernetes object is a “record of intent”–once you create the object, the Kubernetes system will constantly work to ensure that object exists. By creating an object, you’re effectively telling the Kubernetes system what you want your cluster’s workload to look like; this is your cluster’s desired state.
K8s API reference
A detailed description of all objects can be found in the Kubernetes API reference guide.
One of the points in the kubectl best practices section in Kubernetes Docs state below:
Pin to a specific generator version, such as kubectl run
--generator=deployment/v1beta1
But then a little down in the doc, we get to learn that except for Pod, the use of --generator option is deprecated and that it would be removed in future versions.
Why is this being done? Doesn't generator make life easier in creating a template file for resource definition of deployment, service, and other resources? What alternative is the kubernetes team suggesting? This isn't there in the docs :(
kubectl create is the recommended alternative if you want to use more than just a pod (like deployment).
https://kubernetes.io/docs/reference/kubectl/conventions/#generators says:
Note: kubectl run --generator except for run-pod/v1 is deprecated in v1.12.
This pull request has the reason why generators (except run-pod/v1) were deprecated:
The direction is that we want to move away from kubectl run because it's over bloated and complicated for both users and developers. We want to mimic docker run with kubectl run so that it only creates a pod, and if you're interested in other resources kubectl create is the intended replacement.
For deployment you can try
kubectl create deployment hello-node --image=gcr.io/hello-minikube-zero-install/hello-node
and
Note: kubectl run --generator except for run-pod/v1 is deprecated in v1.12.
I have a kubectl which version is 1.8.0 and a kubernetes cluster which version is 1.7.4. Using this kubectl to request the kubernetes cluster will be wrong for some cases like applying an CronJob yaml file.
I have searched a lot but could not find a way to use a higer version kubectl to request a lower version kubernetes cluster.
For Docker, I could set DOCKER_API_VERSION to be compatible with the server API for the docker client. So for kubernetes, is there a similar to do this?
kubectl apply in particular has no ability to switch versions of a resource (it embeds a particular version in an annotation and must deal with that version forever).
For general fetching of resources, you can fully qualify the API group and version of resource you request from the server:
# no qualification, defaults to preferred server group and version
kubectl get deployments
# group qualification, defaults to preferred server version of that group
kubectl get deployments.extensions
kubectl get deployments.apps
# fully qualified resource.version.group
kubectl get deployments.v1beta1.extensions
kubectl get deployments.v1beta1.apps
kubectl get deployments.v1beta2.apps
Yes, there is a option like that in my kubectl version 1.6.6.
kubectl options
--api-version='': DEPRECATED: The API version to use when talking to the server
It was deprecated though. I guess this option has been deleted in 1.8.0
IMO, simply install the lower version kubectl, use it with the lower version cluster.
kubectl is a single file application, we can have multiple versions co-exist.
curl -L https://storage.googleapis.com/kubernetes-release/release/v1.7.4/bin/linux/amd64/kubectl -o kubectl-1.7