标签:ali kubectl ant nali objects root metadata template dom
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
Service Type:
ExternalName, ClusterIP, NodePort, and LoadBalancer
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
标签:ali kubectl ant nali objects root metadata template dom
原文地址:https://www.cnblogs.com/crazy-chinese/p/10325519.html