Hei Habr!
Kesän lopulla haluamme muistuttaa, että jatkamme aiheen käsittelyä ja päätti julkaista Stackoverflowsta artikkelin, jossa esitellään tämän projektin tilannetta kesäkuun alussa.
Nauti lukemisesta!
Tätä artikkelia kirjoitettaessa Kubernetesin ikä on noin. , ja viimeisen kahden vuoden aikana sen suosio on kasvanut niin paljon, että se on jatkuvasti sijoittunut joukkoon alustat. Kubernetes on tänä vuonna kolmas. Yhteenveto: Kubernetes on alusta, joka on suunniteltu konttityökuormien suorittamiseen ja järjestämiseen.
Kontit alkoivat erityisenä suunnitteluna prosessien eristämiseen Linuxissa; kontit ovat olleet mukana vuodesta 2007 lähtien , ja vuodesta 2002 lähtien – nimiavaruudet. Kontit suunniteltiin entistä paremmin vuoteen 2008 mennessä, jolloin se tuli saataville , ja Google kehitti oman sisäisen yritysmekanisminsa nimeltä , jossa "kaikki työ tehdään konteissa". Tästä siirrymme eteenpäin vuoteen 2013, jolloin Dockerin ensimmäinen julkaisu tapahtui, ja konteista tuli vihdoin suosittu massaratkaisu. Tuohon aikaan kontin orkestroinnin päätyökalu oli , vaikka hän ei ollutkaan kovin suosittu. Kubernetes julkaistiin ensimmäisen kerran vuonna 2015, minkä jälkeen tästä työkalusta tuli de facto standardi konttien orkestroinnin alalla.
Yrittääksemme ymmärtää, miksi Kubernetes on niin suosittu, yritämme vastata muutamaan kysymykseen. Milloin kehittäjät pystyivät viimeksi sopimaan sovellusten käyttöönotosta tuotantoon? Kuinka monta kehittäjää tiedät, jotka käyttävät työkaluja sellaisena kuin ne toimitetaan heti valmiina? Kuinka monta pilvijärjestelmänvalvojaa on nykyään, jotka eivät ymmärrä sovellusten toimintaa? Katsomme vastauksia näihin kysymyksiin tässä artikkelissa.
Infrastruktuuri kuten YAML
Maailmassa, joka siirtyi Puppet and Chefistä Kubernetesiin, yksi suurimmista muutoksista oli siirtyminen "infrastruktuurista koodina" "infrastruktuuriksi datana" - erityisesti, kuten YAML. Kaikki Kubernetesin resurssit, mukaan lukien podit, kokoonpanot, käyttöönotetut esiintymät, taltiot jne., voidaan kuvata helposti YAML-tiedostossa. Esimerkiksi:
apiVersion: v1
kind: Pod
metadata:
name: site
labels:
app: web
spec:
containers:
- name: front-end
image: nginx
ports:
- containerPort: 80Tämä näkymä helpottaa DevOps- tai SRE-ammattilaisten ilmaista työkuormiaan täysin ilman, että heidän tarvitsee kirjoittaa koodia kielillä, kuten Python tai Javascript.
Muita etuja infrastruktuurin järjestämisestä datana ovat:
- GitOps- tai Git Operations -versionhallinta. Tämän lähestymistavan avulla voit säilyttää kaikki Kubernetes YAML -tiedostot git-tietovarastoissa, jotta voit seurata tarkalleen, milloin muutos tehtiin, kuka sen teki ja mikä tarkalleen muuttui. Tämä lisää toiminnan läpinäkyvyyttä koko organisaatiossa ja parantaa toiminnan tehokkuutta poistamalla epäselvyyttä, erityisesti missä työntekijöiden tulee etsiä tarvitsemiaan resursseja. Samalla on helpompi tehdä muutoksia automaattisesti Kubernetes-resursseihin yksinkertaisesti yhdistämällä vetopyyntö.
- Skaalautuvuus. Kun resurssit määritellään YAMLiksi, klusterioperaattoreiden on erittäin helppoa muuttaa yhtä tai kahta numeroa Kubernetes-resurssissa, mikä muuttaa sen skaalausta. Kubernetes tarjoaa mekanismin podien vaakasuoraan automaattiseen skaalaukseen, jota voidaan käyttää kätevästi määrittämään, mikä vähimmäis- ja enimmäismäärä podeja vaaditaan tietyssä käyttöönottokokoonpanossa, jotta voidaan käsitellä matalaa ja suurta liikennettä. Jos olet esimerkiksi ottanut käyttöön kokoonpanon, joka vaatii lisäkapasiteettia äkillisen liikennepiikin vuoksi, maxReplicas voidaan muuttaa arvosta 10 arvoon 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- Turvallisuus ja hallinta. YAML on loistava tapa arvioida, kuinka asiat otetaan käyttöön Kubernetesissa. Esimerkiksi suuri turvallisuusongelma koskee sitä, ovatko työkuormasi käynnissä ei-järjestelmänvalvojana. Tässä tapauksessa saatamme tarvita työkaluja, kuten , YAML/JSON-validaattori, plus , käytännön validaattori varmistaakseen, että konteksti työkuormasi ei salli säilön ajaa järjestelmänvalvojan oikeuksilla. Jos tämä on tarpeen, käyttäjät voivat soveltaa yksinkertaista käytäntöä kuten tämä:
package main
deny[msg] {
input.kind = "Deployment"
not input.spec.template.spec.securityContext.runAsNonRoot = true
msg = "Containers must not run as root"
}- Integraatiovaihtoehdot pilvipalveluntarjoajan kanssa. Yksi tämän päivän huipputeknologian huomattavimmista trendeistä on työtaakka julkisilla pilvipalveluntarjoajilla. Komponentin käyttäminen Kubernetes sallii minkä tahansa klusterin integroitumisen pilvipalveluntarjoajan kanssa, jossa se toimii. Jos käyttäjä esimerkiksi käyttää sovellusta Kubernetesissa AWS:ssä ja haluaa paljastaa sovelluksen palvelun kautta, pilvipalveluntarjoaja auttaa luomaan palvelun automaattisesti.
LoadBalancerjoka tuottaa automaattisesti kuormantasaajan ohjata liikennettä sovelluskoteloihin.
Laajennettavuus
Kubernetes on erittäin laajennettava, ja kehittäjät rakastavat sitä. Käytettävissä on joukko resursseja, kuten podeja, käyttöönottoja, StatefulSets, salaisuudet, ConfigMaps, jne. Totta, käyttäjät ja kehittäjät voivat lisätä lomakkeeseen muita resursseja .
Esimerkiksi, jos haluamme määritellä resurssin CronTab, sitten voit tehdä jotain näin:
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
Myöhemmin voimme luoda CronTab-resurssin, jotakuinkin näin:
apiVersion: "my.org/v1"
kind: CronTab
metadata:
name: my-cron-object
spec:
cronSpec: "* * * * */5"
image: my-cron-image
replicas: 5
Toinen Kubernetesin laajennettavuusvaihtoehto on, että kehittäjä voi kirjoittaa omia lausuntojaan. on erityinen prosessi Kubernetes-klusterissa, joka toimii "" Käyttäjä voi operaattorin avulla automatisoida CRD:iden (custom Resource Definition) hallinnan vaihtamalla tietoa Kubernetes API:n kanssa.
Yhteisössä on useita työkaluja, joiden avulla kehittäjien on helppo luoda omia operaattoreita. Heidän joukossa - ja . Tämä SDK tarjoaa perustan, josta kehittäjä voi nopeasti aloittaa operaattorin luomisen. Oletetaan, että voit aloittaa komentoriviltä jotain tällaista:
$ operator-sdk new my-operator --repo github.com/myuser/my-operatorTämä luo kaikki yleiskoodit operaattorillesi, mukaan lukien YAML-tiedostot ja Golang-koodi:
.
|____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.goSitten voit lisätä tarvittavat API:t ja ohjaimet seuraavasti:
$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService
$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppServiceLopuksi kokoa operaattori ja lähetä se konttisi rekisteriin:
$ operator-sdk build your.container.registry/youruser/myapp-operator
Jos kehittäjä haluaa vielä enemmän hallintaa, Go-tiedostojen yleiskoodia voidaan muuttaa. Voit esimerkiksi muuttaa ohjaimen ominaisuuksia tekemällä muutoksia tiedostoon controller.go.
Toinen projekti , voit luoda lausekkeita käyttämällä vain deklaratiivisia YAML-tiedostoja. Esimerkiksi Apache Kafkan operaattori määritellään likimääräisesti . Sen avulla voit asentaa Kafka-klusterin Kubernetesin päälle vain muutamalla komennolla:
$ kubectl kudo install zookeeper
$ kubectl kudo install kafkaJa sitten määritä se toisella komennolla:
$ 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
innovaatiot
Muutaman viime vuoden aikana suuret Kubernetes-julkaisut ovat ilmestyneet muutaman kuukauden välein – eli kolmesta neljään pääjulkaisua vuodessa. Jokaisessa niistä esiteltyjen uusien ominaisuuksien määrä ei vähene. Lisäksi ei ole merkkejä hidastumisesta edes näinä vaikeina aikoina - katsokaa mikä tilanne on nyt .
Uusien ominaisuuksien avulla voit klusteroida toimintoja joustavammin erilaisiin työkuormiin. Lisäksi ohjelmoijat nauttivat paremmasta hallinnasta, kun he ottavat sovelluksia käyttöön suoraan tuotantoon.
Yhteisö
Toinen tärkeä näkökohta Kubernetesin suosiossa on sen yhteisön vahvuus. Vuonna 2015, kun Kubernetes saavutti version 1.0, sponsoroi .
Siellä on myös erilaisia yhteisöjä (Special Interest Groups) keskittyi työskentelemään Kuberneteksen eri osa-alueilla projektin kehittyessä. Nämä ryhmät lisäävät jatkuvasti uusia ominaisuuksia, mikä tekee Kubernetesin kanssa työskentelystä mukavampaa ja mukavampaa.
Cloud Native Foundation isännöi myös CloudNativeCon/KubeConia, joka on kirjoitushetkellä maailman suurin avoimen lähdekoodin konferenssi. Se järjestetään yleensä kolme kertaa vuodessa, ja se kokoaa yhteen tuhansia ammattilaisia, jotka haluavat parantaa Kubernetesia ja sen ekosysteemiä sekä oppia uusia ominaisuuksia, jotka ilmestyvät kolmen kuukauden välein.
Lisäksi Cloud Native Foundationilla on , joka yhdessä SIG:iden kanssa arvioi uusia ja olemassa olevia rahastot keskittyvät pilviekosysteemiin. Suurin osa näistä projekteista auttaa parantamaan Kubernetesin vahvuuksia.
Lopuksi uskon, että Kubernetes ei olisi yhtä menestyvä kuin se on ilman koko yhteisön tietoista panosta, jossa ihmiset pysyvät yhdessä, mutta samalla toivottavat uudet tulokkaat tervetulleiksi laumaan.
Tulevaisuus
Yksi suurimmista haasteista, joka kehittäjien on vastattava tulevaisuudessa, on kyky keskittyä itse koodin yksityiskohtiin, ei infrastruktuuriin, jossa se toimii. Se vastaa näihin trendeihin , joka on yksi johtavista nykyään. Kehittyneitä puitteita on jo olemassa, mm. и , jotka käyttävät Kubernetesia ottamaan infrastruktuurin pois kehittäjältä.
Tässä artikkelissa olemme vain raapineet Kubernetesin nykyisen tilan pintaa – itse asiassa se on vain jäävuoren huippu. Kubernetes-käyttäjillä on käytössään monia muita resursseja, ominaisuuksia ja kokoonpanoja.
Lähde: will.com