I slutten av mai holdt et nettmøte om temaet . Vi snakket om containere, Kubernetes og orkestrering i prinsippet, kriterier for valg av infrastruktur og mye mer. Deltakerne delte saker fra egen praksis.
Deltakere:
- Evgeniy Potapov, administrerende direktør i ITSumma. Mer enn halvparten av kundene flytter enten allerede eller ønsker å bytte til Kubernetes.
- Dmitry Stolyarov, CTO "Flant". Har 10+ års erfaring med å jobbe med containersystemer.
- Denis Remchukov (aka Eric Oldmann), COO argotech.io, ex-RAO UES. Han lovet å snakke om saker i den "blodige" bedriften.
- Andrey Fedorovsky, CTO "News360.com"Etter å ha kjøpt selskapet av en annen aktør, er han ansvarlig for en rekke ML- og AI-prosjekter og infrastruktur.
- Ivan Kruglov, systemingeniør, ex-Booking.com.Den samme personen som gjorde mye med Kubernetes med egne hender.
Temaer:
- Deltakernes innsikt om containere og orkestrering (Docker, Kubernetes, etc.); hva som ble prøvd i praksis eller analysert.
- Case: Selskapet bygger en infrastrukturutviklingsplan i årevis. Hvordan tas beslutningen om å bygge (eller migrere den nåværende) infrastrukturen til containere og Kuber eller ikke?
- Problemer i den skybaserte verden, hva som mangler, la oss forestille oss hva som vil skje i morgen.
En interessant diskusjon fulgte, meningene til deltakerne var så forskjellige og forårsaket så mange kommentarer at jeg vil dele dem med dere. Spise , og nedenfor er et sammendrag av diskusjonen.
Er Kubernetes allerede en standard eller god markedsføring?
«Vi kom til det (Kubernetes. - Red.) da ingen visste om det ennå. Vi kom til ham selv når han ikke var der. Vi ønsket det før" - Dmitry Stolyarov
Bilde fra Reddit.com
For 5-10 år siden var det et enormt antall verktøy, og det fantes ingen enkelt standard. Hvert halvår dukket det opp et nytt produkt, eller til og med mer enn ett. Først Vagrant, deretter Salt, Chef, Puppet, ... "og du bygger om infrastrukturen hver sjette måned. Du har fem administratorer som hele tiden er opptatt med å omskrive konfigurasjoner,” minnes Andrey Fedorovsky. Han mener at Docker og Kubernetes har "overfylt" resten. Docker har blitt en standard de siste fem årene, Kubernetes de siste to årene. Og det er bra for bransjen..
Dmitry Stolyarov og teamet hans elsker Kuber. De ville ha et slikt verktøy før det dukket opp, og kom til det når ingen visste om det. For øyeblikket, av bekvemmelighetshensyn, tar de ikke på seg en klient hvis de forstår at de ikke vil implementere Kubernetes med ham. Samtidig, ifølge Dmitry, har selskapet "mange gigantiske suksesshistorier om å gjenskape den forferdelige arven."
Kubernetes er ikke bare containerorkestrering, det er et konfigurasjonsstyringssystem med utviklet API, en nettverkskomponent, L3-balansering og Ingress-kontrollere, som gjør det relativt enkelt å administrere ressurser, skalere og abstrahere fra de nedre lagene av infrastrukturen.
Dessverre, i livet vårt må vi betale for alt. Og denne skatten er stor, spesielt hvis vi snakker om overgangen til Kubernetes av et selskap med en utviklet infrastruktur, slik Ivan Kruglov mener. Han kunne fritt jobbe både i et selskap med tradisjonell infrastruktur og med Kuber. Det viktigste er å forstå egenskapene til selskapet og markedet. Men for eksempel for Evgeny Potapov, som vil generalisere Kubernetes til ethvert containerorkestreringsverktøy, oppstår ikke et slikt spørsmål.
Evgeniy trakk en analogi med situasjonen på 1990-tallet, da objektorientert programmering dukket opp som en måte å programmere komplekse applikasjoner på. På den tiden fortsatte debatten og nye verktøy dukket opp for å støtte OOP. Så dukket mikrotjenester opp som en måte å bevege seg bort fra det monolittiske konseptet. Dette førte igjen til fremveksten av containere og containerstyringsverktøy. "Jeg tror at vi snart kommer til en tid hvor det ikke vil være noen tvil om det er verdt å skrive en liten mikrotjenesteapplikasjon, den vil bli skrevet som en mikrotjeneste som standard," mener han. Likeledes vil Docker og Kubernetes etter hvert bli standardløsningen uten behov for valg.
Problemet med databaser i statsløse
Photo by
I dag finnes det mange oppskrifter for å kjøre databaser i Kubernetes. Til og med hvordan skille delen som fungerer med I/O-disken fra, betinget, applikasjonsdelen av databasen. Er det mulig at databasene i fremtiden vil endre seg så mye at de vil bli levert i en boks, hvor en del vil bli orkestrert gjennom Docker og Kubernetes, og i en annen del av infrastrukturen, gjennom separat programvare, vil lagringsdelen bli levert ? Vil basene endres som et produkt?
Denne beskrivelsen ligner på køhåndtering, men kravene til pålitelighet og synkronisering av informasjon i tradisjonelle databaser er mye høyere, mener Andrey. Cache hit ratio i normale databaser forblir på 99 %. Hvis en arbeider går ned, lanseres en ny, og cachen "varmes opp" fra bunnen av. Inntil cachen er varmet opp, jobber arbeideren sakte, noe som betyr at den ikke kan lastes med brukerbelastning. Selv om det ikke er noen brukerbelastning, varmes ikke cachen opp. Det er en ond sirkel.
Dmitry er grunnleggende uenig - quorum og sharding løser problemet. Men Andrey insisterer på at løsningen ikke passer for alle. I noen situasjoner er quorum egnet, men det legger ekstra belastning på nettverket. En NoSQL-database er ikke egnet i alle tilfeller.
Meetup-deltakerne ble delt inn i to leire.
Denis og Andrey hevder at alt som er skrevet til disk - databaser og så videre - er umulig å gjøre i det nåværende Kuber-økosystemet. Det er umulig å opprettholde integriteten og konsistensen til produksjonsdata i Kubernetes. Dette er en grunnleggende funksjon. Løsning: hybrid infrastruktur.
Selv moderne skybaserte databaser som MongoDB og Cassandra, eller meldingskøer som Kafka eller RabbitMQ, krever vedvarende datalagre utenfor Kubernetes.
Evgeniy innvender: "Basene i Kubera er en nesten russisk, eller nesten bedriftsskade, som er assosiert med det faktum at det ikke er noen skyadopsjon i Russland." Små eller mellomstore bedrifter i Vesten er Cloud. Amazon RDS-databaser er enklere å bruke enn å fikse med Kubernetes selv. I Russland bruker de Kuber "on-premise" og overfører baser til den når de prøver å bli kvitt dyrehagen.
Dmitry var også uenig i påstanden om at ingen databaser kan holdes i Kubernetes: "Base er forskjellig fra base. Og hvis du pusher en gigantisk relasjonsdatabase, så under ingen omstendigheter. Hvis du skyver noe lite og skybasert, som er mentalt forberedt på halvflyktig liv, vil alt være bra.» Dmitry nevnte også at databaseadministrasjonsverktøy ikke er klare for verken Docker eller Kuber, så store vanskeligheter oppstår.
Ivan er på sin side sikker på at selv om vi abstraherer fra begrepene stateful og stateless, er økosystemet av bedriftsløsninger i Kubernetes ennå ikke klart. Med Kuber er det vanskelig å opprettholde lov- og forskriftskrav. For eksempel er det umulig å lage en identitetsleveringsløsning hvor det kreves strenge serveridentifikasjonsgarantier, helt ned til maskinvaren som settes inn i serverne. Dette området er i utvikling, men det er ingen løsning ennå.
Deltakerne klarte ikke å bli enige, så det vil ikke trekkes noen konklusjoner i denne delen. La oss gi et par praktiske eksempler.
Case 1. Cybersikkerhet av en «mega-regulator» med baser utenfor Kubera
Når det gjelder et utviklet cybersikkerhetssystem, gjør bruk av containere og orkestrering det mulig å bekjempe angrep og inntrenging. For eksempel, i en megaregulator, implementerte Denis og teamet hans en kombinasjon av en orkestrator med en trent SIEM-tjeneste som analyserer logger i sanntid og bestemmer prosessen med et angrep, hacking eller feil. I tilfelle et angrep, et forsøk på å plassere noe, eller i tilfelle en invasjon av løsepengevirus, plukker den, gjennom orkestratoren, opp containere med applikasjoner raskere enn de blir infisert, eller raskere enn angriperen angriper dem.
Tilfelle 2. Delvis migrering av Booking.com-databaser til Kubernetes
I Booking.com er hoveddatabasen MySQL med asynkron replikering – det er en master og et helt hierarki av slaver. Da Ivan forlot selskapet, ble et prosjekt lansert for å overføre slaver som kunne "skytes" med en viss skade.
I tillegg til hovedbasen er det en Cassandra-installasjon med egenskrevet orkestrering, som ble skrevet allerede før Kuber kom inn i mainstream. Det er ingen problemer i denne forbindelse, men det er vedvarende på lokale SSD-er. Ekstern lagring, selv innenfor samme datasenter, brukes ikke på grunn av problemet med høy latenstid.
Den tredje klassen av databaser er søketjenesten Booking.com, hvor hver tjenestenode er en database. Forsøk på å overføre søketjenesten til Kuber mislyktes, fordi hver node har 60-80 GB lokal lagring, som er vanskelig å "løfte" og "varme opp".
Som et resultat ble ikke søkemotoren overført til Kubernetes, og Ivan tror ikke det vil komme nye forsøk i nær fremtid. MySQL-databasen ble overført i to: bare slaver, som ikke er redde for å bli "skutt". Cassandra har satt seg perfekt til rette.
Infrastrukturvalg som en oppgave uten generell løsning
Photo by
La oss si at vi har et nytt selskap, eller et selskap hvor en del av infrastrukturen er bygget på den gamle måten. Den bygger en infrastrukturutviklingsplan for årevis. Hvordan tas avgjørelsen om det skal bygges infrastruktur på containere og Kuber eller ikke?
Selskaper som kjemper i nanosekunder er ekskludert fra diskusjonen. Sunn konservatisme lønner seg når det gjelder pålitelighet, men det er fortsatt selskaper som bør vurdere nye tilnærminger.
Ivan: "Jeg ville definitivt startet et selskap på skyen nå, rett og slett fordi det er raskere," selv om det ikke nødvendigvis er billigere. Med utviklingen av venturekapitalisme har startups ingen store problemer med penger, og hovedoppgaven er å erobre markedet.
Ivan mener det utbygging av dagens infrastruktur er et utvalgskriterium. Hvis det har vært en seriøs investering i fortiden, og den fungerer, så er det ingen vits i å gjøre det om. Hvis infrastrukturen ikke er utviklet, og det er problemer med verktøy, sikkerhet og overvåking, så er det fornuftig å se på en distribuert infrastruktur.
Skatten må uansett betales, og Ivan ville betale den som tillot ham å betale mindre i fremtiden. "For rett og slett i kraft av at jeg kjører på et tog som andre flytter, vil jeg reise mye lenger enn om jeg sitter på et annet tog, som jeg selv må fylle på.sier Ivan. Når selskapet er nytt, og latenskravene er titalls millisekunder, vil Ivan se mot "operatørene" som klassiske databaser er "pakket inn" i i dag. De oppretter en replikeringskjede, som bytter seg selv i tilfelle failover osv...
For et lite selskap med et par servere gir Kubera ingen mening, sier Andrey. Men hvis den planlegger å vokse til hundrevis av servere eller flere, trenger den automatisering og et ressursstyringssystem. 90 % av tilfellene er verdt prisen. Dessuten, uavhengig av belastningsnivå og ressurser. Det er fornuftig for alle, fra startups til store selskaper med et publikum på millioner, å gradvis se mot containerorkestreringsprodukter. "Ja, dette er virkelig fremtiden," er Andrey sikker.
Denis skisserte to hovedkriterier - skalerbarhet og driftsstabilitet. Han vil velge de verktøyene som er best egnet for oppgaven. "Det kan være et noname satt sammen på knærne dine, og det har Nutanix Community Edition på seg. Dette kan være en andre linje i form av en applikasjon på Kuber med en database på backend, som er replikert og har spesifiserte RTO- og RPO-parametere" (gjenopprettingstid/punktmål - ca.).
Evgeniy identifiserte et mulig problem med personell. For øyeblikket er det ikke mange høyt kvalifiserte spesialister på markedet som forstår "guts". Faktisk, hvis den valgte teknologien er gammel, er det vanskelig å ansette andre enn middelaldrende mennesker som er lei og lei av livet. Selv om andre deltakere mener at dette er snakk om opplæring av personell.
Hvis vi stiller spørsmålet om valg: å lansere et lite selskap i Public Cloud med databaser i Amazon RDS eller "on premise" med databaser i Kubernetes, så til tross for noen mangler, var valget til deltakerne Amazon RDS.
Siden flertallet av meetup-lytterne ikke er fra den "blodige" bedriften, altså distribuerte løsninger er det vi bør strebe etter. Datalagringssystemer må være distribuerte, pålitelige og skape latens målt i enheter på millisekunder, maks.", oppsummerte Andrey.
Vurdere Kubernetes-bruk
Lytteren Anton Zhbankov stilte et fellespørsmål til Kubernetes-apologeter: hvordan valgte og gjennomførte du en mulighetsstudie? Hvorfor Kubernetes, hvorfor ikke virtuelle maskiner, for eksempel?
Photo by
Dmitry og Ivan svarte på det. I begge tilfeller, gjennom prøving og feiling, ble det tatt en rekke avgjørelser, som et resultat av at begge deltakerne ankom Kubernetes. Nå begynner bedrifter å uavhengig utvikle programvare som er fornuftig å overføre til Kuber. Vi snakker ikke om klassiske tredjepartssystemer, som 1C. Kubernetes hjelper når utviklere raskt må lage utgivelser, med kontinuerlig kontinuerlig forbedring.
Andreys team prøvde å lage en skalerbar klynge basert på virtuelle maskiner. Noder falt som dominobrikker, noe som noen ganger førte til sammenbruddet av klyngen. "Teoretisk sett kan du gjøre det ferdig og støtte det med hendene, men det er kjedelig. Og er det en løsning på markedet som lar deg jobbe ut av boksen, så går vi gjerne for det. Og vi byttet som et resultat, sier Andrey.
Det finnes standarder for slik analyse og beregning, men ingen kan si hvor nøyaktige de er på ekte maskinvare i drift. For beregninger er det også viktig å forstå hvert verktøy og økosystem, men dette er ikke mulig.
Hva venter oss
Photo by
Etter hvert som teknologien utvikler seg, dukker det opp flere og flere forskjellige deler, og så skjer en faseovergang, en leverandør dukker opp som har drept nok deig til at alt kan samles i et enkelt verktøy.
Tror du det vil komme en tid da det kommer et verktøy som Ubuntu for Linux-verdenen? Kanskje vil et enkelt containeriserings- og orkestreringsverktøy inkludere Kuber. Det vil gjøre det enkelt å bygge skyer på stedet.
Svaret ble gitt av Ivan: "Google bygger nå Anthos - dette er deres pakketilbud som distribuerer skyen og inkluderer Kuber, Service Mesh, overvåking - all maskinvaren som er nødvendig for lokale mikrotjenester." Vi er nesten i fremtiden."
Denis nevnte også Nutanix og VMWare med vRealize Suite-produktet, som kan takle en lignende oppgave uten containerisering.
Dmitry delte sin mening om at å redusere "smerten" og redusere skatter er to områder hvor vi kan forvente forbedringer.
For å oppsummere diskusjonen fremhever vi følgende problemer med moderne infrastruktur:
- Tre deltakere identifiserte umiddelbart et problem med stateful.
- Ulike sikkerhetsstøtteproblemer, inkludert muligheten for at Docker vil ende opp med flere versjoner av Python, applikasjonsservere og komponenter.
Overforbruk, som er bedre å diskutere i et eget møte.
En læringsutfordring da orkestrering er et komplekst økosystem.
Et vanlig problem i bransjen er misbruk av verktøy.Resten av konklusjonene er opp til deg. Det er fortsatt en følelse av at det ikke er lett for Docker+Kubernetes-kombinasjonen å bli en «sentral» del av systemet. For eksempel installeres operativsystemer på maskinvare først, noe som ikke kan sies om containere og orkestrering. Kanskje i fremtiden vil operativsystemer og containere fusjonere med programvare for skyadministrasjon.
Photo byJeg vil benytte anledningen til å hilse på mamma og minne om at vi har en Facebook-gruppe , kanal med interessante publikasjoner fra ulike teknologiblogger. Og kanalen min , hvor jeg snakker om å styre utvikling i produktselskaper.
Kilde: www.habr.com