Hé Habr!
Aan het einde van de zomer willen we u eraan herinneren dat we aan dit onderwerp blijven werken en besloot begin juni een artikel van Stackoverflow te publiceren waarin de stand van zaken in dit project werd gedemonstreerd.
Veel leesplezier!
Op het moment dat dit artikel wordt geschreven, is de leeftijd van Kubernetes ca. , en de afgelopen twee jaar is de populariteit ervan zo sterk gegroeid dat het er consequent onder wordt gerangschikt platforms. Kubernetes staat dit jaar op de derde plaats. Samenvattend: Kubernetes is een platform dat is ontworpen voor het uitvoeren en orkestreren van gecontaineriseerde workloads.
Containers zijn begonnen als een speciaal ontwerp voor het isoleren van processen in Linux; containers zijn sinds 2007 inbegrepen , en sinds 2002 – naamruimten. Containers werden in 2008, toen deze beschikbaar kwamen, nog beter ontworpen , en Google ontwikkelde zijn eigen interne bedrijfsmechanisme genaamd , waar “al het werk in containers wordt gedaan.” Vanaf hier gaan we snel vooruit naar 2013, toen de eerste release van Docker plaatsvond en containers eindelijk een populaire massaoplossing werden. Destijds was het belangrijkste hulpmiddel voor containerorkestratie , hoewel hij niet enorm populair was. Kubernetes werd voor het eerst uitgebracht in 2015, waarna deze tool de de facto standaard werd op het gebied van containerorkestratie.
Om te proberen te begrijpen waarom Kubernetes zo populair is, proberen we een paar vragen te beantwoorden. Wanneer konden ontwikkelaars het voor het laatst eens worden over de manier waarop applicaties in productie konden worden genomen? Hoeveel ontwikkelaars kent u die de tools gebruiken zoals deze kant-en-klaar worden geleverd? Hoeveel cloudbeheerders zijn er tegenwoordig die niet begrijpen hoe applicaties werken? De antwoorden op deze vragen zullen we in dit artikel bekijken.
Infrastructuur als YAML
In de wereld die van Puppet en Chef naar Kubernetes ging, was een van de grootste veranderingen de overstap van ‘infrastructuur als code’ naar ‘infrastructuur als data’ – specifiek zoals YAML. Alle bronnen in Kubernetes, waaronder pods, configuraties, geïmplementeerde instanties, volumes, enz., kunnen eenvoudig worden beschreven in een YAML-bestand. Bijvoorbeeld:
apiVersion: v1
kind: Pod
metadata:
name: site
labels:
app: web
spec:
containers:
- name: front-end
image: nginx
ports:
- containerPort: 80Deze weergave maakt het voor DevOps- of SRE-professionals gemakkelijker om hun werklasten volledig uit te drukken zonder code te hoeven schrijven in talen als Python of Javascript.
Andere voordelen van het organiseren van infrastructuur als data zijn onder meer:
- GitOps of Git Operations Versiebeheer. Met deze aanpak kun je alle Kubernetes YAML-bestanden in git-opslagplaatsen bewaren, zodat je precies kunt bijhouden wanneer een wijziging is aangebracht, wie deze heeft gemaakt en wat er precies is gewijzigd. Dit vergroot de transparantie van de activiteiten in de hele organisatie en verbetert de operationele efficiëntie door dubbelzinnigheid weg te nemen, vooral op het gebied van waar werknemers moeten zoeken naar de middelen die ze nodig hebben. Tegelijkertijd wordt het eenvoudiger om automatisch wijzigingen aan te brengen in Kubernetes-bronnen door simpelweg een pull-verzoek samen te voegen.
- Schaalbaarheid. Wanneer resources worden gedefinieerd als YAML, wordt het voor clusteroperatoren uiterst eenvoudig om een of twee getallen in een Kubernetes-resource te wijzigen, waardoor de manier waarop deze wordt geschaald verandert. Kubernetes biedt een mechanisme voor het horizontaal automatisch schalen van pods, dat kan worden gebruikt om gemakkelijk te bepalen wat het minimale en maximale aantal pods nodig heeft in een bepaalde implementatieconfiguratie om lage en hoge verkeersniveaus te verwerken. Als u bijvoorbeeld een configuratie heeft geïmplementeerd die extra capaciteit vereist vanwege een plotselinge piek in het verkeer, dan kan maxReplicas worden gewijzigd van 10 in 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- Beveiliging en beheer. YAML is geweldig om te evalueren hoe dingen in Kubernetes worden geïmplementeerd. Een belangrijk beveiligingsprobleem heeft bijvoorbeeld betrekking op de vraag of uw workloads worden uitgevoerd als gebruiker zonder beheerdersrechten. In dit geval hebben we mogelijk hulpmiddelen nodig zoals , YAML/JSON-validator, plus , een beleidsvalidator om ervoor te zorgen dat de context uw workloads staan niet toe dat de container met beheerdersrechten wordt uitgevoerd. Als dit nodig is, kunnen gebruikers een eenvoudig beleid toepassen , soortgelijk:
package main
deny[msg] {
input.kind = "Deployment"
not input.spec.template.spec.securityContext.runAsNonRoot = true
msg = "Containers must not run as root"
}- Opties voor integratie met een cloudprovider. Een van de meest opvallende trends in de hedendaagse geavanceerde technologie is het uitvoeren van workloads op publieke cloudproviders. Het onderdeel gebruiken Met Kubernetes kan elk cluster integreren met de cloudprovider waarop het draait. Als een gebruiker bijvoorbeeld een applicatie in Kubernetes op AWS draait en die applicatie via een service wil ontsluiten, helpt de cloudprovider automatisch de service te creëren
LoadBalancer, die automatisch de load balancer levert om verkeer om te leiden naar toepassingspods.
Uitbreidbaarheid
Kubernetes is zeer uitbreidbaar en ontwikkelaars zijn er dol op. Er is een reeks beschikbare bronnen, zoals pods, implementaties, StatefulSets, geheimen, ConfigMaps, enz. Het is waar dat gebruikers en ontwikkelaars andere bronnen aan het formulier kunnen toevoegen .
Als we bijvoorbeeld een resource willen definiëren CronTab, dan zou je zoiets als dit kunnen doen:
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
Later kunnen we een CronTab-bron zoiets als deze maken:
apiVersion: "my.org/v1"
kind: CronTab
metadata:
name: my-cron-object
spec:
cronSpec: "* * * * */5"
image: my-cron-image
replicas: 5
Een andere optie voor uitbreidbaarheid in Kubernetes is dat de ontwikkelaar zijn eigen verklaringen kan schrijven. is een speciaal proces in het Kubernetes-cluster dat werkt volgens de “" Met behulp van een operator kan de gebruiker het beheer van CRD’s (aangepaste resourcedefinities) automatiseren door informatie uit te wisselen met de Kubernetes API.
Er zijn verschillende tools in de community waarmee ontwikkelaars gemakkelijk hun eigen operators kunnen maken. Onder hen - en . Deze SDK biedt een basis van waaruit een ontwikkelaar snel kan beginnen met het maken van een operator. Laten we zeggen dat u vanaf de opdrachtregel zoiets als dit kunt starten:
$ operator-sdk new my-operator --repo github.com/myuser/my-operatorHiermee wordt alle standaardcode voor uw operator gemaakt, inclusief YAML-bestanden en 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.goVervolgens kunt u de vereiste API's en controller als volgt toevoegen:
$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService
$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppServiceMonteer vervolgens ten slotte de operator en stuur deze naar het register van uw container:
$ operator-sdk build your.container.registry/youruser/myapp-operator
Als de ontwikkelaar nog meer controle wil, kan de standaardcode in Go-bestanden worden gewijzigd. Als u bijvoorbeeld de specificaties van de controller wilt wijzigen, kunt u wijzigingen in het bestand aanbrengen controller.go.
Nog een project , kunt u instructies maken met alleen declaratieve YAML-bestanden. Een operator voor Apache Kafka zou bijvoorbeeld bij benadering worden gedefinieerd . Hiermee kun je met slechts een paar opdrachten een Kafka-cluster bovenop Kubernetes installeren:
$ kubectl kudo install zookeeper
$ kubectl kudo install kafkaEn configureer het vervolgens met een ander commando:
$ 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
innovaties
De afgelopen jaren zijn er elke paar maanden grote Kubernetes-releases uitgekomen, dat wil zeggen drie tot vier grote releases per jaar. Het aantal nieuwe functies dat in elk van deze wordt geïntroduceerd, neemt niet af. Bovendien zijn er zelfs in deze moeilijke tijden geen tekenen van vertraging – kijk eens hoe de situatie nu is .
Met nieuwe mogelijkheden kunt u bewerkingen flexibeler clusteren over verschillende workloads. Bovendien hebben programmeurs meer controle bij het rechtstreeks implementeren van applicaties in productie.
Gemeenschap
Een ander belangrijk aspect van de populariteit van Kubernetes is de kracht van de community. In 2015, toen versie 1.0 werd bereikt, werd Kubernetes gesponsord door .
Er zijn ook verschillende gemeenschappen (Special Interest Groups) gericht op het werken aan verschillende gebieden van Kubernetes naarmate het project zich ontwikkelt. Deze groepen voegen voortdurend nieuwe functies toe, waardoor het werken met Kubernetes handiger en handiger wordt.
De Cloud Native Foundation organiseert ook CloudNativeCon/KubeCon, op het moment van schrijven de grootste open source conferentie ter wereld. Het wordt doorgaans drie keer per jaar gehouden en brengt duizenden professionals samen die Kubernetes en zijn ecosysteem willen verbeteren, en nieuwe functies willen leren die elke drie maanden verschijnen.
Bovendien heeft Cloud Native Foundation dat wel , die samen met SIG's nieuwe en bestaande beoordelingen beoordeelt fondsen gericht op het cloud-ecosysteem. De meeste van deze projecten helpen de sterke punten van Kubernetes te verbeteren.
Ten slotte geloof ik dat Kubernetes niet zo succesvol zou zijn als het nu is zonder de bewuste inspanningen van de hele gemeenschap, waar mensen bij elkaar blijven maar tegelijkertijd nieuwkomers verwelkomen.
De toekomst
Een van de belangrijkste uitdagingen waarmee ontwikkelaars in de toekomst te maken zullen krijgen, is het vermogen om zich te concentreren op de details van de code zelf, en niet op de infrastructuur waarin deze draait. Het voldoet aan deze trends , dat vandaag een van de toonaangevende is. Er bestaan al geavanceerde raamwerken, b.v. и , die Kubernetes gebruiken om de infrastructuur van de ontwikkelaar te abstraheren.
In dit artikel hebben we slechts het topje van de ijsberg van de huidige staat van Kubernetes beschreven. Kubernetes-gebruikers hebben veel andere bronnen, mogelijkheden en configuraties tot hun beschikking.
Bron: www.habr.com