Intro
How do components interact with each other inside a Kubernetes cluster?
There are different types of communication in Kubernetes:
container-to-container (inside a pod)
pod-to-pod
pod-to-service
external-to-service
Service
A service is an abstraction which defines a set of pods and a policy by which to access them.
The set of pods targeted by a service is usually determined by a selector.
apiVersion: v1
kind: Service
metadata:
name: service
spec:
type: ClusterIP
selector:
app: pod
ports:
– protocol: TCP
port: 80
The above example suggests that this service applies to all pods with the label app:pod.
In this post we’ll talk about the most common types of services:
ClusterIP
NodePort
LoadBalancer
ClusterIP
This is the default service type.
It makes components reachable only from within the cluster.
If you still want to access it from outside the cluster, you can do it through a proxy.
NodePort
This type of service exposes pods on each node’s IP at a specific port.
apiVersion: v1
kind: Service
metadata:
name: node-service spec:
type: NodePort
selector:
app: pod
ports:
– name: http
protocol: TCP
targetPort: 80
nodePort: 30000
Still, there are a few downsides to this method:
You can only have one service per port
You can only use ports 30000–32767
If your Node/VM IP address change, you need to deal with that
LoadBalancer
This one exposes pods externally using a cloud provider’s load balancer.
If you want to send outside traffic to a pod, this is the default method.
apiVersion: v1
kind: Service
metadata:
name: service
spec:
type: LoadBalancer
clusterIP: 10.0.171.239
selector:
app: pod
ports:
– protocol: TCP
port: 80
Follow the Kubernetes 101 series on mindit.io.
Check out new-spike.net for other articles on Kubernetes and much more!