Ola Habr!
A finais de verán queremos lembrarvos que seguimos traballando o tema 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. , e nos últimos dous anos a súa popularidade creceu tanto que está constantemente clasificado entre 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 , e dende 2002 – espazos de nomes. Os contedores foron deseñados aínda mellor en 2008, cando estivo dispoñible , e Google desenvolveu o seu propio mecanismo corporativo interno chamado , 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 , 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: 80Esta 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 , validador YAML/JSON, ademais , un validador de políticas para garantir que o contexto 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 , 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 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 para 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 .
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. é un proceso especial no clúster de Kubernetes que funciona segundo o "" 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 - e . 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-operatorIsto 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.goDespois 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=MyAppServiceDespois, 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 , permítelle crear declaracións usando só ficheiros YAML declarativos. Por exemplo, un operador para Apache Kafka definiríase aproximadamente . 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 kafkaE 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 .
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 .
Tamén hai varias comunidades (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 , que, xunto cos SIG, revisa novos e existentes 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 , que é un dos principais na actualidade. Xa existen marcos avanzados, p. и , 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
