Kube API and CRDs
k api-resources
- Name
- Short name
- API version
- Namespaced (Boolean)
- Kind
- Verbs
- 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