Does the annotate feature actually work for the v1beta1 recaptcha enterprise endpoint?
The reCAPTCHA Enterprise REST reference shows the v1beta1 endpoint includes the ability to annotate assessments, but the guides say "Some features, such as the Annotation API are available only for the v1 API" and the annotating documentation only shows the v1 url.
Alternatively, is it possible to use the v1 endpoint to annotate assessments that were created with the v1beta1 endpoint?
We may not be able to use service accounts for authentication, so are just wanting to confirm our options if we can only use the v1beta1 endpoint with API keys.
Yes, you can annotate assessments using the v1beta1 endpoint. You can also mix and match, and annotate assessments created with v1beta1 using the v1 annotate API.
Related
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
When an application needs to call events API to get all events of its cluster, as a programmer I may define a role like this:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
resources: ["events"]
verbs: ["list"]
What makes me confusing is the apiGroups part, I can use "events.k8s.io", or simply "", or "events.k8s.io" and "" both...
What is this apiGroups thing? I tried to read official documentation but all I found is this:
API groups make it easier to extend the Kubernetes API. The API group is specified in a REST path and in the apiVersion field of a serialized object.
There are several API groups in Kubernetes:
The core (also called legacy) group is found at REST path /api/v1. The core group is not specified as part of the apiVersion field, for example, apiVersion: v1.
The named groups are at REST path /apis/$GROUP_NAME/$VERSION and use apiVersion: $GROUP_NAME/$VERSION (for example, apiVersion: batch/v1). You can find the full list of supported API groups in the Kubernetes API reference.
This doesn't help me understand it... Why there are named groups and core groups, why I can use "" and "events.k8s.io" together?
If my resource is events, why do I need to explicitly tell K8s that there is an API group named "events.k8s.io" as if the events in "events.k8s.io" and events in resources are two different things...
This question had been haunting me for daysðŸ˜
Why there are named groups and core groups
The reason is historical. Kubernetes first considered some resources part of a core group, meaning the core of Kubernetes is constituted by these resources (resources in the core group includes Pods, Events).
The purposes of the named API groups (or namespaces) (such as events.k8s.io) is to group resources by thematic. You'll have networking.k8s.io for resources related to networking.
The "core" resources were considered such an integral part of Kubernetes that they did not need a group (I'm simplifying).
why I can use "" and "events.k8s.io" together?
If my resource is events, why do I need to explicitly tell K8s that there is an API group named "events.k8s.io" as if the events in "events.k8s.io" and events in resources are two different things...
The API is not exactly the same. In the API reference you can see that in the events.k8s.io you can see some field staring with deprecated which are deprecated field(s) assuring backward compatibility with core.v1 Event type. So depending on which endpoint you use, the API semantic is not exactly the same (but Kubernetes has mechanisms to translate from one version to the other). Since some tools might rely on the core v1 version and not yet have migrated to events.k8s.io/v1, both need to exists.
There has been other "group migration" of that sort, notably from the extensions group to other group (Ingress migrated to networking.k8s.io, Deployment to apps)
It has to do with Kubernetes controllers & CustomResourceDefinition.
When you write an operator for Kubernetes, you would define custom objects. For example, Elastic (www.elastic.co) has an operator deploying ElasticSearch/Kibana. They decided to call one of their object "elasticsearch".
Those resource names are arbitrary, and nothing guarantee there won't be someone else, working on its own operator, using the same names. Thus, when you define your custom resources, you would also affect them with an API group.
The API group is also arbitrary, though would usually identify a unique controller/operator/set of functionality. In the case of the ElasticSearch operator, they went with an API group "k8s.elastic.co". When installing this operator CRD on your cluster, a kubectl get crd would list objects such as "elasticsearchs.k8s.elastic.co", "kibanas.k8s.elastic.co".
You could very well deploy another operator, which implements its own "elasticsearch" or "kibana" objects, within its own API group.
Thus, when you write your Roles / ClusterRoles, that apiGroup field is crucial configuring your RBAC. The resources array lists short names, the apiGroup is then used resolving the fully qualified CRD name.
While kubernetes legacy objects use some empty string, other native objects may use networking.k8s.io, batch, extensions, ... In the meantime, custom controllers would all use their own api group, whenever they rely on their own CRDs.
Now, I'm not sure I know the answer to 'why I can use "" and "events.k8s.io" together?'. I would say it's historic?
I did not see any cases where setting multiple api groups in a rule was benefic. In my opinion, it's misleading, a source of mistake, ... when you find a rule with two api groups, you can be pretty sure the person who wrote it did not understand what they were doing.
At best, one combination of apigroup / resource grants what you meant to. Worst case, one combination of apigroup / resource grants something you did not want to allow in the first place.
Erratum: events are an exception, though. As pointed out in some kubernetes GitHub Issue ( https://github.com/kubernetes/kubernetes/issues/94857 ), some member would argue this is not a bug: we really need both API groups. Which is kind of surprising.
Not sure why would that be. Sidenote, the schema for Event in core/v1 and events.k8s.io isn't the same:
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#event-v1-events-k8s-io
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#event-v1-core
So they're not the same object strictly speaking, although from what I can see, they return the same data / in terms of etcd, it's the same data, with two JSON representations depending on which api group you query:
$ k get event.events.k8s.io -n kube-system
LAST SEEN TYPE REASON OBJECT MESSAGE
58m Warning Unhealthy pod/metrics-server-7df46996d8-c5wf5 Readiness probe failed: Get "https://10.233.108.212:8443/healthz": context deadline exceeded
...
$ k get event -n kube-system
LAST SEEN TYPE REASON OBJECT MESSAGE
58m Warning Unhealthy pod/metrics-server-7df46996d8-c5wf5 Readiness probe failed: Get "https://10.233.108.212:8443/healthz": context deadline exceeded
...
Not sure what's the rational here. events.k8s.io isn't anything new, I haven't read about some transition from one to the other ... That's a good question you have.
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
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
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.