Bob's Journey to Secure Ingress

Bob dives into Kubernetes Ingress Controllers, exploring how they route traffic to services, the role of Endpoints, and securing applications with TLS. With Josie’s guidance, he learns to expose apps securely and troubleshoot traffic flow, taking another step in his Kubernetes journey.

Bob's Journey to Secure Ingress

Bob, now well-versed in managing persistent data and connecting to external services, turned his attention to a crucial aspect of deploying applications in Kubernetes: exposing them to the outside world.

"My applications are running smoothly within the cluster," he thought, "but how do I make them accessible to users outside of Kubernetes?"

Josie, sensing his inquisitiveness, approached with a smile. "Ready to open the doors to your Kubernetes applications, Bob?" she asked.

Bob nodded eagerly. "I'm ready to expose my applications securely to the world."

📂 Code Repository: Explore the complete code and configurations for this article on GitHub.

View Repository on GitHub

Ingress Controllers

Josie began by introducing the concept of Ingress Controllers.

"Ingress Controllers are like the doorkeepers of your Kubernetes house," she explained. "They enforce the rules defined in your Ingress resources and route traffic accordingly."

Bob leaned in. "So, they’re the first point of contact for any user traffic?"

"Exactly," Josie replied. She sketched a basic flow on her notepad and pointed to the Ingress.

Flow of traffic through the Ingress, Service, Endpoints, and Pods

"Traffic starts with the Ingress," Josie continued, "and the Ingress routes it to the correct Service. From there, traffic flows through Endpoints to the Pods running your application."

Josie elaborated that this flow builds on the traffic concepts they had explored earlier with Services and readiness checks in Pods. "Endpoints act as the bridge between Services and Pods. We'll explore them next."

They worked together to define a simple Ingress resource:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-basic-ingress
spec:
  rules:
  - host: my-app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-service
            port:
              number: 80

"This configuration routes traffic for my-app.example.com to the my-app-service on port 80," Josie explained. Bob nodded, starting to grasp the role of Ingress in Kubernetes.

Traffic Flow and the Role of Endpoints

Josie introduced the next piece of the puzzle: Endpoints.

"Think of Endpoints as the backstage crew in a theatre," Josie said. "They ensure that the actors (your Pods) are ready, in place, and able to perform."

Bob chuckled. "So, if something goes wrong with the Pods, the Endpoints won’t know where to send traffic?"

"Exactly," Josie replied. She explained that Endpoints are dynamically updated to map traffic from Services to healthy Pods. To demonstrate, she ran the following command:

$ kubectl get endpoints my-app-service

NAME            ENDPOINTS               AGE
my-app-service  10.244.1.4:3000         15m
                10.244.2.5:3000

"This shows that traffic is directed to Pods listening on port 3000," Josie explained. "If this list were empty, it would mean no Pods are ready to receive traffic."

They updated the Service to ensure traffic flowed correctly:

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 3000

"This way, traffic from the Ingress on port 80 is forwarded to the Pods via port 3000," Josie noted. Bob began to appreciate how each layer worked together.

Securing Traffic with TLS Certificates

"Now that we’ve got traffic flowing," Josie said, "let’s ensure it’s secure." She introduced Bob to TLS certificates.

"TLS certificates are like security badges for your Kubernetes house," she explained. "They encrypt data in transit, protecting it from eavesdropping and tampering."

Josie showed Bob how to create a Kubernetes Secret for the TLS certificate:

apiVersion: v1
kind: Secret
metadata:
  name: my-tls-secret
type: kubernetes.io/tls
data:
  tls.crt: <BASE64_ENCODED_CERTIFICATE>
  tls.key: <BASE64_ENCODED_PRIVATE_KEY>

They then updated the Ingress to enable HTTPS:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-basic-ingress
spec:
  tls:
  - hosts:
    - my-app.example.com
    secretName: my-tls-secret
  rules:
  - host: my-app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-service
            port:
              number: 80

"This tells Kubernetes to use the TLS certificate for HTTPS connections," Josie explained. Bob smiled, feeling more confident in his ability to secure his applications.

At the end of the session, Bob reflected on his learnings and noted down his key takeaways:

  • Ingress Controllers act as the entry point for external traffic, enforcing routing rules defined in Ingress resources
  • Services and Endpoints work together to direct traffic from the Ingress to the appropriate Pods
  • TLS Certificates are essential for securing traffic, enabling HTTPS and protecting data in transit
  • Debugging tools like kubectl describe endpoints and kubectl get pods help identify traffic routing issues

"This was a lot to learn," Bob said, "but I feel much more confident about securely exposing my applications to the world."

Josie smiled. "You're doing great, Bob. Next time, we'll tackle scaling and more advanced traffic routing patterns."