Salut, Habr !
À la fin de l'été, nous tenons à rappeler que nous continuons à travailler sur le sujet et avons décidé de publier un article de Stackoverflow, démontrant l'état d'avancement de ce projet au début de juin.
Bonne lecture !
Au moment de la rédaction de cet article, l'âge de Kubernetes est d'environ , et au cours des deux dernières années, sa popularité a tellement augmenté qu'il figure constamment parmi les Cette année, Kubernetes se classe au troisième rang. Rappelons que Kubernetes est une plateforme destinée à exécuter et orchestrer des charges de travail conteneurisées.
Les conteneurs sont nés comme une construction spéciale pour l'isolation des processus dans Linux ; depuis 2007, ils incluent , et depuis 2002, des espaces de noms. Les conteneurs se sont bien développés d'ici 2008, lorsque est devenu disponible, et chez Google, ils ont développé un mécanisme interne appelé , où « tout le travail se déroule dans des conteneurs ». Revenons en 2013, lorsque le premier lancement de Docker a eu lieu, et les conteneurs ont finalement été adoptés comme des solutions populaires de masse. À cette époque, l'outil principal pour l'orchestration des conteneurs était , bien qu'il n'ait pas connu un succès incroyable. Le premier lancement de Kubernetes a eu lieu en 2015, après quoi cet outil est devenu de facto le standard en matière d'orchestration des conteneurs.
Pour tenter de comprendre pourquoi Kubernetes est si populaire, essayons de répondre à quelques questions. Quand les développeurs ont-ils réussi pour la dernière fois à s'accorder sur la façon de déployer des applications en production ? Combien de développeurs connaissez-vous utilisant des outils tels qu'ils sont fournis 'en boîte' ? Combien d'administrateurs cloud aujourd'hui ne comprennent pas comment fonctionnent les applications ? Nous examinerons les réponses à ces questions dans cet article.
Infrastructure en tant que YAML
Dans un monde qui a évolué de Puppet et Chef vers Kubernetes, un des plus grands changements a été le passage de l'« infrastructure en tant que code » à l'« infrastructure en tant que données » — en particulier, en tant que YAML. Toutes les ressources dans Kubernetes, y compris les pods, configurations, instances déployées, volumes, etc., peuvent être facilement décrites dans un fichier YAML. Par exemple :
apiVersion: v1
kind: Pod
metadata:
name: site
labels:
app: web
spec:
containers:
- name: front-end
image: nginx
ports:
- containerPort: 80Avec une telle présentation, il est plus facile pour les professionnels DevOps ou SRE d'exprimer complètement leurs charges de travail, sans avoir besoin d'écrire du code dans des langages comme Python ou Javascript.
D'autres avantages de l'organisation de l'infrastructure de données sont les suivants :
- GitOps ou contrôle de version des opérations Git. Cette approche permet de conserver tous les fichiers YAML de Kubernetes dans des dépôts git, ce qui vous permet de suivre précisément quand un changement a été effectué, qui l'a effectué et ce qui a été modifié. Cela augmente la transparence des opérations au sein de toute l'organisation, améliore l'efficacité du travail en éliminant l'ambiguïté, notamment en ce qui concerne l'endroit où les employés doivent chercher les ressources dont ils ont besoin. En même temps, il devient plus facile d'apporter des modifications automatiquement aux ressources Kubernetes – par le biais d'une simple fusion de pull request.
- Scalabilité. Lorsque les ressources sont définies sous forme de YAML, il est extrêmement facile pour les opérateurs de cluster de modifier un ou deux chiffres dans la ressource Kubernetes, modifiant ainsi ses principes d'évolutivité. Kubernetes dispose d'un mécanisme pour le scale horizontal automatique des pods, permettant de définir aisément le nombre minimum et maximum de pods requis dans une configuration déployée pour gérer un faible ou un fort niveau de trafic. Par exemple, si vous avez déployé une configuration qui nécessite des capacités supplémentaires en raison d'une forte augmentation du trafic, vous pouvez changer le paramètre maxReplicas de 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- Sécurité et gestion. YAML est idéal pour évaluer comment certaines choses sont déployées dans Kubernetes. Par exemple, un problème sérieux en matière de sécurité concerne le fait de savoir si vos charges de travail s'exécutent sous un utilisateur qui n'a pas de droits d'administrateur. Dans ce cas, des outils comme peuvent s'avérer utiles. , validateur YAML/JSON, en plus , validateurs de politiques, permettant de s'assurer que le contexte La charge de travail ne permet pas au conteneur de fonctionner avec des privilèges d'administrateur. Si cela est nécessaire, les utilisateurs peuvent appliquer une politique simple. , comme ceci :
package main
deny[msg] {
input.kind = "Deployment"
not input.spec.template.spec.securityContext.runAsNonRoot = true
msg = "Les conteneurs ne doivent pas s'exécuter en tant que root"
}- Options d'intégration avec le fournisseur de cloud. L'une des tendances les plus remarquables dans les hautes technologies modernes est d'exécuter des charges de travail sur les infrastructures de fournisseurs de cloud publics. À l'aide de ce composant Kubernetes permet à tout cluster de s'intégrer au fournisseur de cloud sur lequel il fonctionne. Par exemple, si un utilisateur déploie une application dans Kubernetes sur AWS et souhaite rendre cette application accessible via un service, le fournisseur de cloud aide à créer automatiquement ce service.
LoadBalancer, qui fournira automatiquement un équilibreur de charge , pour rediriger le trafic vers les pods d'applications.
Extensibilité
Kubernetes se développe très bien, et cela plaît aux développeurs. Il existe un ensemble de ressources disponibles, telles que les pods, les déploiements, StatefulSets, les secrets, ConfigMaps, etc. En vérité, les utilisateurs et les développeurs peuvent ajouter d'autres ressources sous la forme de .
Par exemple, si nous voulons définir une ressource CronTab, nous pourrions faire quelque chose comme ceci :
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
Plus tard, nous pouvons créer une ressource CronTab d'une manière similaire :
apiVersion: "my.org/v1"
kind: CronTab
metadata:
name: my-cron-object
spec:
cronSpec: "* * * * */5"
image: my-cron-image
replicas: 5
Une autre option d'extensibilité dans Kubernetes est que le développeur peut écrire ses propres opérateurs. – c'est un processus spécial dans le cluster Kubernetes, fonctionnant selon le modèle "» Grâce à l'opérateur, l'utilisateur peut automatiser la gestion des CRD (définitions de ressources personnalisées), en échangeant des informations avec l'API Kubernetes.
Il existe plusieurs outils dans la communauté qui permettent aux développeurs de créer facilement leurs propres opérateurs. Parmi eux se trouve et de ses . Ce SDK fournit une base à partir de laquelle le développeur peut commencer très rapidement à créer un opérateur. Par exemple, on peut commencer par la ligne de commande de la manière suivante :
$ operator-sdk new my-operator --repo github.com/myuser/my-operatorC'est ainsi que tout le code stéréotypé pour votre opérateur est créé, y compris les fichiers YAML et le code en 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.goEnsuite, vous pouvez ajouter les API et le contrôleur nécessaires, comme ceci :
$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService
$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppServiceAprès cela, assemblez enfin l'opérateur et envoyez-le à votre registre de conteneurs :
$ operator-sdk build your.container.registry/youruser/myapp-operator Si le développeur nécessite un contrôle encore plus complet, il peut modifier le code stéréotypé dans les fichiers en Go. Par exemple, pour modifier la spécificité du contrôleur, vous pouvez apporter des modifications à controller.go.
Un autre projet, , permet de créer des opérateurs en utilisant uniquement des fichiers YAML déclaratifs. Par exemple, un opérateur pour Apache Kafka sera défini à peu près comme . Avec celui-ci, vous pouvez installer un cluster Kafka sur Kubernetes avec seulement quelques commandes :
$ kubectl kudo install zookeeper
$ kubectl kudo install kafkaEt ensuite, le configurer avec une autre commande :
$ 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
Au cours des dernières années, les grandes versions de Kubernetes sortent tous les quelques mois, c'est-à-dire trois à quatre grandes versions par an. Le nombre de nouvelles fonctionnalités intégrées dans chacune d'elles ne diminue pas. De plus, il n'y a pas de signes de ralentissement même en ces temps difficiles – regardez l'activité actuelle du .
Les nouvelles fonctionnalités permettent de mieux clusteriser les opérations avec une variété de charges de travail. De plus, les développeurs apprécient un meilleur contrôle lors du déploiement d'applications directement en production.
Communauté
Un autre aspect majeur de la popularité de Kubernetes réside dans la force de sa communauté. En 2015, avec l'arrivée de la version 1.0, Kubernetes a été sponsorisé .
Il existe également diverses communautés (Groupes d'intérêt spéciaux) qui se concentrent sur différents domaines de Kubernetes à mesure que ce projet évolue. Ces groupes ajoutent en permanence de nouvelles fonctionnalités, rendant l'utilisation de Kubernetes de plus en plus pratique.
La Cloud Native Foundation organise également CloudNativeCon/KubeCon, qui, au moment de la rédaction de ce texte, est la plus grande conférence open source au monde. En général, elle a lieu trois fois par an et rassemble des milliers de professionnels désireux d'améliorer Kubernetes et son écosystème, ainsi que de maîtriser de nouvelles fonctionnalités qui apparaissent tous les trois mois.
De plus, la Cloud Native Foundation possède , qui, avec les SIG, examine les nouveaux projets et ceux existants faisant partie du fonds, axés sur l'écosystème cloud. La plupart de ces projets sont conçus pour renforcer les atouts de Kubernetes.
Enfin, je crois que Kubernetes n'aurait pas connu un tel succès sans les efforts conscients de toute la communauté, où les gens se soutiennent mutuellement, mais accueillent également avec joie les nouveaux venus.
L'avenir
L'un des principaux défis auxquels les développeurs devront faire face à l'avenir est la capacité à se concentrer sur les détails du code lui-même, plutôt que sur l'infrastructure dans laquelle il fonctionne. C'est précisément à cette tendance que répond , qui est aujourd'hui l'une des plus en vue. Il existe déjà des frameworks avancés, comme et , qui utilisent Kubernetes pour abstraire l'infrastructure des développeurs.
Dans cet article, nous avons seulement brossé un aperçu de l'état actuel de Kubernetes – en réalité, ce n'est que la pointe de l'iceberg. Les utilisateurs de Kubernetes disposent également de nombreuses autres ressources, capacités et configurations.
Source : habr.com
