Sådan kommer Istio i gang

Og de skøre ting, du kan gøre, når det er.

Et faktisk billede af mig, da Kiali begyndte at arbejde

I det øjeblik du får Istio til at arbejde på din klynge, føles det som om du har taget et ret alvorligt spring fremad. Niveauet for overvågning, sikkerhed og funktionalitet, du straks får, er lysår foran konkurrencen. For et par måneder siden tog vi springet og installerede Istio på vores Kubernetes-klynge og ... hot damn. Vi begynder i begyndelsen med installation og de faldgruber, vi fandt, derefter en oversigt over de værktøjer, vi har fundet mest nyttige.

At få motoren til at køre.

Den nemmeste og mest effektive måde at installere Istio er at bruge Helm-diagrammet. Du får en produktionsklar installation ud af kassen. Du har et par muligheder, men Istio leverer en praktisk download-kommando, så du kan trække et versioneret bundt af Istio Helm-diagrammet ned. Følgende får dig version 1.0.6 af Istio-pakken.

krølle -L https://git.io/getLatestIstio | ISTIO_VERSION = 1.0.6 sh -

Inden i dette downloadede bundt er et praktisk lille roret kort. Det er placeret i install / kubernetes / helm / istio. Når du først er i dette bibliotek, er det en simpel rorinstallation. Vi foretrækker at bruge helm-opgradering - installere i stedet for en lige-up-installation, så den samme kommando kan automatiseres:

roderopgradering istio. -f-værdier.yaml \
- navneområde istio-system \
--installere

Dette vil bruge standardværdierne.yaml-filen, der findes i mappen. Du kan ændre denne fil for at tænde eller slukke for forskellige funktioner.

En note om afinstallation af Istio

Sund fornuft ville diktere, at en roret slette - purge istio ville fjerne alle Istio-ressourcerne, men det fjerner ikke CustomResourceDefinition-typerne. Vi måtte grave rundt og slette CRD’erne manuelt. Vi endte med at scriptere dette. Bare noget at huske på.

Når det var installeret, konfigurerede vi nogle slutpunkter og begyndte at gennemgå, hvad vores nye klynge kunne gøre. Åh dreng, vi blev ikke skuffede.

Konfiguration af Istio

Den sidste ting at gøre er at kommentere et navneområde for at indikere, at Istio kan udføre automatisk sidevogninjektion. Dette er den enkleste måde at bruge Istio på. Bemærkningen er enkel. Et eksempel på et navneområde, du kan bruge, er følgende:

apiVersion: v1
kind: Navneområde
metadata:
    navn: mit navneområde
etiketter:
    istio-injektion: aktiveret

Alle applikationer, der distribueres i dette navneområde, får en udsending-proxy. Denne proxy analyserer din netværkstrafik og offentliggør på Istio Prometheus-serveren, hvor downstream-systemer kan gøre brug af den.

Hvordan ved jeg, om jeg har en udsendingsproxy?

Enkel, kub kubectl få pods inden for det ønskede navneområde. Du kan se noget lignende:

my-application-pod 2/2 Running 0 2d

Hvis du antager, at du kun implementerer en container pr. Pod, vises en anden container nu. Denne anden container er din udsending-proxy. Hvis den er der, og den er klar, er du god til at gå.

Kiali

Jeg kommer lige ud af porten med min favorit. Kiali leverer live netværksdiagrammer og HTTP-statistikker til dine applikationer. Det er en ægte crowd pleaser, og det giver dig et fremragende "hurtigt overblik" instrumentbræt.

Kiali giver dig seriøs synlighed

Se på højre side af dette billede. Oven på det høje synlighedsniveau får du detaljer. Du kan sætte netværksoversigten på en tv-skærm. Når en af ​​disse linjer bliver rød, kan du grave i HTTP-detaljerne under hætten.

Gennemsøg af Kiali

Du kan se trafik, der kommer fra “ukendt” i kiali, som denne:

Er det en hacker !?

Dette er faktisk Kubernetes sundhedstjek. Det er intet at være bekymret for. Du kan skjule dette ved at gøre en af ​​nogle få ting:

  • Juster din sundhedscheck for at bruge en lokal exec på dockercontaineren i stedet for en HTTP-baseret check. Dette er en smule hacky.
  • Brug en anden port end din vigtigste applikationsport til din sundhedscheck. Dette er den retning, vi er gået i, som også åbner en anden dør for (mere om dette senere)

Istio arbejder på dette, og der er en løsning i den splinternye version 1.1.

Grafana

Istio udfylder en Grafana-instans straks for dig. Dette Grafana-eksempel er absolut fyldt med nyttige applikationsmetrics, drevet af de data, der er offentliggjort fra hver applikations udsendingsproxy.

Så snart du implementerer en ny applikation med en udsendingsproxy, får du målinger, der typisk tager hold uger at sammensætte:

Ååååå.

Det er vigtigt at genkende, jeg konfigurerede ikke noget af dette. Istio er nok involveret i dit system til at trække alt dette ud for dig. Og for at fjerne det, er dette et af mange betjeningspaneler. Der er masser af dem, mere end jeg tror, ​​jeg nogensinde vil bruge. I tilfælde af overvågning er mere mere. Jeg vil hellere have for meget detaljer og tone det ned end overhovedet ingen synlighed.

Prometheus

Dette er motoren bag alt hvad der foregår. Prometheus skraber og aggregerer store mængder data og præsenterer dem på en bekvem måde. Jeg havde ikke brug for en enorm mængde tid på at lege med det for at fortælle dig sandheden. Istio-tjenesterne leverer nogle utroligt nyttige ud af boksen-funktionalitet. Prometheus kan bruges til at skrive dine egne grafer eller skrabe tilpassede målinger fra dine applikationer.

Fra bagsiden af ​​disse data kan du udløse alarmer ved hjælp af Alert Manager og skabe meget sofistikeret overvågnings- og alarmeringsplatform til dine applikationer.

Den kontrol, du får

Oven på alt dette har Istio nogle bagt værktøjer, der virkelig skubber grænsen. Du kan udløse fejl, forårsage driftsforstyrrelser, sort hultrafik og meget mere. Jeg har beskrevet nogle af de seje funktioner, som jeg har haft en chance for at spille med, men der er langt flere.

Injektion af fejl

Med Istio kan du injicere fejl. F.eks. Vil følgende YAML forårsage 100% af anmodningerne om at returnere en HTTP-statuskode på 500. Nyttig til, når du simulerer et tredjepartsafbrydelse.

apiVersion: networking.istio.io/v1alpha3
type: VirtualService
metadata:
   navn: ratings
spec:
   værter:
   - vurderinger
   http:
   - fejl:
       abort:
         httpStatus: 500
         procent: 100
     match:
     - overskrifter:
         slutbruger:
           nøjagtigt: json
     rute:
     - destination:
         vært: ratings
         undergruppe: v

Dokumentationen er temmelig god, og du kan dykke ned i alle muligheder for denne funktionalitet. Det, jeg gør her, er blot at vise dig overfladen.

Modstandsdygtighedspolitikker som standard

Hvor ofte har du skrevet logik til implementering af forsøg? Ved at indlæse alt dette i et produkt gør det vanskeligt at fokusere på den specifikke forretningsværdi. Istio gør dette enklere. For eksempel ved at bage genforsøg i:

apiVersion: networking.istio.io/v1alpha3
type: VirtualService
metadata:
    navn: ratings
spec:
    værter:
      - vurderinger
    http:
      - rute:
        - destination:
          vært: ratings
          delmængde: v1
        forsøg:
          forsøg: 3
          perTryTimeout: 2s

Dette vil sikre, at anmodninger fra din tjeneste gentages tre gange med en timeout på to sekunder i hver. Ikke mere forurening af din applikationskode - indlæs dette i servicenettet og hold dine tjenester enkle.

Gensidig TLS

Service til servicekryptering kan være hård. Det er en seriøs handling at sikre, at certifikater ikke udløber… men ikke med Istio. Istio bruger certifikathåndteringspoden for at sikre, at dine applikationer har deres helt eget, skinnende certifikat.

Derefter kan du med den korrekte DestinationRule give mandat til, at dine applikationer kun tillader TLS-krypteret trafik. Dette sikrer, at al kommunikation mellem klynger er låst. Applikationen har ikke en anelse. Det udsender anmodningen i HTTP, og Envoy-proxy-sidevognen vil gennemsigtig opgradere den til gensidig TLS. Den følgende destinationsregel sikrer, at alle anmodninger til v1 af produktsidetjenesten skal krypteres ved hjælp af gensidig TLS.

apiVersion: networking.istio.io/v1alpha3
type: DestinationRulemetadata:
  navn: produktside
spec:
  vært: produktside
  trafficPolicy:
    tls:
      tilstand: ISTIO_MUTUAL
  delmængder:
  - navn: v1
    etiketter:
      version: v1

Der er ikke sådan noget som en gratis frokost

Som med alt er der nogle farer og afvejninger. Istio er strålende, jeg er grundigt imponeret. Det er nemt at gå af skinnerne og finde dig selv med et servicemask frem for et servicemesh.

Smarte integrationslag

Enhver, der har arbejdet i en tilstrækkelig stor organisation, vil have set dette. “Integrationslag”, der oprindeligt er designet til at knytte to applikationer sammen. Derefter får de en lille ekstra logik, et par filer her og der, nogle dirigeringsregler dryssede over toppen og pludselig er de et reden af ​​kompleksitet.

Vær forsigtig med Istio i denne henseende. Det er enormt kraftfuldt, men kræver omhyggelig tanke. Nogle funktioner er seje, men du har muligvis ikke brug for dem. Og nogle gange, tør jeg sige det, er en lille gentagelse i mikroservices mere ønskværdig end et servicenet med mere logik i det end dine faktiske applikationer.

kompleksitet

Kubernetes tilbyder meget at lære. Læringskurven er ret venlig, især sammenlignet med alternativerne, men domænet er bredt. Når du introducerer Istio, introducerer du også en række nye, mere komplekse koncepter. VirtualService og Gateway-typer af tilpassede ressource-definitioner, som du bliver nødt til at blive komfortabel med.

Dette er en afvejning. Se på din klynge eller dit team, og vælg. Er vores overvågning udført af jobbet perfekt? Er vores applikationer modstandsdygtige? Klager ingeniørerne sig over gentagelsen af ​​logik? Sørg for, at du får noget til gengæld for denne kompleksitet, og at denne handel er en no-brainer. Bare ikke søvnvandring i et mareridt.

Det ændrer sig ... hurtigt

Istio har for nylig annonceret, at det er produktionsklar, og med sin 1.1-frigivelse adresseret mange af de eksisterende bekymringer. Når det er sagt, er dette et nyt produkt. Hvis du er den type organisation, der kæmper for at holde trit, kan det tempo, som Istio bevæger sig, være en skade for dig. At falde bagud kan være katastrofalt, især hvis sikkerhedssårbarheder og fejl opstår.

Igen er dette en byrde, du har brug for at resonnere over. Har du evnen til at følge med? Hvis ikke, kan du da? Og selvom du kunne, er det værd? Har du virkelig brug for denne ekstra operationelle overhead?

Det var alt folkens

Jeg har givet højdepunkterne i min oplevelse med Istio. Jeg har personligt brugt al funktionalitet i denne artikel, og den har været enestående. Vi har set den underlige sære eller to, men intet der har givet os meget pause til tanke. Alt i alt, forudsat at du har en situation, der har brug for den, tager Istio din klynge til det næste niveau.

Jeg taler regelmæssigt om Istio, Kubernetes og DevOps på min twitter-konto.