cover

INTRO

Ya tenemos nuestro cluster instalado, ya tenemos storage persistente compartido a traves de NFS, ahora vamos a comenzar a preparar nuestro cluster para que tenga la posibilidad de exponer nuestros servicios al mundo exterior

Requisitos previos

  • Haber completado las 2 primeras partes de esta serie.
  • Conocimientos basicos en SVC nativos K8s.
  • Conocimientos básicos de Networking.
  • Conocimientos básicos de Load Balancing.

Instalamos MetalLB:

Que es?

MetalLB es un Load Balancer pensado para instalaciones de K8s de tipo Bare Metal, básicamente lo que sucede cuando tenemos instalado MetalLB y definimos un svc cualquiera de tipo LoadBalancer, MetalLB hace su magia asignando una VirtualIP de una address-pool predeterminada para luego exponer dicho servicio a traves de un LB funcional al mundo exterior (es algo así como tener un AWS ALB, un CLB o un AzureLB controller en las raspis)

Helm y nada mas:

lo instalamos con nuestro buen amigo Don Helm, primero agregamos el repo y extraemos los values:

$ helm repo add metallb https://metallb.github.io/metallb
$ helm repo update
$ helm show values metallb/metallb > values.yaml

lo tunean al values file, valores a tener en cuenta:

namespace metallb-system 
configInline.address-pools[0].name=default 
configInline.address-pools[0].protocol=layer2 
configInline.address-pools[0].addresses[0]=RANGO-IP-SEGUN-SU-LAN

y lo instalan:

helm install metallb metallb/metallb -f values.yaml

luego, el get po debería tener esta facha:

NAMESPACE     NAME                                      READY   STATUS    RESTARTS   AGE                            
metallb-system   metallb-speaker-sf6cvp                    1/1     Running   0      2m47s                   
metallb-system   metallb-speaker-hg64v                     1/1     Running   0      2m47s                   
metallb-system   metallb-controller-6fb88ff94b-8gt56       1/1     Running   0      2m47s           
metallb-system   metallb-speaker-k5kbh                     1/1     Running   0      2m47s       

Instalamos Nginx Ingress Controller:

Al igual que con MetalLB, vamos a hacerlo siguiendo el “Helm Path”:

helmpath

Agregamos el repo:

$ helm repo add nginx-stable https://helm.nginx.com/stable $ helm repo update

Instalamos (apagando el defualt backend con la siguiente flag):

$ helm install nginx-ing nginx-stable/nginx-ingress -n nginx-ingress-controller \
--set defaultBackend.enabled=false

el k get po tendrá esta facha:

NAME                                    READY   STATUS    RESTARTS   AGE                       
nginx-ingress-controller-62ht5fd-get5s   1/1     Running   0          6s   	

Instalamos Cert Manager:

What the F%$# is CertManager?

Cert Manager es una tool para Kubernetes usada para emitir y gestionar automáticamente certificados x509 contra el ingress controller (Nginx en nuestro caso) y de esa manera asegurar vía SSL todas las rutas HTTP sin tener que preocuparnos en hacerlo manualmente o en lo que implica hacerlo dentro de kubernetes, si… es una MARAVILLA.

Vamos a hacerlo vía helm tambien peeerooo… Cert Manager usa una serie de CRDs (custom resources) que no están incluidos en el chart asi que vamos a hacer lo siguiente:

NOTA: no usen el chart oficial porque está deprecado, vamos a usar otro que está publicado en la doc oficial de CertManager

Agregamos el repo:

helm repo add jetstack https://charts.jetstack.io
helm repo update

Agregamos los CRDs

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml

Instalamos el chart

 helm install \
  cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --version v1.11.0 

el k get po debería verse así:

NAME                                       READY   STATUS    RESTARTS   AGE   
cert-manager-cainjector-6287d6724d-h3td2   1/1     Running   0          69s   	
cert-manager-736475b22c-hfdt5              1/1     Running   0          69s   
cert-manager-webhook-547567b88f-zfm9x      1/1     Running   0          68s   	

ahora agregamos por ejemplo un CertIssuer con LetsEncrypt - SOLO PARA TESTEAR Y PARA JUGAR (para prod usen otra cosa)

cat <<EOF | kubectl apply -f -
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-develop
spec:
  acme:
    email: <TU-MAIL>
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: letsencrypt-develop-key
    solvers:
    - http01:
        ingress:
          class: nginx
EOF

Listo, ahora cada vez que configures SSL en un Ingress Object, un certificado LetsEncrypt va a ser emitido auto-MAGICAMENTE.

En la proxima y ultima parte vamos a instalar algunas aplicaciones útiles para comenzar a utilizar nuestro HomeLab en nuestro día a día

Fuente

Material Extra: Curso “Devops en 5 Pasos” Disponible en Udemy

Temas:

  • Docker
  • Kubernetes
  • MultiCloud (AWS - Azure - GCP)
  • IaC (Terraform, Cloud Formation, ARM Templates, Cloud Resource Manager)
  • CI/CD Pipelines (GitlabCI, Azure Devops, CircleCI)

Descripción completa: Detalle y enlaces del curso

Invitame un CaféInvitame un Café