• external DNS: Ignore Ingress object

    1 min read

    If we are using external DNS to create DNS records based on the configured Ingress objects we might face a situation where we have two Ingress objects with the same hosts configured:

    $ kubectl get ingress
    NAME                    CLASS    HOSTS                                          ADDRESS       PORTS     AGE
    repo-nginx              <none>   repo.pet2cattle.com                     80        194d
    repo-alb                <none>   repo.pet2cattle.com                     80, 443   115d

    In a situation like this, we want to be able to tell external DNS to ignore one of them.


  • Enable access logs for an Ingress using ALB

    3 min read

    AWS Kubernetes Ingress ALB access logs

    When configuring the ALB using an Ingress object we can enable storing access logs to an S3 bucket in the same way we can do it for any ALB using terraform


  • ArgoCD redirect loop when using a Ingress objects with HTTPS offloading

    3 min read

    When enabling an Ingress for ArgoCD we might end up with a redirect loop: ArgoCD keeps redirecting to the main page using https, even tough it is already using https:

    $ curl -I https://argocd.pet2cattle.com/
    HTTP/2 307 
    date: Wed, 23 Mar 2022 22:38:31 GMT
    content-type: text/html; charset=utf-8
    location: https://argocd.pet2cattle.com/

    This issue happens because, by default, ArgoCD expects to handle the TLS termination by itself, always redirecting HTTP requests to HTTPS. If we try to offload the TLS termination to the ingress controller, from ArgoCD's perspective the connection is HTTP, so it keeps redirecting to HTTPS


  • Install and configure external-DNS on AWS EKS

    3 min read

    With external DNS the DNS records for the ingress objects we have will be created automatically. We can choose between several cloud providers but we can even configure it to use the standard dynamic zone manipulation defined in RFC-2136. Let's see how to configure it on AWS EKS with Route53


  • Failed build model due to couldn't auto-discover subnets: unable to discover at least one subnet

    2 min read

    Using an ALB controller we might face the following error while creating Ingress objects:

    $ kubectl describe ingress pet2cattle -n pet2cattle
    Name:             pet2cattle
    Namespace:        pet2cattle
    Default backend:  default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
      Host                        Path  Backends
      ----                        ----  --------
                                  /   ssl-redirect:use-annotation (<error: endpoints "ssl-redirect" not found>)
                                  /   pet2cattle:http (
    Annotations:                  alb.ingress.kubernetes.io/actions.ssl-redirect:
                                    {"Type": "redirect", "RedirectConfig": { "Protocol": "HTTPS", "Port": "443", "StatusCode": "HTTP_301"}}
                                  alb.ingress.kubernetes.io/group.name: pet2cattle
                                  alb.ingress.kubernetes.io/listen-ports: [{"HTTP":80},{"HTTPS":443}]
                                  alb.ingress.kubernetes.io/scheme: internal
                                  alb.ingress.kubernetes.io/target-type: ip
                                  kubernetes.io/ingress.class: alb
                                  meta.helm.sh/release-name: pet2cattle
                                  meta.helm.sh/release-namespace: pet2cattle
      Type     Reason            Age                 From     Message
      ----     ------            ----                ----     -------
      Warning  FailedBuildModel  16m (x19 over 38m)  ingress  Failed build model due to couldn't auto-discover subnets: unable to discover at least one subnet

    This message is telling us that the ALB controller is no able to find the subnets of the requested type. We will have to check the following:



From pet to cattle
Treat your kubernetes clusters like cattle, not pets