Task 2.1: Networking

• AA Pod can be reached from another node through a hostPort mapped on its node

  Incorrect

  hostPort exposes a Pod on its node's address; it is not needed for Pod-to-Pod traffic, which uses Pod IPs.

• BEach Pod has its own cluster-wide IP, and Pods reach each other on it directly, without NAT

  Correct

  The model gives every Pod a unique cluster-wide IP and lets all Pods communicate, on the same or different nodes, without proxies or address translation.

• CPod IP addresses are routable just within the node where the Pod runs, so cross-node traffic needs NAT

  Incorrect

  Pod IPs are cluster-wide. The network plugin makes them reachable from every node.

• DThe kubelet translates addresses between nodes for each Pod-to-Pod connection

  Incorrect

  The kubelet runs Pods; it does not translate traffic. Pod-to-Pod traffic needs no translation at all.

Kubernetes networking is flat: Pods talk to each other on their own IPs across the cluster, and a network plugin implements that model.

• ANodePort

  Incorrect

  NodePort opens a port on every node's IP address, which exposes the Service outside the cluster network.

• BLoadBalancer

  Incorrect

  LoadBalancer exposes the Service outside the cluster through an external load balancer, the opposite of what is wanted.

• CExternalName

  Incorrect

  ExternalName maps the Service to an external DNS name with a CNAME record; it does not front Pods in the cluster.

• DClusterIP

  Correct

  ClusterIP, the default type, gives the Service a virtual IP that is reachable only from inside the cluster.

ClusterIP is the internal Service type. NodePort and LoadBalancer add ways in from outside, and ExternalName points at something outside.

• Aorders.billing.svc.cluster.local

  Correct

  Service records follow <service>.<namespace>.svc.<cluster-domain>, so this name resolves to the Service in billing.

• Borders

  Incorrect

  A bare name is expanded with the client's own namespace first, so from shop it looks for orders.shop.svc.cluster.local.

• Cbilling.orders.svc.cluster.local

  Incorrect

  The order is reversed; the Service name comes before the namespace.

• Dorders.billing.pod.cluster.local

  Incorrect

  Services are published under svc. The pod subdomain is for Pod address records, not Service names.

Cluster DNS gives every Service a name of the form service.namespace.svc.cluster-domain; a short name works only from the same namespace.

• AThe Service has type ClusterIP instead of NodePort

  Incorrect

  Ingress backends are commonly ClusterIP Services; the controller forwards to them inside the cluster.

• BThe Ingress lives in the same namespace as the Service

  Incorrect

  An Ingress refers to backend Services in its own namespace, so that is the expected setup.

• CNo Ingress controller is running in the cluster

  Correct

  An Ingress is only a set of rules. An Ingress controller has to read them and do the routing; creating the resource alone has no effect.

• Dkube-proxy does not support HTTP routing rules

  Incorrect

  Routing by host and path is the Ingress controller's job, not kube-proxy's, so this is not the cause.

Ingress objects need an Ingress controller to fulfill them. Without one, the rules sit in the API and nothing routes traffic.

• AThe policy needs policyTypes set to Egress to restrict incoming connections

  Incorrect

  Incoming connections are governed by Ingress rules; Egress covers traffic leaving the selected Pods.

• BThe cluster's network plugin does not enforce NetworkPolicy

  Correct

  Policies are enforced by the network plugin. Creating a NetworkPolicy without a plugin that implements it has no effect.

• CThe policy's podSelector does not match the labels on the database Pods

  Correct

  A policy isolates only the Pods it selects. If the selector misses the database Pods, they stay non-isolated and accept all traffic.

• DTraffic between Pods of one namespace is outside the scope of NetworkPolicy

  Incorrect

  Policies apply to Pod-to-Pod traffic within a namespace as well as across namespaces.

• EThe policy acts on traffic sent to a Service's ClusterIP, not on direct Pod IPs

  Incorrect

  NetworkPolicy works on Pod IPs and ports at layer 3 and 4; traffic through a Service is treated the same way.

Two things must hold for a policy to bite: a network plugin that enforces NetworkPolicy, and a podSelector that actually selects the Pods to protect.

• A30000-32767

  Correct

  By default the control plane allocates node ports from 30000-32767, set by --service-node-port-range.

• B1-1023

  Incorrect

  Those are well-known system ports, not the node port range.

• C8000-8999

  Incorrect

  That is not the default node port range.

• D49152-65535

  Incorrect

  That is a common ephemeral port range for clients, not the node port range.

Node ports come from a configurable range that defaults to 30000-32767.

• AAn A record for the Service name

  Incorrect

  A records return addresses, not port numbers.

• BAn SRV record for the named port

  Correct

  Cluster DNS creates SRV records for named ports, which return the port number and the target name.

• CA CNAME record for the Service name

  Incorrect

  CNAMEs map names to names, as ExternalName Services do; they carry no ports.

• DA PTR record for the Service's cluster IP

  Incorrect

  Reverse lookups map addresses back to names, not to ports.

SRV records of the form _port-name._protocol.service.namespace.svc carry the port for named ports.

• AA ConfigMap mounted into each of the backend Pods

  Incorrect

  TLS here is terminated at the Ingress, and keys do not belong in ConfigMaps.

• BThe backend Service's port that is named https

  Incorrect

  Port names do not carry certificates.

• CAn annotation holding the certificate file path

  Incorrect

  The Ingress spec references a Secret for TLS material, not a file path.

• DA Secret named in the tls section, with tls.crt and tls.key

  Correct

  The TLS secret must contain keys named tls.crt and tls.key with the certificate and private key.

Ingress TLS uses a Secret with tls.crt and tls.key, referenced by host in the tls section.

• AThrough the namespace the Ingress is created in

  Incorrect

  The namespace does not decide which controller takes the Ingress.

• BThrough spec.ingressClassName on the Ingress

  Correct

  The ingressClassName field links an Ingress to an IngressClass and so to the controller that serves it.

• CThrough the type of the backend Service it points to

  Incorrect

  Service types do not select Ingress controllers.

• DThrough the order in which the controllers were installed

  Incorrect

  Installation order has no effect; the class reference decides.

IngressClass resources and the ingressClassName field route each Ingress to the intended controller.