Kube API and CRDs


k api-resources

- Name
- Short name
- API version
- Namespaced (Boolean)
- Kind
- Verbs

k api-versions

* API not managed by controller
SubjectAccessReview It represent operation on object

* Kind has set of versions. All Kind are organized in group.

* We have multiple versions for a Kind

1. served version: List of versions available in API

2. Decodable version: Kube-API server knows how to decode that version. We can create object for specific kind with version x and retrieve object for same kind, with version y. When version change, schema also change. Kube-API server does schema conversion. 

3. storage version = encodable version: as per etcd

4. We can get preferred version with
k get --raw /apis/GROUP
For Example:
k get --raw /apis/networking.k8s.io

kubectl request with preferred version

* (1) Kube-API server (2) kube clients e.g. kubectl (3) client-go maintains mapping of resource types (e.g. pods) and kind (Pod) . Then REST end point is constructed as follows

- /apis/GROUP/VERSION/RESOURCE/NAME to get a cluster-scoped object
- /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME to access a namespace-scoped object.

Without specifying NAME, we get KindList (e.g. ServiceList)

* Along with CRD, we define:
- group, kind, resource type
- versions: served version, storage version (used at etcd), decodable version, preferred version generally same as storage version. 
- namespace scoped or cluster scoped. This is scope for object, not for API. 
- URL endpoint

* Verbs

- get, list : GET
- watch : GET ....?watch=
- create, update: PUT
- patch: PATCH

* Generated values
- name : If generatedName is set
- creationTimestamp
- deletionTimestamp
- UID
- resourceVersion
- Any field set by mutating webhook
- port, IP for service object

Reference

0 comments:

Post a Comment