Hallo, Habra!
Am Ende des Sommers möchten wir daran erinnern, dass wir weiterhin am Thema arbeiten und haben beschlossen, einen Artikel von Stackoverflow zu veröffentlichen, der den Stand der Dinge in diesem Projekt zu Beginn des Juni zeigt.
Viel SpaĂ beim Lesen!
Zum Zeitpunkt der Erstellung dieses Artikels ist Kubernetes etwa , und in den letzten zwei Jahren ist seine PopularitĂ€t so stark gewachsen, dass es stabil zu den Plattformen gehört. In diesem Jahr belegt Kubernetes den dritten Platz. Erinnern wir uns: Kubernetes ist eine Plattform, die fĂŒr den Betrieb und die Orchestrierung von Container-Workloads konzipiert ist.
Container entstanden als spezielle Struktur zur Isolation von Prozessen in Linux; seit 2007 gehören dazu , und seit 2002 â Namespaces. Container haben sich bis 2008 noch weiter entwickelt, als verfĂŒgbar wurde , und Google entwickelte sein internes Mechanismus namens , wo âalle Arbeiten in Containern durchgefĂŒhrt werdenâ. Lassen Sie uns ins Jahr 2013 zurĂŒckspringen, als die erste Version von Docker veröffentlicht wurde und Container endgĂŒltig zu beliebten Massenlösungen wurden. Zu diesem Zeitpunkt war das Hauptwerkzeug zur Orchestrierung von Containern , obwohl es nicht ĂŒbermĂ€Ăig populĂ€r war. Die erste Veröffentlichung von Kubernetes fand 2015 statt, danach wurde dieses Tool de facto zum Standard im Bereich der Container-Orchestrierung.
Um zu versuchen, zu verstehen, warum Kubernetes so beliebt ist, lassen Sie uns einige Fragen beantworten. Wann gelang es den Entwicklern zuletzt, sich darĂŒber zu einigen, wie man Anwendungen in der Produktion bereitstellt? Wie viele Entwickler kennen Sie, die Werkzeuge so verwenden, wie sie âout of the boxâ bereitgestellt werden? Wie viele Cloud-Administratoren von heute haben kein VerstĂ€ndnis dafĂŒr, wie Anwendungen funktionieren? Die Antworten auf diese Fragen werden wir in diesem Artikel betrachten.
Infrastructure as YAML
In einer Welt, die von Puppet und Chef zu Kubernetes ĂŒbergegangen ist, bestand eine der gröĂten VerĂ€nderungen darin, von âInfrastructure as Codeâ zu âInfrastructure as Dataâ â konkret, in Form von YAML. Alle Ressourcen in Kubernetes, einschlieĂlich Pods, Konfigurationen, bereitgestellte Instanzen, Volumes usw., können einfach in einer YAML-Datei beschrieben werden. Zum Beispiel:
apiVersion: v1
kind: Pod
metadata:
name: site
labels:
app: web
spec:
containers:
- name: front-end
image: nginx
ports:
- containerPort: 80Mit dieser PrĂ€sentation können DevOps- oder SRE-Spezialisten ihre Arbeitslasten vollstĂ€ndig ausdrĂŒcken, ohne den Programmcode in Sprachen wie Python oder Javascript schreiben zu mĂŒssen.
Weitere Vorteile der Organisation von Infrastruktur als Daten sind unter anderem:
- GitOps oder Versionskontrolle von Git Operations Version. Dieser Ansatz ermöglicht es, alle YAML-Dateien von Kubernetes in Git-Repositories zu halten, wodurch Sie genau nachverfolgen können, wann eine Ănderung vorgenommen wurde, wer sie vorgenommen hat und was genau sich geĂ€ndert hat. Dies erhöht die Transparenz der Operationen innerhalb der gesamten Organisation und steigert die Effizienz, da Unklarheiten, insbesondere bezĂŒglich des Standortes, an dem Mitarbeiter die benötigten Ressourcen suchen, beseitigt werden. Gleichzeitig wird es einfacher, Ănderungen an Kubernetes-Ressourcen automatisch vorzunehmen - durch einfaches ZusammenfĂŒhren von Pull-Requests.
- Skalierbarkeit. Wenn Ressourcen in Form von YAML definiert sind, wird es den Cluster-Operatoren extrem einfach, eine oder zwei Zahlen in der Kubernetes-Ressource zu Àndern, wodurch sich die Skalierungsprinzipien Àndern. Kubernetes hat einen Mechanismus zum horizontalen automatischen Skalieren von Pods, mit dem einfach festgelegt werden kann, wie viele Pods minimum und maximum in einer bestimmten bereitgestellten Konfiguration erforderlich sind, um mit niedrigem und hohem Verkehrsaufkommen umzugehen. Beispielsweise, wenn Sie eine Konfiguration bereitgestellt haben, die aufgrund eines plötzlichen Anstiegs des Verkehrs zusÀtzliche Ressourcen benötigt, kann der Wert von maxReplicas von 10 auf 20 geÀndert werden:
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- Sicherheit und Verwaltung. YAML eignet sich hervorragend zur Bewertung, wie verschiedene Dinge in Kubernetes bereitgestellt werden. Ein ernsthaftes Sicherheitsproblem betrifft die Frage, ob Ihre Arbeitslasten unter einem Benutzer ausgefĂŒhrt werden, der keine Administratorrechte hat. In diesem Fall können uns Werkzeuge wie , YAML/JSON-Validator, plus , Policy-Validator, um sicherzustellen, dass der Kontext Ihre Arbeitslasten erlauben es dem Container nicht, mit Administratorrechten zu arbeiten. Wenn dies erforderlich ist, können die Benutzer eine einfache Richtlinie anwenden. , so:
package main
deny[msg] {
input.kind = "Deployment"
not input.spec.template.spec.securityContext.runAsNonRoot = true
msg = "Container dĂŒrfen nicht als root ausgefĂŒhrt werden"
}- Integrationsmöglichkeiten mit dem Cloud-Anbieter. Einer der auffĂ€lligsten Trends in der modernen Hochtechnologie ist das AusfĂŒhren von Arbeitslasten auf den Ressourcen öffentlicher Cloud-Anbieter. Mit Hilfe des Components ermöglicht Kubernetes jedem Cluster die Integration mit dem Cloud-Anbieter, auf dem es lĂ€uft. Wenn ein Benutzer beispielsweise eine Anwendung in Kubernetes auf AWS gestartet hat und den Zugriff auf diese Anwendung ĂŒber einen Service eröffnen möchte, hilft der Cloud-Anbieter dabei, automatisch einen Service zu erstellen,
LoadBalancer, der automatisch einen Lastenausgleich bereitstellt. , um den Traffic auf die Pods der Anwendungen umzuleiten.
Erweiterbarkeit
Kubernetes ist sehr skalierbar, und das gefÀllt den Entwicklern. Es gibt eine Reihe vorhandener Ressourcen wie Pods, Deployments, StatefulSets, Secrets, ConfigMaps, usw. TatsÀchlich können Benutzer und Entwickler weitere Ressourcen in Form von .
definieren. Wenn wir beispielsweise eine Ressource definieren möchten CronTab, könnten wir so etwas machen:
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
SpÀter können wir eine Ressource CronTab ungefÀhr so erstellen:
apiVersion: "my.org/v1"
kind: CronTab
metadata:
name: my-cron-object
spec:
cronSpec: "* * * * */5"
image: my-cron-image
replicas: 5
Eine weitere Möglichkeit zur Erweiterbarkeit in Kubernetes besteht darin, dass Entwickler eigene Operatoren schreiben können. â dies ist ein spezieller Prozess im Kubernetes-Cluster, der nach dem Muster ââ funktioniert. Mithilfe des Operators kann der Benutzer die Verwaltung von CRDs (benutzerdefinierten Ressourcendefinitionen) automatisieren, indem er Informationen mit der Kubernetes-API austauscht.
In der Community gibt es mehrere Werkzeuge, mit denen Entwickler ihre eigenen Operatoren einfach erstellen können. Dazu gehört stabilen Zweigen . Dieses SDK bietet eine Grundlage, von der aus der Entwickler sehr schnell mit der Erstellung eines Operators beginnen kann. Zum Beispiel kann man mit der Befehlszeile ungefÀhr so anfangen:
$ operator-sdk new my-operator --repo github.com/myuser/my-operatorSo wird der gesamte Standardcode fĂŒr Ihren Operator erstellt, einschlieĂlich der YAML-Dateien und dem 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.goDanach können die erforderlichen APIs und der Controller so hinzugefĂŒgt werden:
$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService
$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppServiceAnschlieĂend kann der Operator schlieĂlich gesammelt und in das Container-Registry Ihrer Wahl hochgeladen werden:
$ operator-sdk build your.container.registry/youruser/myapp-operator Falls der Entwickler noch mehr Kontrolle benötigt, kann er den Standardcode in den Go-Dateien anpassen. Zum Beispiel kann man Ănderungen an der Datei vornehmen, um die spezifische Funktionsweise des Controllers zu modifizieren. controller.go.
Ein weiteres Projekt, , ermöglicht es, Operatoren allein mit deklarativen YAML-Dateien zu erstellen. Beispielsweise wird der Operator fĂŒr Apache Kafka ungefĂ€hr so definiert . Damit kann man mit nur ein paar Befehlen einen Kafka-Cluster auf Kubernetes installieren:
$ kubectl kudo install zookeeper
$ kubectl kudo install kafkaUnd dann kann er mit einem weiteren Befehl konfiguriert werden:
$ 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
Innovationen
In den letzten Jahren erscheinen groĂe Kubernetes-Versionen alle paar Monate â also drei bis vier groĂe Versionen pro Jahr. Die Anzahl neuer Funktionen, die in jeder einzelnen implementiert werden, nimmt nicht ab. DarĂŒber hinaus sind selbst in unseren schwierigen Zeiten keine Anzeichen einer Verlangsamung zu beobachten â schauen Sie sich an, wie aktiv das .
. Neue Möglichkeiten ermöglichen eine flexiblere Clusterbildung der Operationen bei unterschiedlichen Arbeitslasten. AuĂerdem schĂ€tzen Programmierer eine umfassendere Kontrolle beim Bereitstellen von Anwendungen direkt in der Produktion.
Die Community
Ein weiterer ernsthafter Aspekt der PopularitÀt von Kubernetes liegt in der StÀrke seiner Community. Im Jahr 2015, nach der Veröffentlichung von Version 1.0, wurde Kubernetes gesponsert .
Es gibt auch verschiedene Gemeinschaften (Sondergruppen, die darauf abzielen, verschiedene Bereiche von Kubernetes zu bearbeiten, wĂ€hrend sich das Projekt weiterentwickelt. Diese Gruppen fĂŒgen stĂ€ndig neue Funktionen hinzu, wodurch die Arbeit mit Kubernetes immer praktischer wird.
Die Cloud Native Foundation veranstaltet auch die CloudNativeCon/KubeCon, die zum Zeitpunkt des Verfassens dieses Textes die gröĂte Open-Source-Konferenz der Welt ist. In der Regel findet sie dreimal im Jahr statt und versammelt Tausende von Fachleuten, die Kubernetes und sein Ăkosystem verbessern möchten sowie neue Möglichkeiten erlernen, die alle drei Monate entstehen.
DarĂŒber hinaus gibt es in der Cloud Native Foundation , das zusammen mit den SIGs neue und bestehende Fonds, die auf das Cloud-Ăkosystem ausgerichtet sind. Die meisten dieser Projekte tragen zur Verbesserung der StĂ€rken von Kubernetes bei.
SchlieĂlich glaube ich, dass Kubernetes nicht so erfolgreich wĂ€re, hĂ€tte es nicht das bewusste Engagement der gesamten Community, in der sich die Menschen gegenseitig unterstĂŒtzen, wĂ€hrend sie gleichzeitig neue Mitglieder herzlich willkommen heiĂen.
Zukunft
Eine der gröĂten Herausforderungen, mit denen Entwickler in Zukunft konfrontiert sein werden, ist die FĂ€higkeit, sich auf die Details des Codes selbst zu konzentrieren und nicht auf die Infrastruktur, in der er ausgefĂŒhrt wird. Genau auf diese Trends reagiert , das heute zu den fĂŒhrenden gehört. Es gibt bereits fortschrittliche Frameworks, wie zum Beispiel und , die Kubernetes zur Abstraktion der Infrastruktur vom Entwickler nutzen.
In diesem Artikel haben wir nur einen allgemeinen Ăberblick ĂŒber den aktuellen Stand von Kubernetes gegeben â tatsĂ€chlich ist das nur die Spitze des Eisbergs. Den Nutzern von Kubernetes stehen viele weitere Ressourcen, Möglichkeiten und Konfigurationen zur VerfĂŒgung.
Quelle: habr.com
