Sobre a crecente popularidade de Kubernetes

Ola Habr!

A finais de verán queremos lembrarvos que seguimos traballando o tema Kubernetes e decidiu publicar a principios de xuño un artigo de Stackoverflow que demostra o estado de cousas deste proxecto.

Goza de lectura!

No momento de escribir este artigo, a idade de Kubernetes é de aprox. seis anos, e nos últimos dous anos a súa popularidade creceu tanto que está constantemente clasificado entre máis favorito plataformas. Kubernetes ocupa o terceiro lugar este ano. Para recapitular: Kubernetes é unha plataforma deseñada para executar e orquestrar cargas de traballo en contenedores.

Os contedores comezaron como un deseño especial para illar procesos en Linux; contedores inclúense desde 2007 cgroups, e dende 2002 – espazos de nomes. Os contedores foron deseñados aínda mellor en 2008, cando estivo dispoñible LXC, e Google desenvolveu o seu propio mecanismo corporativo interno chamado Borg, onde "todo o traballo faise en contedores". A partir de aquí avanzamos ata 2013, cando tivo lugar o primeiro lanzamento de Docker, e os contedores convertéronse finalmente nunha solución masiva popular. Nese momento, a principal ferramenta para a orquestración de contedores era Mesos, aínda que non era moi popular. Kubernetes lanzouse por primeira vez en 2015, despois de que esta ferramenta converteuse no estándar de facto no campo da orquestración de contedores.

Para tentar entender por que Kubernetes é tan popular, imos tentar responder a algunhas preguntas. Cando foi a última vez que os desenvolvedores puideron poñerse de acordo sobre como implementar aplicacións en produción? Cantos desenvolvedores coñeces que usan as ferramentas xa que se proporcionan de forma inmediata? Cantos administradores na nube hai hoxe que non entenden como funcionan as aplicacións? Veremos as respostas a estas preguntas neste artigo.

Infraestrutura como YAML

No mundo que pasou de Puppet and Chef a Kubernetes, un dos maiores cambios foi o paso de "infraestrutura como código" a "infraestrutura como datos", en concreto, como YAML. Todos os recursos de Kubernetes, que inclúen pods, configuracións, instancias despregadas, volumes, etc., pódense describir facilmente nun ficheiro YAML. Por exemplo:

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

Esta vista facilita aos profesionais de DevOps ou SRE expresar plenamente as súas cargas de traballo sen ter que escribir código en linguaxes como Python ou Javascript.

Outras vantaxes de organizar a infraestrutura como datos inclúen:

• Control de versión de GitOps ou Git Operations. Este enfoque permítelle manter todos os ficheiros YAML de Kubernetes en repositorios git, para que poida rastrexar exactamente cando se fixo un cambio, quen o fixo e que cambiou exactamente. Isto aumenta a transparencia das operacións en toda a organización e mellora a eficiencia operativa eliminando a ambigüidade, especialmente sobre onde os empregados deben buscar os recursos que necesitan. Ao mesmo tempo, faise máis doado facer automaticamente cambios nos recursos de Kubernetes simplemente fusionando unha solicitude de extracción.
• Escalabilidade. Cando os recursos se definen como YAML, para os operadores do clúster é moi sinxelo cambiar un ou dous números nun recurso de Kubernetes, cambiando así a súa escala. Kubernetes ofrece un mecanismo para a escala automática horizontal dos pods, que se pode usar para determinar convenientemente cal é o número mínimo e máximo de pods necesarios nunha determinada configuración de implantación para xestionar niveis de tráfico baixos e altos. Por exemplo, se implantou unha configuración que require capacidade adicional debido a un aumento repentino de tráfico, maxReplicas pódese cambiar de 10 a 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

• Seguridade e xestión. YAML é excelente para avaliar como se implementan as cousas en Kubernetes. Por exemplo, un problema de seguranza importante é saber se as túas cargas de traballo se están executando como un usuario non administrador. Neste caso, é posible que necesitemos ferramentas como concurso, validador YAML/JSON, ademais Abre axente de políticas, un validador de políticas para garantir que o contexto SecurityContext as túas cargas de traballo non permiten que o contedor se execute con privilexios de administrador. Se é necesario, os usuarios poden aplicar unha política sinxela Eu rezo, como isto:

package main

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

• Opcións para a integración cun provedor de nube. Unha das tendencias máis notables da alta tecnoloxía actual é executar cargas de traballo en provedores de nube pública. Usando o compoñente provedor de nube Kubernetes permite que calquera clúster se integre co provedor de nube no que se executa. Por exemplo, se un usuario executa unha aplicación en Kubernetes en AWS e quere expor esa aplicación a través dun servizo, o provedor na nube axuda a crear o servizo automaticamente LoadBalancerque proporcionará automaticamente o equilibrador de carga Amazon Elastic Load Balancerpara redirixir o tráfico aos módulos de aplicacións.

Ampliabilidade

Kubernetes é moi extensible e aos desenvolvedores encántalle. Hai un conxunto de recursos dispoñibles, como pods, despregamentos, StatefulSets, segredos, ConfigMaps, etc. É certo que os usuarios e desenvolvedores poden engadir outros recursos no formulario definicións de recursos personalizados.

Por exemplo, se queremos definir un recurso CronTab, entón podes facer algo como isto:

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

Máis tarde podemos crear un recurso CronTab algo así:

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

Outra opción de extensibilidade en Kubernetes é que o desenvolvedor poida escribir as súas propias declaracións. Operador é un proceso especial no clúster de Kubernetes que funciona segundo o "circuíto de control" Coa axuda dun operador, o usuario pode automatizar a xestión de CRD (definicións de recursos personalizadas) intercambiando información coa API de Kubernetes.

Existen varias ferramentas na comunidade que facilitan aos desenvolvedores a creación dos seus propios operadores. Entre eles - Marco do operador e SDK do operador. Este SDK proporciona unha base desde a que un programador pode comezar a crear rapidamente un operador. Digamos que pode comezar desde a liña de comandos algo así:

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

Isto crea todo o código estándar para o teu operador, incluídos os ficheiros YAML e o código Golang:

.
|____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

Despois podes engadir as API e o controlador necesarios, como este:

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

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

Despois, finalmente, reúne o operador e envíao ao rexistro do teu contedor:

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

Se o programador quere aínda máis control, pódese cambiar o código estándar dos ficheiros Go. Por exemplo, para modificar as características específicas do controlador, pode facer cambios no ficheiro controller.go.

Outro proxecto En todas partes, permítelle crear declaracións usando só ficheiros YAML declarativos. Por exemplo, un operador para Apache Kafka definiríase aproximadamente así. Con el, podes instalar un clúster de Kafka encima de Kubernetes con só un par de comandos:

$ kubectl kudo install zookeeper
$ kubectl kudo install kafka

E despois configúrao con outro comando:

$ 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

Innovación

Durante os últimos anos, as principais versións de Kubernetes saíron cada poucos meses, é dicir, de tres a catro lanzamentos importantes ao ano. O número de novidades introducidas en cada unha delas non diminúe. Ademais, non hai sinais de desaceleración mesmo nestes tempos difíciles: mira cal é a situación agora Actividade do proxecto Kubernetes en Github.

As novas capacidades permítenche agrupar operacións de forma máis flexible en diversas cargas de traballo. Ademais, os programadores gozan dun maior control ao despregar aplicacións directamente na produción.

Comunidade

Outro aspecto importante da popularidade de Kubernetes é a forza da súa comunidade. En 2015, ao chegar á versión 1.0, Kubernetes foi patrocinado por Fundación Cloud Native Computing.

Tamén hai varias comunidades SIX (Grupos de Interese Especial) centrados en traballar en diferentes áreas de Kubernetes a medida que o proxecto evoluciona. Estes grupos engaden constantemente novas funcións, o que fai que traballar con Kubernetes sexa máis cómodo e cómodo.

A Cloud Native Foundation tamén acolle CloudNativeCon/KubeCon, que, no momento de escribir este artigo, é a maior conferencia de código aberto do mundo. Adoita celebrarse tres veces ao ano, reúne a miles de profesionais que queren mellorar Kubernetes e o seu ecosistema, así como coñecer novas funcións que aparecen cada tres meses.

Ademais, Cloud Native Foundation ten Comisión Técnica de Supervisión, que, xunto cos SIG, revisa novos e existentes proxectos fondos centrados no ecosistema da nube. A maioría destes proxectos axudan a mellorar os puntos fortes de Kubernetes.

Finalmente, creo que Kubernetes non sería tan exitoso como sen os esforzos conscientes de toda a comunidade, onde a xente se mantén unida pero ao mesmo tempo acolle aos recén chegados ao redil.

Futuro

Un dos principais retos aos que terán que enfrontarse os desenvolvedores no futuro é a capacidade de centrarse nos detalles do propio código, e non na infraestrutura na que se executa. Cumpre con estas tendencias paradigma arquitectónico sen servidor, que é un dos principais na actualidade. Xa existen marcos avanzados, p. Knativo и OpenFaas, que usan Kubernetes para abstraer a infraestrutura do programador.

Neste artigo, só raiamos a superficie do estado actual de Kubernetes; de feito, é só a punta do iceberg. Os usuarios de Kubernetes teñen moitos outros recursos, capacidades e configuracións á súa disposición.

Fonte: www.habr.com