Hai moita literatura de referencia en Internet, pero ás veces o consello máis sinxelo é o máis valioso. Equipo traducido , que o autor do artigo recolleu tras un ano de traballo con Kubernetes. Os consellos non están ordenados por importancia, pero pensamos que cada un atopará algo útil para si mesmo.
O comando máis sinxelo para traballar con Kubernetes
Para comezar, quizais a acción máis sinxela e útil para traballar con Kubernetes. O seguinte comando permite completar o comando kubectl en bash shell:
echo "source <(kubectl completion bash)" >> ~/.bashrc
Completamento automático kubectl escribirase no ficheiro .bashrc e activarase automaticamente cada vez que se inicie o shell. Isto acelera a escritura de comandos longos e parámetros como all-namespaces. Ler máis en .
Límites de memoria e CPU predeterminados nun espazo de nomes
Se a aplicación está escrita incorrectamente, por exemplo, abre unha nova conexión á base de datos cada segundo pero nunca a pecha, entón o clúster ten unha fuga de memoria. E se a aplicación non ten un límite de memoria establecido durante a implantación, isto pode provocar un fallo do nodo.
Para evitar isto, Kubernetes permítelle establecer restricións predeterminadas por espazo de nomes. Escríbense no ficheiro yaml para un espazo de nomes específico. Aquí tes un exemplo deste tipo de ficheiros:
apiVersion: v1
kind: LimitRange
metadata:
name: mem-limit-range
spec:
limits:
- default:
memory: 512Mi
defaultRequest:
memory: 256Mi
type: Container
Crea ese yaml e aplícao a calquera espazo de nomes. Por exemplo, ao espazo de nomes limit-example. Agora calquera contedor despregado neste espazo de nomes terá un límite de 512 Mi, a non ser que se estableza outro límite individual para este contedor.
Recollida de lixo en versións antigas de Kubernetes
Kubelet inicia por defecto a recollida de lixo cando var/lib/docker ocupa o 90% do espazo dispoñible no disco. Isto é xenial, non obstante, ata Kubernetes 1.7 non había un límite predeterminado no número de inodos utilizados, que corresponden ao número de ficheiros do sistema de ficheiros.
Potencialmente o teu recipiente var/lib/docker pode usar só o 50% do espazo do disco, pero pode quedar sen inodos, o que causará problemas aos traballadores.
Nas versións anteriores de kubelet da 1.4 á 1.6 terás que engadir esta bandeira:
--eviction-hard
=memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%
En versións 1.7 e posteriores esta bandeira está definida por defecto. Non obstante, as versións anteriores non controlan o límite do inodo.
Minikube... pequeno pero poderoso Kubernetes local
Minikube é a forma máis sinxela de executar un clúster local de Kubernetes. Lanzase cun comando sinxelo:
minikube start
Ao executar este comando, un clúster de Kubernetes real se executa no teu ordenador.
O truco é como construír a aplicación e executala localmente nese clúster. A menos que se indique especificamente, a imaxe de Docker crearase no teu ordenador e non no clúster.
Para forzar a Docker a enviar a imaxe ao clúster local de Kubernetes, a máquina docker recibe o seguinte comando:
eval $(minikube docker-env)
Agora podemos crear aplicacións nun clúster de Kubernetes local.
Non deas acceso a kubectl a todos
Isto parece obvio, pero se varios equipos están usando o mesmo clúster para as súas aplicacións (que é para o que se creou Kubernetes), non deberías darlle a todos kubectl. É mellor separar os comandos, asignando a cada un deles o seu propio espazo de nomes e limitando o acceso mediante políticas RBAC.
Pódese confundir asignando dereitos para acceder, ler, crear, eliminar e outras operacións para cada pod. Pero o principal é limitar o acceso aos segredos, permitíndoo só aos administradores. Deste xeito diferenciaremos entre os que poden administrar o clúster e os que simplemente poden implantar nel.
Xestionar os orzamentos de pod
Como garantir que non hai tempo de inactividade para unha aplicación nun clúster de Kubernetes? PodDisruptionBudget e de novo PodDisruptionBudget.
Os clústeres actualízanse periodicamente e os nodos baléranse. Nada se queda parado, esa é a realidade. Cada implementación con máis dunha instancia debe incluír un PDB (PodDisruptionBudget). Créase nun ficheiro yaml sinxelo que se aplica ao clúster. A área de cobertura dun PDB particular está determinada polos selectores de etiquetas.
Nota: O orzamento do PPB só se ten en conta cando a infracción orzamentaria é reversible (). En situacións como fallos de hardware, PDB non funcionará.
Exemplo de PDB:
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: app-a-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: app-a
Os dous parámetros principais son matchLabels и minAvailable. O primeiro parámetro especifica a que aplicacións se aplica o orzamento. Por exemplo, se teño implementacións con etiquetas app: app-a и app: app-b, entón este PDB só se aplicará ao primeiro.
Parámetro minAvailable tido en conta ao baleirar (limpar) o nodo. Por exemplo, no noso exemplo, durante o baleirado, todas as instancias son desafiuzadas app: app-a, excepto dous.
Isto permítelle controlar cantas instancias da aplicación deberían executarse nun momento dado.
Seguimento da saúde da aplicación
Este seguimento é posible de dúas formas: mediante probas de Preparación ou Liveness.
A primeira sonda (preparación) determina a disposición do contedor para recibir tráfico.
O segundo (vivencia) mostra se o recipiente está saudable ou se debe reiniciar.
As configuracións relevantes simplemente engádense ao yaml para a súa implantación. Alí podes especificar tempos de espera, tempos de atraso e o número de reintentos. Consulta máis detalles sobre eles .
As etiquetas están en todas partes
As etiquetas son un dos conceptos fundamentais en Kubernetes. Permiten que os obxectos se comuniquen libremente entre si, así como crear consultas baseadas en etiquetas. En Kubernetes, incluso podes ir ao cliente e ver eventos de etiquetas específicas.
Podes facer case calquera cousa con etiquetas, pero un bo exemplo sería crear varios ambientes para executar programas no mesmo clúster.
Digamos que usa o mesmo clúster para dev и qa. Isto significa que podes ter unha aplicación app-a, traballando simultaneamente en ambos ambientes qa и dev. Neste caso, podemos acceder por separado á instancia da aplicación nun ambiente específico especificando o parámetro axeitado environment. Por exemplo app: app-a и environment: dev para un ambiente, e app: app-a и environment: qa para o segundo.
Isto permítelle acceder a ambas as instancias da aplicación, por exemplo, para realizar probas simultaneamente.
Organízate
Kubernetes é un sistema moi potente, pero calquera sistema pode quedar atascado con demasiados procesos. O Kubelet executa todos os procesos e comprobacións que especifique, así como os propios.
Por suposto, un servizo orfo non ralentizará o sistema e Kubernetes está deseñado para escalar desde cero. Pero se en lugar dun servizo aparece un millón, o kubelet comeza a atragantarse.
Se por algún motivo eliminas unha implementación (contedor, imaxe, o que sexa), asegúrate de facer unha limpeza completa.
Coñece Go
Gardamos o consello principal para o final. Aprende a linguaxe de programación Go.
Kubernetes desenvólvese en Go, todas as extensións están escritas en Go e tamén se admite oficialmente a biblioteca cliente cliente-go.
Pódese usar para cousas diferentes e interesantes. Por exemplo, para ampliar o sistema Kubernetes ao teu gusto. Así, podes usar os teus propios programas para recoller datos, implementar aplicacións ou simplemente limpar contedores.
Aprender a linguaxe de programación Go e dominar client-go é quizais o consello máis importante que podes dar aos novos usuarios de Kubernetes.
Que máis ler:
- .
- ?
- .
Fonte: www.habr.com