Rob Stewart

stewartcircle.com

CKA Prep - Services and Networking

2022-08-17 8 min read Kubernetes

This post is part of a series which contains my study notes for the Certified Kubernetes Administrator (CKA) exam.

Note: Unless specifically indicated, text and examples in this post all come directly from the official Kubernetes documentation. I attempted to locate and extract the relevant portions of the kubernetes.io documentation that applied to the exam objective. However, I encourage you to do your own reading. I cannot guarantee that I got all of the important sections.

Services and Networking

The Exam Curriculum breaks down the third exam topic into the following objectives:

Understand Host Networking Configuration on the Cluster Nodes

Relevant search terms for Kubernetes Documentation: networking

Concepts

The basic tenants of Kubernetes networking:

  • All of the nodes on a Kubernetes cluster must be able to communicate on a network.
  • Pod-to-Pod communication is handled by the Container Network Interface (CNI) plug-in installed on the Kubernetes cluster. All Pods on a Kubernetes cluster must be able to communicate without network address translation.
  • Any time there is a need for highly-coupled container-to-container communication then those containers can be run on a single pod which enables localhost communication.
  • Services are responsible for Pod-to-Service communication and external communication between pods running on the cluster and resources outside the cluster.

top

Understand Connectivity Between Pods

Relevant search terms for Kubernetes Documentation: Pod Networking,

Concepts

  • “Every Pod in a cluster gets its own unique cluster-wide IP address. This means you do not need to explicitly create links between Pods and you almost never need to deal with mapping container ports to host ports.”
  • “Every container in a Pod shares the network namespace, including the IP address and network ports.”
  • “Inside a Pod (and only then), the containers that belong to the Pod can communicate with one another using localhost. "
  • “When containers in a Pod communicate with entities outside the Pod, they must coordinate how they use the shared network resources (such as ports).”
  • “Within a Pod, containers share an IP address and port space, and can find each other via localhost. The containers in a Pod can also communicate with each other using standard inter-process communications like SystemV semaphores or POSIX shared memory.”
  • “Containers within the Pod see the system hostname as being the same as the configured name for the Pod.”
  • “Containers in different Pods have distinct IP addresses and can not communicate by OS-level IPC without special configuration. Containers that want to interact with a container running in a different Pod can use IP networking to communicate.”
  • “Kubernetes imposes the following fundamental requirements on any networking implementation (barring any intentional network segmentation policies):”
    • “pods can communicate with all other pods on any other node without NAT”
    • “agents on a node (e.g. system daemons, kubelet) can communicate with all pods on that node”

top

Understand ClusterIP, NodePort, LoadBalancer Service Types and Endpoints

Relevant search terms for Kubernetes Documentation: service

API Objects

  • Service - (shortname svc) “An abstract way to expose an application running on a set of Pods as a network service.”

Concepts

  • “A Kubernetes Service is an abstraction which [usually] defines a logical set of Pods running somewhere in your cluster, that all provide the same functionality.”

  • “When created, each Service is assigned a unique IP address (also called clusterIP). This address is tied to the lifespan of the Service, and will not change while the Service is alive. "

  • “Pods can be configured to talk to the Service, and know that communication to the Service will be automatically load-balanced out to some pod that is a member of the Service.”

  • There are four types of services:

    • “ClusterIP: Exposes the Service on a cluster-internal IP. Choosing this value makes the Service only reachable from within the cluster. This is the default ServiceType.”
    • “NodePort: Exposes the Service on each Node’s IP at a static port (the NodePort). A ClusterIP Service, to which the NodePort Service routes, is automatically created. You’ll be able to contact the NodePort Service, from outside the cluster, by requesting <NodeIP>:<NodePort>.”
    • “LoadBalancer: Exposes the Service externally using a cloud provider’s load balancer. NodePort and ClusterIP Services, to which the external load balancer routes, are automatically created.”
    • “ExternalName: Maps the Service to the contents of the externalName field (e.g. foo.bar.example.com), by returning a CNAME record with its value. No proxying of any kind is set up.”

  • Endpoints map services to Pods or other network addresses

    • When a Service is created with Selectors then the controller for the service selector continuously scans for Pods that match its selector and updates the corresponding endpoint object that has the same name as the service with the addresses of the Pods.
    • However, if a service is created without Selectors then the corresponding Endpoint object is not created automatically when the service is created. However, you can create an Endpoint object manually with the same name as the Service and use it to map the service to any network address and port. This is useful if you want to have a service which points to an end point running outside the cluster.

  • A Headless Service is a service created without allocating a ClusterIP. Headless Services are typically used with StatefulSets.

Relevant Commands

Create a deployment called “my-dep” and then expose it with a ClusterIP service called “my-svc”

kubectl create deployment my-dep --image=nginx \
--port=8080  --replicas=2 

kubectl expose deployment my-dep --port=80 \
--target-port=8080  --name=my-svc \
--type=ClusterIP

Note: when you create a service using expose, the name of the service is the same as the name of the exposed object if you do not use the --name argument to specify the name. The selector the Service uses comes from the label on the exposed resource.

Create a deployment called “my-dep2” and then create a NodePort service called “my-dev2”

kubectl create deployment my-dep2 --image=nginx \
--port=8080  --replicas=2 

kubectl create service nodeport my-dep2  --tcp=80:8080

Create a deployment called “my-dep3” and then expose it with a Load Balancer Service called “my-lb”

kubectl create deployment my-dep3 --image=nginx \
--port=8080  --replicas=2 

kubectl expose deployment my-dep3 --port=80 \
--target-port=8080  --name=my-svc \
--type=LoadBalancer

top

Know How to Use Ingress Controllers and Ingress Resources

Relevant search terms for Kubernetes Documentation: ingress

API Objects

  • Ingress - “An API object that manages external access to the services in a cluster, typically HTTP.

    Ingress may provide load balancing, SSL termination and name-based virtual hosting.”

Concepts

  • “Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster. Traffic routing is controlled by rules defined on the Ingress resource.”

  • “In order for the Ingress resource to work, the cluster must have an ingress controller running.”

  • “Unlike other types of controllers which run as part of the kube-controller-manager binary, Ingress controllers are not started automatically with a cluster.”

  • Therefore, an Ingress Controller must be deployed to the cluster in order to use Ingress resources.

  • There are several different types of Ingress

    • Ingress backed by a single service - This is roughly equivalent to a NodePort Service or a LoadBalancer Service.
    • Simple Fanout – In cases where a web application has multiple URL paths which are each supported by a distinct Kubernetes service an Ingress can be used to route the traffic from each URL path to the corresponding service.
    • Name Based Virtual Hosting - In cases where a single Ingress may route traffic to a different service based on the host name.

  • Ingress can support TLS by referencing a secret containing the cert and key in the spec.

Relevant Commands

Create a simple fanout ingress called “ing-1” with 2 rules and 2 annotations

kubectl create ingress ing-1 --class=default \
--rule="mysite.com/=svc:port" \
--rule="mysite.com/admin/=svcadmin:portadmin"
--annotation ingress.annotation1=foo \
--annotation ingress.annotation2=bla

top

Know How to Configure and Use CoreDNS

Relevant search terms for Kubernetes Documentation: coredns

Concepts

  • For clusters deployed by kubeadm, the DNS for the cluster is handled by a deployment in the kube-system namespace called coredns; the coredns configuration comes from a configmap in the kube-system namespace also called coredns.

  • “Kubernetes creates DNS records for Services and Pods. You can contact Services with consistent DNS names instead of IP addresses.”

  • DNS records for Services

    • “Normal” Services (e.g., not headless) are assigned an A record (or AAAA record if using IPv6) with a name in the form of my-svc.my-namespace.svc.cluster-domain.example which resolves to the ClusterIP of the service. For example, the DNS name of a service called svc1 in the dev namespace would be svc1.dev.svc.cluster.local.
    • “Headless” Services (those without a ClusterIP) are also assigned an A record (or AAAA record if using IPv6) with a name in the form of my-svc.my-namespace.svc.cluster-domain.example which resolves to the set of IP addresses of the Pods selected by the Service or the specified address in the EndPoint if the Service does not contain a selector.

  • DNS Records for Pods

    • Pods are assigned A records (or AAAA record if using IPv6) with names in the form of pod-ip-address.my-namespace.pod.cluster-domain.example. For example, if a Pod in the web namespace has the IP address 10.200.62.5, and the domain name for your cluster is cluster.local, then the Pod has a DNS name 10-200-62-5.web.pod.cluster.local. If a Pod is exposed by a service, then a DNS like the following will also be created pod-ip-address.service-name.my-namespace.svc.cluster-domain.example.

top

Choose an Appropriate Container Network Interface Plugin

Relevant search terms for Kubernetes Documentation: cluster networking

Concepts

  • There are a wide variety of Cluster Network Interface (CNI) plugins. None of them are part of the base kubernetes distribution. However, when deploying a cluster with kubeadm a CNI plugin must be deployed in order for the cluster to function.

top

And that’s a wrap for this topic.

Return to the series overview page

cka kubernetes exam prep
© 2022 by Rob Stewart
Bilberry Hugo Theme