1 Service
Kubernetes Pods are mortal. They are born and when they die, they are not resurrected. ReplicaSets in particular create and destroy Pods dynamically (e.g. when scaling out or in). While each Pod gets its own IP address, even those IP addresses cannot be relied upon to be stable over time. This leads to a problem: if some set of Pods (let’s call them backends) provides functionality to other Pods (let’s call them frontends) inside the Kubernetes cluster, how do those frontends find out and keep track of which backends are in that set?
Enter Services.
A Kubernetes Service is an abstraction which defines a logical set of Pods and a policy by which to access them - sometimes called a micro-service. The set of Pods targeted by a Service is (usually) determined by a Label Selector (see below for why you might want a Service without a selector).
As an example, consider an image-processing backend which is running with 3 replicas. Those replicas are fungible - frontends do not care which backend they use. While the actual Pods that compose the backend set may change, the frontend clients should not need to be aware of that or keep track of the list of backends themselves. The Service abstraction enables this decoupling.
For Kubernetes-native applications, Kubernetes offers a simple Endpoints API that is updated whenever the set of Pods in a Service changes. For non-native applications, Kubernetes offers a virtual-IP-based bridge to Services which redirects to the backend Pods.
PS: there are three working mode for Service -> userspace, iptables and ipvs
- userspace: used for kubernetes 1.1 -
- iptables: between 1.1 and 1.10 -
- ipvs: 1.11+ (current)
Service Type:
ExternalName, ClusterIP, NodePort, and LoadBalancer
2. Create a Service for Redis
using template below:
apiVersion: apps/v1 kind: Deployment metadata: name: redis namespace: default spec: replicas: 1 selector: matchLabels: app: redis role: logstore template: metadata: labels: app: redis role: logstore spec: containers: - name: redis image: redis:4.0-alpine ports: - containerPort: 6379 --- apiVersion: v1 kind: Service metadata: name: redis-svc namespace: default spec: selector: app: redis role: logstore clusterIP: 10.97.97.97 type: ClusterIP ports: - port: 6379 targetPort: 6379
* port -> service ip address port
* targetPort -> container port
* nodePort -> node port for external communications
Perform command:
[root@k8smaster service]# kubectl apply -f redis-svc.yaml service/redis created
[root@k8smaster service]# kubectl get pods -o wide --show-labels
NAME READY STATUS RESTARTS AGE IP NODE LABELS
redis-797f4cc7c4-xmvcm 1/1 Running 0 18d 10.244.1.47 k8snode1 app=redis,pod-template-hash=3539077370,role=logstore
[root@k8smaster service]# kubectl get svc -o wide --show-labels
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR LABELS
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 24d <none> component=apiserver,provider=kubernetes
redis-svc ClusterIP 10.97.97.97 <none> 6379/TCP 18d app=redis,role=logstore <none>
[root@k8smaster service]# kubectl describe svc redis-svc
Name: redis-svc
Namespace: default
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"redis-svc","namespace":"default"},"spec":{"clusterIP":"10.97.97.9...
Selector: app=redis,role=logstore
Type: ClusterIP
IP: 10.97.97.97
Port: <unset> 6379/TCP
TargetPort: 6379/TCP
Endpoints: 10.244.1.47:6379
Session Affinity: None
Events: <none>
From the information we can see Endpoints point to 10.244.1.47:6379 which is the random assigned ip and predefined exposed port of redis pod
Endpoints is a kubernetes object. You can also create it manually, this is like a brige between Service and Pod