Changes between Version 6 and Version 7 of k8snetworking2023


Ignore:
Timestamp:
Dec 8, 2023, 2:47:41 PM (3 years ago)
Author:
admin
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • k8snetworking2023

    2 3 4 6 7 10 11 15 16 23 24 26 27 28 32 33 50 51 52 53 66 67 72 73 102 103 107 108 111 112 119 120 122 123 133 134 145 146 148 149 151 152 154 155 156 157 159 160 183 184 186 187 194 195 200 201 204 205 212 213
    v6 v7  
    1 '''Issuing a Virtual IP to a Service Using MetalLB on Kubernetes'''
     1== Issuing a Virtual IP to a Service Using MetalLB on Kubernetes ==
    2
    3MetalLB is a load balancer implementation for bare metal Kubernetes clusters, using L2 advertisements. This tutorial will guide you through the process of setting up MetalLB in your Kubernetes cluster and assigning a virtual IP to a service.
    4
    5 '''Step 1: Install MetalLB'''
     5=== Step 1: Install MetalLB ===
    6
    7MetalLB can be installed via a manifest or using Helm. We'll use the manifest method here.
    … …  
    10
    11{{{
    12 kubectl apply -f
    13 https://raw.githubusercontent.com/metallb/metallb/v0.13.12/con
    14 fig/manifests/metallb-native.yaml
     12#!sh
     13kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.13.12/config/manifests/metallb-native.yaml
     14
    15}}}
    16
    … …  
    23You should see the MetalLB pods running.
    24
    25 '''Step 2: Configure MetalLB'''
     25=== Step 2: Configure MetalLB ===
    26
    27MetalLB can operate in either Layer 2 mode or BGP mode. We'll use Layer 2 mode for simplicity.
    28
    29 ''1. Create a ConfigMap for MetalLB: Define a range of IP addresses that MetalLB will manage. Create a file named `metallb-pool.yaml` with the following content:''
    30 
    31 {{{
     29''1. Create a !ConfigMap for MetalLB: Define a range of IP addresses that MetalLB will manage. Create a file named `metallb-pool.yaml` with the following content:''
     30
     31{{{
     32#!python
    33apiVersion: metallb.io/v1beta1
    34kind: IPAddressPool
    … …  
    51
    52{{{
     53#!python
    54apiVersion: metallb.io/v1beta1
    55kind: L2Advertisement
    … …  
    68'''Step 3: Create a Service with a Virtual IP'''
    69
    68 Let’s expose the wordpress application: Edit the service of type LoadBalancer on
    69 wordpress-service.yaml:
    70 
    71 {{{
     70Let’s expose the wordpress application: Edit the service of type !LoadBalancer on `wordpress-service.yaml`:
     71
     72{{{
     73#!python
    74apiVersion: v1
    75kind: Service
    … …  
    104On a different VM than the master do the testing for ARP advertisements.
    105
    104 Remove MetalLB (Only for the reference)
    105 
    106 {{{
     106Remove !MetalLB (Only for the reference)
     107
     108{{{
     109#!sh
    110arp -a
    111ping 192.168.1.200
    … …  
    114}}}
    115
    113 Remove MetalLB (Only for the reference)
    114 
    115 {{{
    116 kubectl delete -f
    117 https://raw.githubusercontent.com/metallb/metallb/v0.13.12/con
    118 fig/manifests/metallb-native.yaml
     116Remove !MetalLB (Only for the reference)
     117
     118{{{
     119#!sh
     120kubectl delete -f https://raw.githubusercontent.com/metallb/metallb/v0.13.12/config/manifests/metallb-native.yaml
    121kubectl delete -f metallb-pool.yaml
    122kubectl delete -f L2add.yaml
    … …  
    124}}}
    125
    124 === Kubernetes Ingress. (Optional) ===
    125 
    126 In a Kubernetes environment, if you want to use an Ingress resource to direct traffic to a service that's exposed via NodePort, while still allowing users to access the service using a standard port (like port 80) without specifying the NodePort, you can set it up as follows:
    127 
    128 '''Step 1: Expose Your Service Using NodePort'''
    129 
    130 ''1. Create a Service of Type NodePort for Your Web Application: Suppose you have a deployment named webapp. You'll need to create a service for it. Here's an example YAML for the service:''
    131 
    132 {{{
     126
     127== Kubernetes Ingress. (Optional) ==
     128
     129In a Kubernetes environment, if you want to use an Ingress resource to direct traffic to a service that's exposed via !NodePort, while still allowing users to access the service using a standard port (like port 80) without specifying the !NodePort, you can set it up as follows:
     130
     131=== Step 1: Expose Your Service Using !NodePort ===
     132
     133''1. Create a Service of Type !NodePort for Your Web Application: Suppose you have a deployment named webapp. You'll need to create a service for it. Here's an example YAML for the service:''
     134
     135{{{
     136#!python
    137apiVersion: v1
    138kind: Service
    … …  
    149}}}
    150
    147 This service will expose your webapp on a NodePort.
     151This service will expose your webapp on a !NodePort.
    152
    153• Apply the Service:
    … …  
    155`kubectl apply -f [your-service-file].yaml`
    156
    153 '''Step 2: Set Up Ingress to Route to the NodePort Service'''
     157=== Step 2: Set Up Ingress to Route to the !NodePort Service ===
    158
    159''1. Define an Ingress Resource: Create an Ingress resource that routes traffic to your NodePort service. Here's an example YAML for the Ingress:''
    160
    161{{{
    158 
     162#!python
    163apiVersion: networking.k8s.io/v1
    164kind: Ingress
    … …  
    187
    188
    185 '''Step 3: Ensure Ingress Controller is Set Up Correctly'''
     189=== Step 3: Ensure Ingress Controller is Set Up Correctly ===
    190
    191Ensuring that your Ingress Controller is properly set up and accessible from outside the Kubernetes cluster involves several key steps. This setup is crucial for allowing external traffic to reach your services through the Ingress rules you've defined. Here's a breakdown of what this entails:
    … …  
    198
    199{{{
    196 kubectl apply -f
    197 https://raw.githubusercontent.com/kubernetes/ingress-
    198 nginx/controller-
    199 v1.8.2/deploy/static/provider/cloud/deploy.yaml
     200#!sh
     201kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.8.2/deploy/static/provider/cloud/deploy.yaml
     202
    203}}}
    204''
    … …  
    207
    208• Service Type: The Ingress Controller itself is exposed via a Kubernetes Service. This Service needs to be accessible from outside the cluster. There are two common ways to do this:
    206 - NodePort: The Service is exposed on a high port (e.g., 30000-32767) on each node's IP address. External traffic can reach the Ingress Controller by hitting any node's IP at this port.
    207 - LoadBalancer: If your cluster is running in a cloud environment that supports LoadBalancer Services, this is a more straightforward way to expose your Ingress Controller. For our setup lets allow the metalLB setup to lease an external IP address that routes traffic to the Ingress Controller.
    208 
    209 '''Step 4: DNS Configuration'''
    210 
    211 ''1. Configure DNS: Map the DNS record to the external IP address of one of your cluster nodes (if using NodePort for the Ingress Controller) or to the external IP provided by the LoadBalancer (if using LoadBalancer for the Ingress Controller).''
     209- !NodePort: The Service is exposed on a high port (e.g., 30000-32767) on each node's IP address. External traffic can reach the Ingress Controller by hitting any node's IP at this port.
     210- !LoadBalancer: If your cluster is running in a cloud environment that supports !LoadBalancer Services, this is a more straightforward way to expose your Ingress Controller. For our setup lets allow the metalLB setup to lease an external IP address that routes traffic to the Ingress Controller.
     211
     212=== Step 4: DNS Configuration ===
     213
     214''1. Configure DNS: Map the DNS record to the external IP address of one of your cluster nodes (if using !NodePort for the Ingress Controller) or to the external IP provided by the !LoadBalancer (if using !LoadBalancer for the Ingress Controller).''
    215
    216Read More: