Du kan støte på et problem mens du setter opp en Kubernetes-klynge når du bare vet hvordan du bruker NodePort for å gjøre Kubernetes-tjenesten tilgjengelig over Internett. Når du bruker NodePort-tjenestetypen, vil et høyt portnummer bli tildelt, og du må tillate tilkoblinger til disse portene i brannmurregelen. Det er skadelig for infrastrukturen din, spesielt hvis serveren er tilgjengelig via det åpne Internett. Du kan tildele en blokk med IP-adresser utenfor klyngen som en klyngeadministrator som kan overføre trafikk til tjenester der. Dette er nøyaktig hva vi skal snakke om i denne artikkelen: å finne all viktig informasjon om hvordan du konfigurerer eksterne IP-er for nektetjenester i Kubernetes.
Hva er ekstern IP-tjeneste?
Ett av tjenesteendepunktene vil motta trafikk som kommer inn i klyngen ved å bruke den eksterne IP-en (som destinasjons-IP) og tjenesteporten. Kubernetes er ikke ansvarlig for å administrere ekstern IP.
Å sørge for hvilken IP som brukes for å få tilgang til Kubernetes-klyngen er avgjørende i denne situasjonen. Ved å bruke den eksterne IP-tjenestetypen kan vi binde tjenesten til IP-adressen som brukes for å få tilgang til klyngen.
Det faktum at Kubernetes-nettverket samhandler med Overlay-nettverket er viktig for å forstå denne situasjonen. Dette innebærer at du kan få tilgang til praktisk talt hver node i klyngen når du når en av nodene (master- eller arbeidernoden).
Nettverket vises på denne måten:
Både node 1 og 2 i diagrammet deler en enkelt IP-adresse. Den virkelige Poden bor på Node 1, men IP-adressen 1.2.3.6 er bundet til Nginx-tjenesten på Node 1. Node 1s IP-adresse, 1.2.3.4, er bundet til httpd-tjenesten, og Node 2s faktiske Pod er lokalisert der.
Dette er gjort mulig av Overlay-nettverkets fundament. Når vi krøller IP-adresse 1.2.3.4, skal httpd-tjenesten svare; når vi krøller 1.2.3.5, bør Nginx-tjenesten svare.
Fordeler og ulemper med ekstern IP
Her er fordelene og ulempene med ekstern IP:
Det er fordelaktig å bruke ekstern IP fordi:
-
- Din IP er fullstendig innenfor din kontroll. I stedet for å bruke skyleverandørens ASN, kan du bruke IP som tilhører ditt eget ASN.
Ulempene med ekstern IP inkluderer følgende:
-
- Det enkle oppsettet vi skal gå gjennom akkurat nå er IKKE veldig lett tilgjengelig. Dette innebærer at hvis noden svikter, vil tjenesten ikke lenger være tilgjengelig, og du må fikse problemet manuelt.
- For å håndtere IP-ene kreves det betydelig menneskelig arbeidskraft. Siden IP-ene ikke er dynamisk tildelt for deg, må du gjøre det manuelt.
Hva er standard fornekt/tillat atferd?
« Standard tillat ” angir at all trafikk er tillatt som standard. Med mindre det er spesifikt tillatt, nektes all trafikk som standard ved bruk av begrepet ' standard nekte .' unntatt når en nettverkspolicy er spesifisert.
-
- All trafikk til og fra en pod er tillatt hvis ingen nettverkspolicyer er i kraft for den poden.
- Hvis én eller flere nettverkspolicyer er i kraft for en pod av typen ingress, er bare den inngående trafikken som er eksplisitt tillatt av disse policyene, tillatt.
- Når en eller flere nettverkspolicyer gjelder for en pod av typen egress, er bare egress-trafikken tillatt av disse policyene tillatt.
Standardinnstillingen for andre endepunkttyper (VM-er, vertsgrensesnitt) er å blokkere trafikk. Bare trafikk som er spesifikt tillatt av nettverkspolicy er tillatt, selv om ingen nettverkspolicyer gjelder for endepunktet.
Beste praksis: Implisitt standard retningslinjer for avvisning
Du må konfigurere en implisitt standard avvisningspolicy opprettet for Kubernetes-podene dine. Dette sørger for at uønsket trafikk blokkeres automatisk. Husk at policyer for implisitt standardavvisning alltid trer i kraft sist; hvis andre retningslinjer tillater trafikk, gjelder ikke avslaget. Avslaget implementeres først etter at alle andre retningslinjer har blitt vurdert.
Hvordan lage en standard avvisningspolicy for Kubernetes Pods?
Vi anbefaler at du bruker den globale nettverkspolicyen selv om noen av følgende regler kan brukes til å konstruere en standard avvisningspolicy for Kubernetes-pods. En global nettverkspolicy brukes på alle arbeidsbelastninger (VM-er og containere) på tvers av alle navneområder og verter. En global nettverkspolicy oppfordrer til en forsiktig tilnærming til sikkerhet samtidig som ressursene forsvares.
-
- Aktiver standard for å nekte global nettverkspolicy, ikke-navnavstand
- Aktiver standard for å nekte nettverkspolicy, navneavstand
- Aktiver standard for å nekte Kubernetes-policy, navneavstand
Hva er IP-blokkering?
Med dette er spesifikke IP CIDR-områder valgt for å tillates som inngående kilder eller utgangsdestinasjoner. Gitt at Pod-IP-er er forbigående og uforutsigbare, bør disse være klyngeeksterne IP-er.
Kilde- eller destinasjons-IP-en til pakker må ofte skrives om når du bruker klyngeinngangs- og egressmetoder. Avhengig av den bestemte nettverksplugin-modulen (skytjenesteleverandør, tjenesteimplementering osv.) som brukes, kan virkemåten endres.
Dette gjelder for ingress, og det betyr at du i noen tilfeller må filtrere innkommende pakker som er basert på den faktiske kilde-IP-en. På den annen side kan 'kilde-IP-en' som NetworkPolicy fungerer på være IP-en til en LoadBalancer eller til og med Pod-noden, etc.
Dette viser at tilkoblinger mellom pods og tjeneste-IP-er som er omskrevet til klyngeeksterne IP-er kan bli utsatt for ipBlock-baserte begrensninger når det gjelder utgang.
Hva er standardretningslinjene?
All inn- og utgående trafikk til og fra pods i et navneområde er som standard tillatt hvis det ikke er noen kontroller på plass for det navneområdet. Du kan endre navneområdets standardoppførsel ved å bruke følgende eksempler.
Standard Nekt all inngående trafikk
Når du oppretter en nettverkspolicy som velger alle pods, men som ikke inkluderer innkommende trafikk til disse podene, kan du bygge en 'standard' inngangsisolasjonspolicy, og det er for et navneområde.
Dette sikrer at alle pods, uavhengig av om noen annen NetworkPolicy velger dem, er isolert for ingress. Denne regelen gjelder ikke for isolasjon for å gå ut av pod.
Standard avvis all utgående trafikk
Når du oppretter en NetworkPolicy som velger alle pods, men forbyr utgående trafikk fra disse podene, kan du bygge en 'standard' utgangsisoleringspolicy, og det er også for et navneområde.
Konklusjon
Denne veiledningen handlet om bruken av DenyServiceExternalIPs. Vi har også designet en diagrammatisk representasjon for å få brukerne våre til å forstå at den fungerer. Vi har også gitt eksempler på konfigurasjoner.