What is Kubernetes API?
The Kubernetes API is being used to read and write Kubernetes resource objects via a Kubernetes API endpoint. The Kubernetes API serves as the foundation for the declarative configuration schema for the system. The kubectl command-line tool can be used to create, update, delete, and get API objects.
Kubernetes also stores its serialized state (currently in etcd) in terms of the API resources.
Primary functions of Kubernetes resources
Following are the basic types of resources provided by the Kubernetes API and their primary functions.
- Workloads – Workloads are objects you use to manage and run your containers on the cluster.
- Discovery & LB – Discovery & LB resources are objects you use to “stitch” your workloads together into an externally accessible, load-balanced Service.
- Config & Storage – Config & Storage resources are objects you use to inject initialization data into your applications, and to persist data that is external to your container.
- Cluster – Cluster resources objects define how the cluster itself is configured; these are typically used only by cluster operators.
- Metadata – Metadata resources are objects you use to configure the behavior of other resources within the cluster, such as HorizontalPodAutoscaler for scaling workloads.
Kubernetes resources objects Components?
Each resource objects typically have 3 components:
- ResourceSpec: This is defined by the user and describes the desired state of system. Fill this in when creating or updating an object.
- ResourceStatus: This is filled in by the server and reports the current state of the system. Only kubernetes components should fill this in
- Resource ObjectMeta: This is metadata about the resource, such as its name, type, api version, annotations, and labels. This contains fields that maybe updated both by the end user and the system (e.g. annotations)
Kubernetes resource Operations
Most resources provide the following Operations:
- Create:
- Update:
- Replace:
- Patch:
- Read
- Get:
- List:
- List All Namespaces:
- Watch:
- Delete
- Additional Operations
- Rollback:
- Read / Write Scale:
- Read / Write Status:
Kubernetes resources – WORKLOADS
Worloads resources are responsible for managing and running your containers on the cluster. Containers are created by Controllers through Pods. Pods run Containers and provide environmental dependencies such as shared or persistent storage Volumes and Configuration or Secret data injected into the container.
The most common Controllers are:
- Deployments for stateless persistent apps (e.g. http servers)
- StatefulSets for stateful persistent apps (e.g. databases)
- Jobs for run-to-completion apps (e.g. batch jobs).
Kubernetes resources – DISCOVERY & LOAD BALANCING
Discovery and Load Balancing resources are responsible for stitching your workloads together into an accessible Loadbalanced Service. By default, Workloads are only accessible within the cluster, and they must be exposed externally using a either a LoadBalancer or NodePort Service. For development, internally accessible Workloads can be accessed via proxy through the api master using the kubectl proxy command.
Common resource types:
- Services for providing a single ip endpoint loadbalanced across multiple Workload replicas.
- Ingress for providing a https(s) endpoint http(s) routed to one or more Services
Kubernetes resources – CONFIG & STORAGE
Config and Storage resources are responsible for injecting data into your applications and persisting data externally to your container.
Common resource types:
- ConfigMaps – ConfigMaps for providing text key value pairs injected into the application through environment variables, command line arguments, or files
- Secrets – Secrets for providing binary data injected into the application through files
- Volumes – Volumes for providing a filesystem external to the Container. Maybe shared across Containers within the same Pod and have a lifetime persisting beyond a Container or Pod.
Kubernetes resources – METADATA
Metadata resources are responsible for configuring behavior of your other Resources within the Cluster.
Common resource types:
- HorizontalPodAutoscaler (HPA) – HorizontalPodAutoscaler (HPA) for automatically scaling the replicacount of your workloads in response to load
- PodDisruptionBudget – PodDisruptionBudget for configuring how many replicas in a given workload maybe made concurrently unavailable when performing maintenance.
- ThirdPartyResource – ThirdPartyResource for extending the Kubernetes APIs with your own types
- Event – Event for notification of resource lifecycle events in the cluster.
Kubernetes resources – CLUSTER
Cluster resources are responsible for defining configuration of the cluster itself, and are generally only used by cluster operators.
How Kubernetes API works?
When you use the Kubernetes API to create the object (either directly or via kubectl), that API request must include that information as JSON in the request body. Most often, you provide the information to kubectl in a .yaml file. kubectl converts the information to JSON when making the API request.
Before Kubernetes 1.10
The Kubernetes apiserver (aka “master”) exposes an API that can be used to retrieve the Swagger v1.2 Kubernetes API spec located at /swaggerapi.
Starting with Kubernetes 1.10
OpenAPI spec is served in a single /openapi/v2 endpoint.
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.
Alpha level: The version names contain alpha (e.g. v1alpha1).
Beta level: The version names contain beta (e.g. v2beta3).
Stable level: The version name is vX where X is an integer.
Note –
The format-separated endpoints (/swagger.json, /swagger-2.0.0.json, /swagger-2.0.0.pb-v1, /swagger-2.0.0.pb-v1.gz) are deprecated and will get removed in Kubernetes 1.14
API groups
To make it easier to extend the Kubernetes API, Kubernetes implemented API groups. The API group is specified in a REST path and in the apiVersion field of a serialized object. Currently there are several API groups in use:
1. The core group, often referred to as the legacy group, is at the REST path /api/v1 and uses apiVersion: v1.
2. The named groups are at REST path /apis/$GROUP_NAME/$VERSION, and use apiVersion: $GROUP_NAME/$VERSION (e.g. apiVersion: batch/v1).
Enabling API groups
Certain resources and API groups are enabled by default. They can be enabled or disabled by setting –runtime-config on apiserver. –runtime-config accepts comma separated values.
For ex: to disable batch/v1, set –runtime-config=batch/v1=false, to enable batch/v2alpha1, set –runtime-config=batch/v2alpha1. The flag accepts comma separated set of key=value pairs describing runtime configuration of the apiserver.
What is OpenAPI & Swagger?
OpenAPI 3.0 is the first official release of the specification since it was donated to the OpenAPI Initiative by SmartBear Software and renamed from the Swagger Specification to OpenAPI specification in 2015. This year marked the official release of OpenAPI 3.0, the latest version of the OpenAPI specification.
Difference Between Swagger and OpenAPI?
The easiest way to understand the difference is:
- OpenAPI = Specification
- Swagger = Tools for implementing the specification
The OpenAPI is the official name of the specification. The development of the specification is fostered by the OpenAPI Initiative, which involves more the 30 organizations from different areas of the tech world — including Microsoft, Google, IBM, and CapitalOne. Smartbear Software, which is the company that leads the development of the Swagger tools, is also a member of the OpenAPI Initiative, helping lead the evolution of the specification.
Swagger is the name associated with some of the most well-known, and widely used tools for implementing the OpenAPI specification. The Swagger toolset includes a mix of open source, free, and commercial tools, which can be used at different stages of the API lifecycle.
Very Good Articles which must be referred here
https://swagger.io/blog/api-strategy/difference-between-swagger-and-openapi/
Examples of getting OpenAPI spec
| Before 1.10 | Starting with Kubernetes 1.10 |
|---|---|
| GET /swagger.json | GET /openapi/v2 Accept: application/json |
| GET /swagger-2.0.0.pb-v1 | GET /openapi/v2 Accept: application/com.github.proto-openapi.spec.v2@v1.0+protobuf |
| GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 Accept: application/com.github.proto-openapi.spec.v2@v1.0+protobuf Accept-Encoding: gzip |
- DevOps Certified Professionals (DCP)
- Site Reliability Engineering Certified Professionals (SRECP)
- Master in DevOps Engineering (MDE)
- DevSecOps Certified Professionals (DSOCP)
URL - https://www.devopsschool.com/certification/
My Linkedin - https://www.linkedin.com/in/rajeshkumarin
- Best AI tools for Software Engineers - November 4, 2024
- Installing Jupyter: Get up and running on your computer - November 2, 2024
- An Introduction of SymOps by SymOps.com - October 30, 2024
