Clever Geek Handbook

On the growing popularity of Kubernetes

Hello, Habr!



At the end of the summer, we want to remind you that we are continuing to work on the Kubernetes topic and decided to publish an article on Stackoverflow demonstrating the state of affairs in this project at the beginning of June.







Enjoy reading!



At the time of this writing, Kubernetes is about six years old , and has grown in popularity so much over the past two years that it has consistently ranked among the most favored platforms. Kubernetes is in third place this year. As a reminder, Kubernetes is a platform for running and orchestrating containerized workloads.



Containers originated as a special construct for process isolation in Linux; containers have been cgroups since 2007 and namespaces since 2002. The containers took shape even better by 2008, when LXC became available , and Google developed its own internal mechanism called Borg.where “all work is done in containers”. From here, fast forward to 2013, when the first release of Docker took place, and containers finally moved to the category of popular mass solutions. At that time, Mesos was the main tool for orchestrating containers , although it was not very popular. The first release of Kubernetes took place in 2015, after which this tool became the de facto standard in the field of container orchestration.



To try to understand why Kubernetes is so popular, let's try to answer a few questions. When was the last time developers were able to agree on how to deploy applications to production? How many developers do you know use tools as they are provided out of the box? How many cloud administrators are there today who don't understand how applications work? We will consider the answers to these questions in this article.



Infrastructure as YAML



In the world that has gone from Puppet and Chef to Kubernetes, one of the biggest changes has been the move from infrastructure as code to infrastructure as data - specifically like YAML. All resources in Kubernetes, which include pods, configurations, deployed instances, volumes, etc., can be easily described in a YAML file. For instance: 



apiVersion: v1
kind: Pod
metadata:
  name: site
  labels:
    app: web
spec:
  containers:
    - name: front-end
      image: nginx
      ports:
        - containerPort: 80


This view makes it easier for DevOps or SREs to fully express their workloads without having to write code in languages ​​such as Python or Javascript.



Other advantages of organizing infrastructure as data, in particular, are as follows:



  • GitOps Git Operations Version. YAML- Kubernetes git, , , , . , , , , . , Kubernetes – pull-.
  • . YAML, Kubernetes, . Kubernetes , , , , . , , - , maxReplicas 10 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




package main

deny[msg] {
  input.kind = "Deployment"
  not input.spec.template.spec.securityContext.runAsNonRoot = true
  msg = "Containers must not run as root"
}






Kubernetes is very extensible and developers love it. There is a collection of resources available, such as pods, sweeps,, StatefulSetssecrets ConfigMaps, etc. However, users and developers can add other resources in the form of custom resource definitions .



For example, if we wanted 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 something like this: 



apiVersion: "my.org/v1"
kind: CronTab
metadata:
  name: my-cron-object
spec:
  cronSpec: "* * * * */5"
  image: my-cron-image
  replicas: 5


Another option for extensibility in Kubernetes is that the developer can write their own operators. An operator is a special process in a Kubernetes cluster that operates in a " control loop " pattern . With the help of an operator, the user can automate the management of CRDs (custom resource definitions) by exchanging information with the Kubernetes API.



There are several tools in the community that make it easy for developers to create their own operators. Among them are the Operator Framework and its Operator SDK . This SDK provides a framework from which a developer can very quickly start creating a statement. Let's say you can start from the command line something like this: 



$ operator-sdk new my-operator --repo github.com/myuser/my-operator




This creates all the stereotyped code for your operator, including the YAML files and Golang 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.go


Then you can add the API and controller you want, like this: 



$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService

$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppService


Then, finally, collect the operator and send it to the registry of your container: 



$ operator-sdk build your.container.registry/youruser/myapp-operator


If the developer needs even more control, then you can change the stereotyped code in the files to Go. For example, to modify the specifics of the controller, you can make changes to the file controller.go.



Another project, KUDO , allows you to create statements using only declarative YAML files. For example, an operator for Apache Kafka would be defined like this . 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 kafka




And 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


Innovation



Over the past few years, major Kubernetes releases have been released every few months - that is, three to four major releases per year. The number of new features implemented in each of them does not decrease. Moreover, there are no signs of slowing down even in our difficult times - look at the current activity of the Kubernetes project on Github .



New capabilities allow you to more flexibly cluster operations across a variety of workloads. Plus, programmers like more control when deploying applications directly to production.



Community



Another major aspect of Kubernetes' popularity is the strength of its community. In 2015, upon reaching version 1.0, Kubernetes was sponsored by the Cloud Native Computing Foundation .



There are also a variety of SIG (Special Interest Groups) communities that focus on different areas of Kubernetes as the project evolves. These teams are constantly adding new capabilities to make working with Kubernetes more convenient and convenient.



The Cloud Native Foundation also hosts CloudNativeCon / KubeCon, which is the largest open source conference in the world at the time of this writing. Typically, it is held three times a year and brings together thousands of professionals who want to improve Kubernetes and its ecosystem, as well as master new features that appear every three months.



Moreover, the Cloud Native Foundation has a Technical Oversight Committee , which, in conjunction with SIGs, reviews new and existing projects of the foundation focused on the cloud ecosystem. Most of these projects help improve the strengths of Kubernetes.



Finally, I believe that Kubernetes would not have had such success without the deliberate efforts of the entire community, where people cling to each other, but at the same time, gladly welcome newcomers into their ranks.



Future



One of the main challenges that developers will have to deal with in the future is the ability to focus on the details of the code itself, rather than the infrastructure in which it operates. It is to these trends that the serverless architecture paradigm , which is one of the leading today, responds . There are already advanced frameworks like Knative and OpenFaas that use Kubernetes to abstract the infrastructure away from the developer.



In this article, we've only taken a rough look at the current state of Kubernetes - in fact, this is just the tip of the iceberg. Kubernetes users have many other resources, capabilities, and configurations at their disposal.


More articles:


All Articles