How kubernetes maintains different api version resource? - kubernetes

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

Related

Create kubernetes events using kubernetes event api

I am pretty new in the kubernetes field, and have specific interest in kubernetes eventing. What I did was creating a K8 cluster, assign PODs to that cluster, and type kubectl get events command to see the corresponding events. Now for my work, I need to explore how can I create an K8 event resource using the eveting API provided here, so that using the kubectl get events command I can see the event stored in etcd. But as I mentioned I don't know K8 that deep, I'm struggling to make this api work.
N.B. I had a look into knative eventing, but seems to be the eventing feature Knative provides, is different than the K8 eveting, as I can't see the Knative events in the kubectl get events command. (please correct me if I am wrong).
Thanks in advance.
Usually events are created in Kubernetes as a way of informing of relevant status changes of an object.
Creating an event is as simple as:
kubectl apply -f - <<EOF
apiVersion: v1
kind: Event
metadata:
name: myevent
namespace: default
type: Warning
message: 'not sure if this what you want to do'
involvedObject:
kind: someObject
EOF
But usually this is done programmatically, using the Kubernetes client library of your choice and the core (v1) API group.
Knative Eventing is platform that enables Event Driven architectures, which does not seems related to your question, but if it were, you can find all getting started docs here:
Installation: https://knative.dev/docs/install/yaml-install/eventing/install-eventing-with-yaml/
Getting started: https://knative.dev/docs/eventing/getting-started/
Maybe this could be helpfull to. Knative have this concepts of "Event Sources" that already exists and serves as links for events for certain producers and sinks.
In the case of the K8's events API there is one called the APIServer Source: https://knative.dev/docs/eventing/sources/apiserversource/
A bit more about Event Sources here: https://knative.dev/docs/eventing/sources/

Kubernetes : Use of apiVersion in container manifest file

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

kubernetes specification for autoscaling/v2beta2

In this blog here: https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details
There is a blurb:
For object metrics and external metrics, a single metric is fetched, which describes the object in question. This metric is compared to the target value, to produce a ratio as above. In the autoscaling/v2beta2 API version, this value can optionally be divided by the number of pods before the comparison is made.
I need to do exactly this; divide my current metric by the current number of pods.
Where can I find the specification for this API? I have googled frantically to see what the autoscaling yaml specification is to do this but I cannot find it. IE I need to write the autoscaler resource as part of our helm chart.
The specification for k8s API can be found here: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/
The above is for k8s version 1.18, you'll have to switch to the right version for you.
The spec for HPA v2beta2 would be here: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#horizontalpodautoscaler-v2beta2-autoscaling

coordination.k8s.io api in GKE

I'm trying the leader-election code example provided with the go client (here) in a GKE cluster v1.13.7.
That requires a resource of type Lease of groupVersion coordination.k8s.io/v1 but there isn't. I know that Lease has been promoted to v1 in k8s 1.14 (not yet available with gke), but I expected to find the v1beta1 version.
Try with
kubectl proxy
curl -X GET localhost:8001/apis/coordination.k8s.io
and I get
404 page not found
Although the feature is v1 in 1.14, GKE has not incorporated this feature yet.
Since GKE is a fully managed product, the eng team decide which features to incorporate I to the GKE offering.
I recommend opening a feature request through the Google Public Issue Tracker and provide your use case for the feature to have integrated in future releases

apiVersion and beta versions

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.