For pod we keep it v1
When replicaset we keep it apps/v1.
Question is apps/v1 contains all the objects of v1 as well or what's the hierarchy? Can someone please explain ?
The apiVersion is composed of two components: thegroup and the version.
The version indicates the levels of stability and support: if version contains alpha, the software may contains bugs and the feature may be dropped in future release; if version contains beta, the feature is considered tested, and is enabled by default - the feature will not be dropped but some details may change.
The group have been introduced to ease development and maintenance of k8s. The API group is also specified in REST path when accessing the k8s API. The full list of groups is located: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#-strong-api-groups-strong-
So there is no hierarchy between v1 and apps/v1.
The first API resources introduced in Kubernetes do not have groups. So you will use the apiVersion: v1.
Later resources are linked to a group. For examples, Jobs and CronJobs are both in the group batch. So their apiVersion will be batch/v1. Deployments and replicasets are in the apps group, and are using apiVersion: apps/v1.
You can obtain all api-resources using the command : kubectl api-resources
See also: https://kubernetes.io/docs/reference/using-api/#api-groups
Related
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.
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.
Kubernetes versions:
v1.15.2
Scenario shows：
kubernetes v1.15.2 have added some new api versions,for example, the autoscaling/v2beta2 in the autoscaling group. But after read the HorizontalController structure in kubernetes code src\k8s.io\kubernetes\pkg\controller\podautoscaler\, All the members in HorizontalController is autoscaling/v1.
type HorizontalController struct {
scaleNamespacer scaleclient.ScalesGetter ==> autoscaling/v1
hpaNamespacer autoscalingclient.HorizontalPodAutoscalersGetter ==> autoscaling/v1
mapper apimeta.RESTMapper
replicaCalc *ReplicaCalculator
eventRecorder record.EventRecorder
downscaleStabilisationWindow time.Duration
// hpaLister is able to list/get HPAs from the shared cache from the informer passed in to
// NewHorizontalController.
hpaLister autoscalinglisters.HorizontalPodAutoscalerLister ==> autoscaling/v1
hpaListerSynced cache.InformerSynced ==> autoscaling/v1
// podLister is able to list/get Pods from the shared cache from the informer passed in to
// NewHorizontalController.
podLister corelisters.PodLister
podListerSynced cache.InformerSynced
// Controllers that need to be synced
queue workqueue.RateLimitingInterface
// Latest unstabilized recommendations for each autoscaler.
recommendations map[string][]timestampedRecommendation
}
So how kubernetes maintans the autoscaling/v2beta2 resources with HorizontalController?
In the official kubernetes documentation You can find following information:
API Object
The Horizontal Pod Autoscaler is an API resource in the Kubernetes autoscaling API group. The current stable version, which only includes support for CPU autoscaling, can be found in the autoscaling/v1 API version.
The beta version, which includes support for scaling on memory and custom metrics, can be found in autoscaling/v2beta2. The new fields introduced in autoscaling/v2beta2 are preserved as annotations when working with autoscaling/v1.
More details about the API object can be found at HorizontalPodAutoscaler Object.
Also according to kubernetes documentation about API overview under API versioning:
API versioning
To eliminate fields or restructure resource representations,
Kubernetes supports multiple API versions, each at a different API
path. For example: /api/v1 or /apis/extensions/v1beta1.
The version is set at the API level rather than at the resource or
field level to:
Ensure that the API presents a clear and consistent view of system resources and behavior.
Enable control access to end-of-life and/or experimental APIs.
The JSON and Protobuf serialization schemas follow the same guidelines
for schema changes. The following descriptions cover both formats.
So You can find all apis versions for autoscaling like v2beta2 under kubernetes/pkg/apis/autoscaling/ .
For example using HTTP GET would be like this: GET /apis/autoscaling/v2beta2
After some intense google and SO search i couldn't find any document that mentions both rolling update and set image, and can stress the difference between the two.
Can anyone shed light? When would I rather use either of those?
EDIT: It's worth mentioning that i'm already working with deployments (rather than replication controller directly) and that I'm using yaml configuration files. It would also be nice to know if there's a way to perform any of those using configuration files rather than direct commands.
In older k8s versions the ReplicationController was the only resource to manage a group of replicated pods. To update the pods of a ReplicationController you use kubectl rolling-update.
Later, k8s introduced the Deployment which manages ReplicaSet resources. The Deployment could be updated via kubectl set image.
Working with Deployment resources (as you already do) is the preferred way. I guess the ReplicationController and its rolling-update command are mainly still there for backward compatibility.
UPDATE: As mentioned in the comments:
To update a Deployment I used kubectl patch as it could also change things like adding new env vars whereas kubectl set image is rather limited and can only change the image version. Also note, that patch can be applied to all k8s resources and is not restricted to be used with a Deployment.
Later, I shifted my deployment processes to use helm - a really neat and k8s native package management tool. Can highly recommend to have a look at it.
Following the docs to create a Deployment, I have a .yaml file like this:
apiVersion: extensions/v1beta1
kind: Deployment
...
I wasn't sure what to make of the "extensions/v1beta1", so I ended up here in the API docs.
That makes it sound like I should use a value of "v1", but that doesn't seem to be valid when I try to kubectl apply my .yaml file.
Could someome help me to better understand what the apiVersion values mean and how I can determine the best value to use for each component?
Oh, and I'm using minikube and "kubectl version" reports that client and server are "GitVersion:"v1.3.0".
The docs you linked to are from before the release of Kubernetes 1.0 (a year ago). At that time, we had beta versions of the API and were migrating to the v1 API. Since then, we have introduced multiple API groups, and each API group can have a different version. The version indicates the maturity of the API (alpha is under active development, beta means it will have compatibility/upgradability guarantees, and v1 means it's stable). The deployment API is currently in the second category, so using extensions/v1beta1 is correct.
from documentation suggested by #Vern DeHaven
extensions/v1beta1
This version of the API includes many new, commonly used features of Kubernetes. Deployments, DaemonSets, ReplicaSets, and Ingresses all received significant changes in this release.
Note that in Kubernetes 1.6, some of these objects were relocated from extensions to specific API groups (e.g. apps). When these objects move out of beta, expect them to be in a specific API group like apps/v1.
Using extensions/v1beta1 is becoming deprecated—try to use the specific API group where possible, depending on your Kubernetes cluster version.