Hello, Habr!
At the end of summer, we want to remind you that we continue to work on the topic and have decided to publish an article from Stack Overflow, showcasing the state of affairs in this project as of early June.
Happy reading!
As of the writing of this article, Kubernetes is about , and in the last two years, its popularity has grown so much that it consistently ranks among the platforms. This year, Kubernetes holds third place. Reminder: Kubernetes is a platform designed for running and orchestrating containerized workloads.
Containers originated as a special construct for isolating processes in Linux; since 2007, they include , and since 2002 – namespaces. Containers were better defined by 2008, when became available, and Google developed its internal mechanism called , where "all work is done in containers." Now, let’s jump to 2013, when the first Docker release took place, and containers finally transitioned into popular mass solutions. At that time, the primary tool for orchestrating containers was , although it wasn't wildly popular. The first Kubernetes release was in 2015, after which this tool became the de facto standard in container orchestration.
To try to understand why Kubernetes is so popular, let's attempt to answer a few questions. When was the last time developers reached an agreement on how to deploy applications to production? How many developers do you know who use tools in the way they are provided "out of the box"? How many cloud administrators today do not understand how applications work? We will address the answers to these questions in this article.
Infrastructure as YAML
In a world that has transitioned from Puppet and Chef to Kubernetes, one of the biggest changes has been the shift from "infrastructure as code" to "infrastructure as data" — specifically, as YAML. All resources in Kubernetes, including pods, configurations, deployed instances, volumes, etc., can be easily described in a YAML file. For example:
apiVersion: v1
kind: Pod
metadata:
name: site
labels:
app: web
spec:
containers:
- name: front-end
image: nginx
ports:
- containerPort: 80With this approach, DevOps or SRE specialists can fully express their workloads without the need to write code in languages like Python or JavaScript.
Other advantages of organizing infrastructure as data include the following:
- GitOps or version control for Git Operations. This approach allows all Kubernetes YAML files to be stored in git repositories, enabling you to precisely track when a change was made, who made it, and what exactly was changed. This increases operational transparency across the organization and enhances work efficiency by eliminating ambiguity, especially regarding where employees should look for the resources they need. At the same time, it becomes easier to automatically make changes to Kubernetes resources through a regular pull request merge.
- Scalability. When resources are defined in YAML, it becomes extremely easy for cluster operators to change one or two numbers in a Kubernetes resource, thereby altering its scaling principles. Kubernetes has a mechanism for horizontal pod autoscaling, allowing you to specify the minimum and maximum number of pods required in a given deployed configuration to handle low and high traffic levels. For example, if you deployed a configuration that needs additional power due to a sudden spike in traffic, you can change the maxReplicas from 10 to 20.
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: myapp
namespace: default
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: myapp-deployment
minReplicas: 1
maxReplicas: 20
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50- Security and management. YAML is great for assessing how certain things are deployed in Kubernetes. For example, a significant security concern is whether your workloads are running under a user without administrative rights. In this case, tools such as , a YAML/JSON validator, plus , a policy validator that ensures the context the workload does not allow the container to run with administrator privileges. If this is required, users can apply a simple policy , like this:
package main
deny[msg] {
input.kind = "Deployment"
not input.spec.template.spec.securityContext.runAsNonRoot = true
msg = "Containers must not run as root"
}- Integration options with cloud providers. One of the most notable trends in modern high technology is to run workloads on the resources of public cloud providers. Using a component Kubernetes allows any cluster to integrate with the cloud provider on which it runs. For example, if a user launches an application in Kubernetes on AWS and wants to expose it via a service, the cloud provider helps automatically create a service
LoadBalancer, which will automatically provide a load balancer , to direct traffic to the application pods.
Scalability
Kubernetes scales very well, which is appreciated by developers. There is a set of available resources such as pods, deployments, StatefulSets, secrets, ConfigMaps, etc. However, users and developers can also add other resources in the form of .
For example, if we want to define a resource CronTab, we could do something like this:
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: crontabs.my.org
spec:
group: my.org
versions:
- name: v1
served: true
storage: true
schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
properties:
cronSpec:
type: string
pattern: '^(d+|*)(/d+)?(s+(d+|*)(/d+)?){4}$'
replicas:
type: integer
minimum: 1
maximum: 10
scope: Namespaced
names:
plural: crontabs
singular: crontab
kind: CronTab
shortNames:
- ct
Later we can create a CronTab resource approximately like this:
apiVersion: "my.org/v1"
kind: CronTab
metadata:
name: my-cron-object
spec:
cronSpec: "* * * * */5"
image: my-cron-image
replicas: 5
Another scalability option in Kubernetes is that the developer can write their own operators. – is a special process in the Kubernetes cluster that operates on the "" pattern. With an operator, a user can automate the management of CRDs (custom resource definitions), exchanging information with the Kubernetes API.
There are several tools in the community that allow developers to easily create their own operators. Among them is and its . This SDK provides a foundation upon which a developer can quickly start creating an operator. For example, you can start from the command line like this:
$ operator-sdk new my-operator --repo github.com/myuser/my-operatorThis generates all the boilerplate code for your operator, including YAML files and Go code:
.
|____cmd
| |____manager
| | |____main.go
|____go.mod
|____deploy
| |____role.yaml
| |____role_binding.yaml
| |____service_account.yaml
| |____operator.yaml
|____tools.go
|____go.sum
|____.gitignore
|____version
| |____version.go
|____build
| |____bin
| | |____user_setup
| | |____entrypoint
| |____Dockerfile
|____pkg
| |____apis
| | |____apis.go
| |____controller
| | |____controller.goThen you can add the necessary API and controller like this:
$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService
$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppServiceAfter that, finally build the operator and push it to your container registry:
$ operator-sdk build your.container.registry/youruser/myapp-operator If the developer requires even more control, they can modify the boilerplate code in the Go files. For example, to change the specifics of the controller, you can make edits in the file controller.go.
Another project, , allows you to create operators using only declarative YAML files. For instance, an operator for Apache Kafka would be defined something like . With it, you can install a Kafka cluster on top of Kubernetes with just a couple of commands:
$ kubectl kudo install zookeeper
$ kubectl kudo install kafkaAnd then configure it with another command:
$ kubectl kudo install kafka --instance=my-kafka-name
-p ZOOKEEPER_URI=zk-zookeeper-0.zk-hs:2181
-p ZOOKEEPER_PATH=/my-path -p BROKER_CPUS=3000m
-p BROKER_COUNT=5 -p BROKER_MEM=4096m
-p DISK_SIZE=40Gi -p MIN_INSYNC_REPLICAS=3
-p NUM_NETWORK_THREADS=10 -p NUM_IO_THREADS=20
Innovations
In recent years, major Kubernetes releases have come out every few months—three to four major releases a year. The number of new features implemented in each one continues to grow. Moreover, there are no signs of slowing down even in our challenging times—just look at the current .
New capabilities allow for more flexible clustering operations with a variety of workloads. Additionally, developers appreciate having more comprehensive control when deploying applications directly in production.
The community
Another significant aspect of Kubernetes' popularity lies in the strength of its community. In 2015, upon reaching version 1.0, Kubernetes was sponsored .
There are also various communities (special interest groups) aimed at addressing various areas of Kubernetes as the project evolves. These groups continuously add new features, making working with Kubernetes increasingly convenient.
The Cloud Native Foundation also hosts CloudNativeCon/KubeCon, which, at the time of writing, is the largest open-source conference in the world. Typically held three times a year, it gathers thousands of professionals eager to enhance Kubernetes and its ecosystem, as well as to explore new opportunities emerging every three months.
Moreover, within the Cloud Native Foundation, there is a , which, together with SIGs, evaluates new and existing projects focused on the cloud ecosystem. Most of these projects help improve the strengths of Kubernetes.
Finally, I believe Kubernetes would not have achieved such success without the conscious efforts of the entire community, where people support one another but are also happy to welcome newcomers.
The Future
One of the main challenges developers will face in the future is the ability to focus on the details of the code itself, rather than on the infrastructure it operates in. This trend is addressed by the , which is now one of the leading paradigms. Advanced frameworks already exist, such as and , which leverage Kubernetes to abstract infrastructure from the developer.
In this article, we only briefly touched on the current state of Kubernetes – in reality, this is just the tip of the iceberg. Users of Kubernetes have many other resources, capabilities, and configurations at their disposal.
Source: habr.com
