programming kubernetes chapter 2 - kube api server [43939030]

http interface provides 4 structures:

1. Kinds

   • Type of entity, each object has a kind

   • usually 3 categories of kinds

     1. objects -> a persistent entity within the system
     2. lists -> 1 or more kinds
     3. special purpose -> for special actions, like status

2. API Group

   • collection of kinds that are logically related
   • like /apis/core

3. Version

   • each API group can (and likely does) exist as multiple versions
   • All objects are either in one API version or none

4. Resource

   • lowercase, plural word that identifies a set of HTTP endpoints

     • usually sends and receives a single kind
     • can have subrouses, usually implemented with custom HTTP protocols like websockets
   • always corresponds to an HTTP path

• Group Version Resource (GVR)

  • Uniquely identifies a HTTP path

• Group Version Kind (GVK)

  • what a GVR returns

• api/v1 exists outside of apis as a legacy holdover, should be apis/core/v1
• cluster wide entities have different values, such as /metrics, /logs, and /healthz

• specs vs status

  • specifications - desired state for a resource
  • status - observed state for a resource

Each API group has a specific handler, and there are 6 different phases internally

1. Entry
2. Authn/authz
3. mutation admission -> this is where the incoming request can be transformed
4. schema validation
5. validating admission -> large part of the validation logic
6. etcd