Ingress

Question 1

wat is ingress

Answer 1

een Kubernetes-resource die het mogelijk maakt om HTTP- en HTTPS-verkeer van buiten het cluster naar specifieke applicaties binnen het cluster te sturen. Het zorgt voor routing van inkomend verkeer naar de juiste service, afhankelijk van de URL of het domein.

Question 2

wat zijn de 3 belangrijste onderdelen van Ingress?

Answer 2

• ingress resource
• ingress controller
• service

Question 3

wat is een ingress resource?

Answer 3

Dit is een Kubernetes-object (specificeer je routing-regels) dat je aanmaakt om te bepalen hoe het verkeer naar je services moet worden geleid.

Question 4

wat is een ingress controler?

Answer 4

Dit is een component die in je cluster draait en verantwoordelijk is voor het daadwerkelijk verwerken van de Ingress-regels. Het zorgt ervoor dat verkeer via de juiste poort (meestal 80 voor HTTP en 443 voor HTTPS) naar de juiste services wordt gestuurd.

Question 5

wat is een service?

Answer 5

Dit zijn de applicaties binnen je cluster die je wilt bereiken via Ingress. Elke service heeft een specifieke URL of pad dat je in de Ingress-regels definieert.

Question 6

Wat is het verschil tussen een Ingress en een Service in Kubernetes

Answer 6

Een Service biedt een interne netwerktoegang tot applicaties binnen het cluster, terwijl een Ingress inkomend verkeer van buiten het cluster naar de services binnen het cluster routet op basis van regels (bijvoorbeeld URL-paden en domeinen).

Question 7

Hoe installeer je een Ingress Controller in een Kubernetes-cluster?

Answer 7

n Ingress Controller kan meestal worden geïnstalleerd met behulp van een Helm-chart, kubectl, of via een specifieke YAML-manifest van bijvoorbeeld NGINX, Traefik of andere controllers. Voor NGINX kan het bijvoorbeeld via deze stap:

bash
Code kopiëren
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/cloud/deploy.yaml

Question 8

Wat doet de host-parameter in een Ingress-regel?

Answer 8

De host-parameter specificeert het domein of de subdomeinen waarop de Ingress-regels van toepassing zijn. Bijvoorbeeld, www.mijnsite.com of api.mijnsite.com.

Question 9

Wat is het verschil tussen de path en pathType in een Ingress-resource?

Answer 9

De path geeft het URL-pad aan waarop de Ingress-regel moet matchen, bijvoorbeeld /api/*.
De pathType bepaalt hoe de padvergelijking wordt uitgevoerd:
Prefix: Het pad moet beginnen met de opgegeven waarde.
Exact: Het pad moet exact overeenkomen met de opgegeven waarde.
ImplementationSpecific: Het pad wordt bepaald door de Ingress Controller.

Question 10

welke pathTypes zijn er?

Answer 10

Prefix: Het pad moet beginnen met de opgegeven waarde.
Exact: Het pad moet exact overeenkomen met de opgegeven waarde.
ImplementationSpecific: Het pad wordt bepaald door de Ingress Controller.

Question 11

Kun je meerdere regels in één Ingress-resource gebruiken?

Answer 11

Ja, je kunt meerdere regels toevoegen in één Ingress-resource om verkeer naar verschillende services te routeren op basis van verschillende hosts of paden.

Question 12

Kun je SSL-terminatie configureren met een Ingress?

Answer 12

Ja, je kunt SSL-terminatie configureren door een TLS-secret te maken en dit te verwijzen in de Ingress-resource. Het stelt de Ingress-controller in staat om HTTPS-verkeer af te handelen en het als HTTP naar de achterliggende services door te sturen.

Question 13

Wat is een backend in een Ingress-resource?

Answer 13

De backend definieert de service en de poort naar welke het verkeer wordt gestuurd wanneer het overeenkomt met de Ingress-regels (bijvoorbeeld een specifieke host of pad)

Question 14

Wat gebeurt er als je meerdere Ingress-resources hebt voor dezelfde host?

Answer 14

Als meerdere Ingress-resources voor dezelfde host bestaan, kan de Ingress Controller afhankelijk van zijn configuratie conflicten oplossen. Sommige controllers gebruiken de regels op volgorde van definitie, terwijl andere de regels combineren. Het is aanbevolen om duidelijke en unieke Ingress-regels te definiëren om conflicten te vermijden.

Question 15

Kun je Ingress gebruiken met een LoadBalancer-type Service?

Answer 15

Ja, je kunt Ingress gebruiken met een LoadBalancer-type Service. In dit geval wordt het externe verkeer naar de LoadBalancer gestuurd, die dan door de Ingress Controller naar de juiste service binnen het cluster wordt gerouteerd.

Question 16

Hoe kun je een Ingress-regel testen?

Answer 16

Je kunt een Ingress-regel testen door het domein of IP-adres waarop het verkeer wordt verwacht aan te roepen in een webbrowser of met tools zoals curl. Zorg ervoor dat de Ingress Controller actief is en de regels correct zijn toegepast.

Question 17

Kun je Ingress gebruiken om niet-HTTP-verkeer, zoals TCP of UDP, te routeren?

Answer 17

Nee, Ingress is bedoeld voor HTTP(S)-verkeer. Voor niet-HTTP-verkeer zoals TCP of UDP, gebruik je Services van het type ClusterIP, NodePort of LoadBalancer, afhankelijk van de behoeften van je applicatie.

Question 18

verschil tussen ingress en egress

Answer 18

ingress is verkeerd dat naar je pod toe komt. egress is verkeer dat uit je pod vertrekt.

Question 19

networkpolicy: netwerkbeleid is?

Answer 19

helpt om te regelen welk verkeer je pods binnen het cluster kunnen ontvangen of versturen.

Question 20

hoe werkt networkpolicy

Answer 20

Het werkt met labels en selectors om te bepalen welke pods met elkaar kunnen communiceren.

Question 21

Wat is het verschil tussen een podSelector en een namespaceSelector in een netwerkbeleid

Answer 21

Een podSelector selecteert pods op basis van labels binnen een bepaalde namespace, terwijl een namespaceSelector pods selecteert op basis van de namespace waarin ze zich bevinden. Bijvoorbeeld, je kunt een namespaceSelector gebruiken om verkeer alleen van pods in een specifieke namespace (zoals prod) toe te staan, terwijl de podSelector bepaalt welke pods binnen die namespace toegang hebben.

Question 22

Wat als je een externe server (zoals een back-up server) toegang wilt geven tot de databasepod?

Answer 22

Als de externe server geen pod is binnen het Kubernetes-cluster, kun je een ipBlock gebruiken in je netwerkbeleid. Hiermee kun je een specifiek IP-adres (bijvoorbeeld het IP van de back-up server) toestaan om verbinding te maken met de databasepod.

Question 23

Hoe kun je meerdere API-pods in verschillende namespaces beperken tot alleen toegang tot de databasepod in de prod namespace?

Answer 23

Je kunt dit doen door zowel een podSelector als een namespaceSelector toe te voegen aan het netwerkbeleid. De podSelector zorgt ervoor dat alleen de API-pods toegang hebben, en de namespaceSelector zorgt ervoor dat alleen de API-pods in de prod namespace toegang krijgen tot de databasepod.

Question 24

Wat gebeurt er als je geen namespaceSelector of podSelector gebruikt in een netwerkbeleid?

Answer 24

Als je geen namespaceSelector of podSelector gebruikt, zou dit betekenen dat alle pods binnen de opgegeven namespace toegang kunnen krijgen tot de databasepod, ongeacht de labels van de pods. Dit is meestal niet wenselijk, omdat het te breed kan zijn en ongewenst verkeer kan toestaan.

Question 25

Waarom zou je zowel een namespaceSelector als een podSelector gebruiken?

Answer 25

Je zou beide selectors gebruiken als je zowel de namespace als de labels van de pods wilt controleren. Bijvoorbeeld, je wilt alleen verkeer toestaan van API-pods in de prod namespace met een specifiek label (zoals rol: api). Dit maakt je netwerkbeleid strikter en veiliger.

Question 26

Wat moet je doen als je een back-upserver buiten het Kubernetes-cluster hebt en deze toegang wilt geven tot de databasepod?

Answer 26

Als de back-upserver buiten het Kubernetes-cluster is, kun je een ipBlock gebruiken in het netwerkbeleid. Hiermee kun je verkeer toestaan van een specifiek IP-adres (bijvoorbeeld het IP van de back-upserver) naar de databasepod.