Kubernetes/container-related standardization memo

The Kubernetes-based container orchestration system is not a monolithic monolithic system, but a combination of various ecosystem tools and the idea of microservices.

By defining a standard interface when combining various components such as storage and network as elements that form the entire system with Kubernetes (or container system), various players (vendors and OSS projects) can You will be able to flexibly create extended functions and link/provide them.

There are many such standard interfaces, specifications, and projects, so I will summarize some as a memorandum.

[1] CSI : Container Storage Interface

** Standard IF for extended persistent storage ** https://kubernetes-csi.github.io/

--Standards/API for exposing arbitrary blocks and file storage systems to containerized workloads on ** Container Orchestration Systems (CO) ** such as Kubernetes --CSI allows third-party storage providers to create and deploy plugins that expose new storage systems on Kubernetes without touching the core Kubernetes code. --Installing the CSI driver will support storage systems that Kubernetes does not natively support. --CSI allows you to use the latest storage features such as snapshots and resizing --Become GA with Kubernetes ** v1.13 **

reference)

https://cloud.google.com/anthos/gke/docs/on-prem/archive/1.2/how-to/install-csi-driver?hl=ja

Example: Amazon EKS x Amazon EFS

When using ** Amazon EFS ** (managed file system) from ** Amazon EKS ** Kubernetes cluster, install the CSI driver for EFS (kubectl apply or helm install) published on GitHub, and the Kubernetes cluster EFS storage is available directly from the pod above

--Reference URL - https://github.com/kubernetes-sigs/aws-efs-csi-driver - https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/efs-csi.html

[2] CNI : Container Network Interface

** Standard IF for container network connection ** https://github.com/containernetworking/cni

--Advocated by CoreOS and now a CNCF project --Consists of ** plugins ** that configure a network interface in a Linux container, and ** specifications and libraries ** for creating it. --CNI is responsible for connecting the container to the network and deleting the resources allocated when the container was deleted.

Typical CNI plugin

flannel（https://github.com/coreos/flannel）
Calico（https://www.projectcalico.org/）
Canal（https://github.com/projectcalico/canal）
Weave Net（https://www.weave.works/oss/net/）
etc.

Reference URL

https://rancher.com/blog/2019/2019-03-21-comparing-kubernetes-cni-providers-flannel-calico-canal-and-weave/

[3] SMI : Service Mesh Interface

** Kubernetes Standard IF for Service Meshes ** https://smi-spec.io/

--Standard interface of service mesh software jointly announced by Microsoft and HashiCorp --Examples of basic functions of the most common service mesh use cases -** Traffic policy : Policy settings such as encryption and authentication for traffic between services - Traffic telemetry : Get traffic-critical metrics such as error rates and latencies between services - Traffic management **: Traffic management such as switching traffic to services --SMI compatible service mesh plug-in example - Istio（https://github.com/servicemeshinterface/smi-adapter-istio） - linkerd（https://linkerd.io/） - Consul（https://www.consul.io/docs/connect） - etc.

reference) https://www.publickey1.jp/blog/19/hashicorpservice_mesh_interfacesmikubernetesapi.html

[4] CRI : Container Runtime Interface

** Standard IF for Kubernetes container runtime connection ** https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/

-Managed by ** CNCF ** --A plugin interface that allows kubelet to use different container runtimes without recompiling --CRI consists of protocol buffers, ** gRPC API **, and libraries --Example of High-Level container runtime supporting CRI - Docker(dockershim + containerd)（https://www.docker.com/） - containerd（https://containerd.io/） - CRI-O（https://cri-o.io/）

Docker (docker shim + containerd) has been deprecated since Kubernetes v1.20

[5] OCI : Open Container Initiative

** Container Image and Runtime Standard Initiatives ** https://opencontainers.org/

--One of the Linux Foundation projects --Established for the purpose of formulating standard specifications for container virtualization --There are two main specifications. -** Runtime Specification ** (runtime-spec): Container runtime and lifecycle specifications -** Image Specification ** (image-spec): Container image specification --Click here for High-level and Low-level runtimes - https://qiita.com/suzukihi724/items/d1dba5a2ed33d9c0d868

[6] Open Tracing

** Standard specifications for distributed tracing ** https://opentracing.io/

-Provide vendor-independent ** API specifications ** and ** libraries ** for ** distributed tracing ** --Library supported languages: Go, JavaScript, Java, Python, Ruby, PHP, Objective-C, C ++, C # --Open Tracing compatible distributed tracing tool example - Jager（https://www.jaegertracing.io/）

[7] Operator Hub

** Kubernetes Operator shared repository ** https://operatorhub.io/

--A repository service that allows you to search and share verified ** Kubernetes Operator **

What is Kubernetes Operator in the first place?

https://kubernetes.io/ja/docs/concepts/extend-kubernetes/operator/

--A framework for packaging, deploying, and managing primarily ** stateful ** applications (databases, etc.) on Kubernetes --For example, in the case of a database, it is necessary to implement management tasks such as backup, troubleshooting, cluster management, and monitoring, and the purpose is to automate such operations. --Based on the following Kubernetes API extensions -** CRD [Custom Resource Definitions] : Extend Kubernetes API to define your own resource [Custom Resource] - Custom Controller **: Declarative API for controlling Custom Resources

reference) https://qiita.com/MahoTakara/items/af4ad8ab69c24102bd72 https://www.redhat.com/ja/topics/containers/what-is-a-kubernetes-operator https://www.sraoss.co.jp/tech-blog/pgsql/kubernetes-postgres-operator/