KUBERNETES API



The REST API is the underlying makeup of Kubernetes. All operations and communications between components, and external user commands are REST API calls that the API Server handles. Consequently, everything in the Kubernetes platform is treated as an API object and has a corresponding entry in the API.


more

THE KUBERNETES API IS WHERE EVERYTHING IN KUBERNETES IS DEFINED.

EVERYTHING IS A RESOURCE THAT’S DEFINED IN THE API.
PODS, DEPLOYMENTS ETC ARE ALL RESOURCES.

IT'S A RESTFUL API THAT USES HTTPS METHODS OR VERBS TO PERFORM CRUD STYLE OPERATIONS.









ACCESS TO THE API HAPPENS THROUGH THE KUBECTL COMMAND LINE UTILITY

WE DEFINE THE DIFFERENT PARTS OF OUR APPLICATIONS IN YAML FILES AND THEN USE KUBECTL TO POST THEM TO THE API SERVER

AFTER AUTHENTICATION THERE WILL BE A RECORD OF INTENT THAT WILL BE CREATED ON THE CLUSTER THAT CHANGES THE OVERALL DESIRED STATE OF THE CLUSTER.

THAT THEN CAUSES THE OTHER COMPONENTS OF THE CONTROL PLANE TO TAKE ACTION.





THE KUBERNETES WAY OF DEPLOYING AND MANAGING APPLICATIONS IS TO DEFINE THE VARIOUS PARTS OF THOSE APPLICATIONS IN YAML FILES.

USING YAML FOR K8s DEFINITIONS GIVES YOU A NUMBER OF ADVANTAGES, INCLUDING:

* CONVENIENCE: YOU'LL NO LONGER HAVE TO ADD ADD
ALL YOUR PARAMETERS TO THE COMMAND LINE.

* MAINTENANCE: YAML FILES CAN BE ADDED TP SOURCE CONTROL, SO YOU CAN TRACK CHANGES.

* FLEXIBILITY: YOU'LL BE ABLE TO CREATE MUCH MORE COMPLEX STRUCTURES USING YAML THAN YOU CAN ON THE COMMAND LINE.



POSTING NEW YAML FILES CHANGES THE DESIRED STATE. BEFORE LONG THE CONTROL LOOPS WILL NOTICE AND VARIOUS PARTS OF THE CONTROL PLANE WILL KICK IN TO LIFE TO BRING THE OBSERVED STATE IN TO LINE WITH THE NEW DESIRED STATE.










FOR EXAMPLE THERE IS A CLUSTER WITH 10 RUNNING REPLICASE OF A SERVICE THAT CONVERTS FILES. IF YOU POST AN UPDATED YAML FILE TO THE CLUSTER CHANGING THE DESIRED STATE TO 20 REPLICAS INSTEAD OF 10 THE CURRENT OBSERVED STATE WILL BE OUT OF SYNC WITH THE NEW DESIRED STATE. WATCH LOOPS WILL NOTICE AND START TO RECONCILE. THE YAML FILES ARE YOUR SOURCE OF ACCURACY AND SERVES AS A LIVING APPLICATION DOCUMENTATION.







MONOLITHIC APPLICATIONS USED TO HAVE MANY APIs IN ONE PLACE. AS KUBERNETES GREW IT BECAME A HUGE HEADACHE TRYING TO DEVELOP MANY INDIVIDUAL RESOURCES IN A SINGLE MONLITHIC API, SO THEY BROKE IT APART AND CREATED A NUMBER OF API GROUPS.

NOW THERE ARE A NUMBER OF DIFFERENT API GROUPS.

THE WORKLOAD APIs LIKE DEPLOYMENTS, REPLICA SETS, AND DAEMON SETS ARE IN THE APPS API GROUP.
ROLE BASED ACCESS CONTROLS ARE IN THEIR OWN AUTHORIZATION GROUP. THERE ARE MANY GROUPS EACH WITH THEIR OWN RESOURCES



EACH OF THESE API GROUPS IS TAKEN CARE OF BY A SPECIAL INTEREST GROUP (SIG) WHO ARE A GROUP OF PEOPLE WHO ARE RESPONSIBLE FOR FEATURE DEVELOPMENT. FOR EXAMPLE SIG APPS OWNS THE
THE APPS API.

THE PROJECT IS COMPRISED OF THE FOLLOWING TYPES OF SUBGROUPS:
* SPECIAL INTEREST GROUPS, SIGs
SUBPROJECTS
* WORKING GROUPS, WGs
* COMMITTEES
* USER GROUPS

https://github.com/kubernetes/community/blob/master/sig-list.






RESOURCES LIVE IN API GROUPS AND EACH API GROUP IS VERSIONED. THE RELEASE CYCLE COMES IN THREE STAGES:

1.) ALPHA - FEATURES ARE DISABLED BY DEFAULT.
USE CAUTION.
APHA SHOULD NOT BE TRUSTED.

2.) BETA - FEATURES ARE FAIRLY STABLE AND WOULD
LOOK PRETTY MUCH THE SAME AS WHEN THEY GO TO
GENERAL AVAILABILITY.

3.) GENERAL AVAILABILITY (GA) - THE FEATURE SET IS
STABLE AND CONSIDERED READY FOR PRODUCTION.