Hallo, Habr!
Aan het einde van de zomer willen we herinneren dat we doorgaan met het werken aan het onderwerp en hebben besloten om een artikel van Stackoverflow te publiceren, dat de stand van zaken in dit project begin juni toont.
Prettige lectuur!
Op het moment dat dit artikel geschreven werd, is Kubernetes ongeveer , en in de afgelopen twee jaar is de populariteit zo gegroeid dat het consistent tot Ć©Ć©n van de platforms behoort. Dit jaar staat Kubernetes op de derde plaats. Ter herinnering: Kubernetes is een platform dat is ontworpen voor het draaien en orkestreren van container workload.
Containers zijn ontstaan als een speciale constructie voor procesisolatie in Linux; sinds 2007 bevatten containers , en sinds 2002 namespaces. Containers zijn nog beter vormgegeven in 2008, toen beschikbaar kwam, en Google ontwikkelde een interne mechanism genaamd , waar "al het werk in containers plaatsvindt". We springen naar 2013, toen de eerste release van Docker plaatsvond en containers eindelijk populair werden als massale oplossingen. Op dat moment was het belangrijkste instrument voor het orkestreren van containers , hoewel het niet bijzonder populair was. De eerste release van Kubernetes vond plaats in 2015, waarna dit instrument de facto de standaard werd op het gebied van containerorkestratie.
Om te proberen te begrijpen waarom Kubernetes zo populair is, laten we proberen een paar vragen te beantwoorden. Wanneer was de laatste keer dat ontwikkelaars overeenstemming konden bereiken over hoe applicaties in productie moeten worden uitgerold? Hoeveel ontwikkelaars kent u die de tools gebruiken zoals ze "out of the box" worden aangeleverd? Hoeveel cloudbeheerders zijn er tegenwoordig die niet begrijpen hoe applicaties werken? De antwoorden op deze vragen zullen we in dit artikel behandelen.
Infrastructuur als YAML
In een wereld die van Puppet en Chef naar Kubernetes is gegaan, was een van de grootste veranderingen de overgang van "infrastructuur als code" naar "infrastructuur als data" ā specifiek, als YAML. Alle bronnen in Kubernetes, zoals pods, configuraties, uitgerolde instanties, volumes, enzovoort, 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: 80Met deze aanpak kunnen DevOps- of SRE-specialisten hun werkbelasting volledig uitdrukken, zonder dat ze programmeercode hoeven te schrijven in talen zoals Python of Javascript.
Andere voordelen van het organiseren van infrastructuur als data zijn als volgt:
- GitOps of versiebeheer van Git Operations. Deze aanpak stelt je in staat om alle YAML-bestanden van Kubernetes in Git-repositories te houden, waardoor je precies kunt bijhouden wanneer een wijziging is aangebracht, wie deze heeft aangebracht en wat er precies is veranderd. Dit verhoogt de transparantie van de processen binnen de organisatie en verbetert de efficiĆ«ntie door ambiguĆÆteit weg te nemen, vooral waar medewerkers de benodigde bronnen moeten zoeken. Tegelijkertijd wordt het eenvoudiger om automatisch wijzigingen aan Kubernetes-resources aan te brengen door middel van een gewone pull-verzoek.
- Schaalbaarheid. Wanneer resources zijn gedefinieerd in YAML, wordt het voor clusteroperators extreem eenvoudig om Ć©Ć©n of twee cijfers in de Kubernetes-resource te wijzigen, waardoor de schaalprincipes ervan veranderen. Kubernetes heeft een mechanisme voor horizontale autoscaling van pods, waarmee je gemakkelijk kunt bepalen wat het minimum- en maximumaantal pods is dat nodig is in een specifieke uitgerolde configuratie om om te gaan met laag en hoog verkeersniveau. Bijvoorbeeld, als je een configuratie hebt uitgerold die extra capaciteit vereist vanwege een plotselinge verkeersstijging, kan de maxReplicas-waarde worden gewijzigd van 10 naar 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- Veiligheid en beheer. YAML is uitermate geschikt voor het beoordelen van hoe dingen worden uitgerold in Kubernetes. Een serieus probleem met de beveiliging heeft betrekking op de vraag of je werkbelastingen draaien vanuit een gebruiker zonder administratieve rechten. In dit geval kunnen tools zoals , een YAML/JSON-validator, en , een beleidsvalidator die ervoor zorgt dat de context de werklast van uw containers staat niet toe dat ze met beheerdersrechten draaien. Indien nodig kunnen gebruikers een eenvoudige beleid toepassen. , zo:
package main
denie[msg] {
input.kind = "Deployment"
not input.spec.template.spec.securityContext.runAsNonRoot = true
msg = "Containers mogen niet als root draaien"
}- Integratiemogelijkheden met cloudproviders. Een van de meest opvallende trends in moderne technologieƫn is het draaien van werklasten op de infrastructuur van publieke cloudproviders. Met de component Kubernetes stelt elke cluster in staat om te integreren met de cloudprovider waarvoor het is ingericht. Bijvoorbeeld, als een gebruiker een applicatie in Kubernetes op AWS heeft uitgevoerd en deze applicatie toegankelijk wil maken via een service, helpt de cloudprovider automatisch een service te creƫren
LoadBalancer, die automatisch een load balancer zal verstrekken , om het verkeer naar de applicatie-pods te routeren.
Schaalbaarheid
Kubernetes is zeer uitbreidbaar en dat is aantrekkelijk voor ontwikkelaars. Er is een set bestaande bronnen zoals pods, deployments, StatefulSets, secrets, ConfigMaps, enzovoort. Echter, gebruikers en ontwikkelaars kunnen ook andere bronnen toevoegen in de vorm van .
Bijvoorbeeld, als we een resource willen definiƫren CronTab, zouden we iets kunnen doen zoals:
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 resource ongeveer als volgt creƫren:
apiVersion: "my.org/v1"
kind: CronTab
metadata:
name: my-cron-object
spec:
cronSpec: "* * * * */5"
image: my-cron-image
replicas: 5
Een andere mogelijkheid voor uitbreidbaarheid in Kubernetes is dat de ontwikkelaar zijn eigen operators kan schrijven. is een speciaal proces in de Kubernetes-cluster dat werkt volgens het patroon "". Met een operator kan de gebruiker het beheer van CRD (gebruikersgedefinieerde resource definities) automatiseren door informatie uit te wisselen met de Kubernetes API.
In de gemeenschap zijn er verschillende hulpmiddelen waarmee ontwikkelaars gemakkelijk hun eigen operators kunnen maken.Onder hen is er: en zijn . Deze SDK biedt een basis waar de ontwikkelaar snel aan de slag kan met het creƫren van een operator. Laten we zeggen dat je kunt beginnen met de opdrachtregel ongeveer zo:
$ operator-sdk new my-operator --repo github.com/myuser/my-operatorZo wordt de standaardcode voor jouw operator gecreƫerd, inclusief YAML-bestanden en code in 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.goVervolgens kun je de benodigde API en controller toevoegen, zo:
$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService
$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppServiceDaarna kun je eindelijk de operator bouwen en deze naar jouw containerregister sturen:
$ operator-sdk build your.container.registry/youruser/myapp-operator Als de ontwikkelaar nog meer controle wenst, kan hij de standaardcode in de Go-bestanden aanpassen. Bijv. om de specificiteit van de controller te wijzigen, kan je de wijzigingen aanbrengen in het bestand controller.go.
Een ander project, , stelt je in staat om operators te creƫren, waarbij je enkel declaratieve YAML-bestanden gebruikt. Bijvoorbeeld, een operator voor Apache Kafka zou ongeveer als volgt worden gedefinieerd: . Hiermee kun je met een paar commando's een Kafka-cluster bovenop Kubernetes installeren:
$ kubectl kudo install zookeeper
$ kubectl kudo install kafkaEn vervolgens kun je deze configureren met nog een 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
In de afgelopen jaren zijn er grote releases van Kubernetes om de paar maanden ā dat wil zeggen, drie tot vier grote releases per jaar. Het aantal nieuwe functies dat in elke release wordt geĆÆntroduceerd, neemt niet af. Sterker nog, er zijn zelfs geen tekenen van vertraging merkbaar, kijk maar naar de huidige .
Nieuwe mogelijkheden maken het mogelijk om flexibeler te clusteren bij diverse werkbelastingen. Bovendien waarderen programmeurs meer controle bij het uitrollen van applicaties direct in productie.
Gemeenschap
Een andere belangrijke factor in de populariteit van Kubernetes is de kracht van de gemeenschap. In 2015, met de release van versie 1.0, werd Kubernetes gesponsord .
Er bestaan ook verschillende gemeenschappen (Special Interest Groups), gericht op het verkennen van verschillende gebieden van Kubernetes naarmate dit project zich ontwikkelt. Deze groepen blijven voortdurend nieuwe mogelijkheden toevoegen, waardoor werken met Kubernetes steeds gemakkelijker wordt.
De Cloud Native Foundation organiseert ook CloudNativeCon/KubeCon, die, op het moment van schrijven, de grootste open source conferentie ter wereld is. Het wordt meestal drie keer per jaar gehouden en verzamelt duizenden professionals die hun kennis van Kubernetes en zijn ecosysteem willen verbeteren, evenals nieuwe mogelijkheden willen leren die elke drie maanden verschijnen.
Bovendien is er binnen de Cloud Native Foundation , dat, samen met SIGs, nieuwe en bestaande projecten van de stichting, gericht op het cloud-ecosysteem. De meeste van deze projecten helpen om de sterke punten van Kubernetes te verbeteren.
Tot slot geloof ik dat Kubernetes niet zo'n succes zou hebben gehad zonder de bewuste inspanningen van de hele gemeenschap, waar mensen elkaar steunen, maar tegelijkertijd nieuwkomers met open armen verwelkomen.
Toekomst
Een van de grootste uitdagingen waar ontwikkelaars in de toekomst mee te maken zullen krijgen, is de vaardigheid om zich te concentreren op de details van de code zelf, in plaats van op de infrastructuur waarin deze draait. Deze trends beantwoorden aan , die tegenwoordig een van de toonaangevende is. Er zijn al geavanceerde frameworks, zoals en , die Kubernetes gebruiken om de infrastructuur van de ontwikkelaar te abstraheren.
In dit artikel hebben we slechts een algemeen overzicht gegeven van de huidige staat van Kubernetes ā in werkelijkheid is dit slechts de top van de ijsberg. Gebruikers van Kubernetes hebben ook tal van andere middelen, mogelijkheden en configuraties tot hun beschikking.
Bron: habr.com
