資源控制器的缺陷，就是比如有的pod死掉了，再重建之後，裡面的ip會改變，這個過程會影響別的程式使用。SVC的作用就是可以監測到這種改變，它也是通過標籤選擇匹配到一組pod。有四種方式，clusterip，nodeport和LB這種服務是對內部的。在實際生產環境中，可能有不同的service需求，比如業務一個，管理一個等。k8s需要一種管理服務的服務。那就是ingress，這個比較複雜，專門放一篇文章裡面寫。

ClusterIP:

預設型別，自動分配一個僅內部可以訪問的虛擬IP。在每個node節點使用iptables。

 [root@zr-k8s-master01 ~]# cat clusterip-myapp-deployment.yamlapiVersion: apps/v1kind: Deploymentmetadata: name: myapp-deploy namespace: defaultspec: replicas: 3 selector: matchLabels: app: myapp release: stabel template: metadata: labels: app: myapp release: stabel env: test spec: containers: - name: myapp image: ikubernetes/myapp:v1 imagePullPolicy: IfNotPresent ports: - name: http containerPort: 80

kubectl apply -f clusterip-myapp-deployment.yaml –record

kubectl get pod -o wide

有三個ip地址，萬一哪個重建了，ip還會變化，所以可以建立一個SVC進行管理。

[root@zr-k8s-master01 ~]# cat clusterip-myapp-service.yamlapiVersion: v1kind: Servicemetadata:  name: myapp  namespace: defaultspec:  type: ClusterIP #有時候可以指定clusterIP:”None”,這個時候就不會有clusterip地址出現。  selector: #用來匹配後端的pod    app: myapp    release: stabel  ports:  - name: http    port: 80targetPort: 80

kubectl apply -f clusterip-myapp-service.yaml

kubectl get svc

ipvsadm -Ln

我們建立的這個名字為myapp的SVC的clusterip就是10.108.69.176。通過這個ip可以訪問到它對應的pod，訪問機制是pod輪詢。

一個svc一旦建立成功，它的主機名會被寫入到coredns裡面，寫入的規則是：SVC的名稱+當前名稱空間+當前叢集的域名。當你建立的SVC是無頭服務（即指定clusterIP:”None”）的時候，雖然沒有ip了，但是可以通過域名解析的方式檢視到對應的pod，當然也可以訪問到對應的pod上去。

kubectl get pod -n kube-system -o wide

dig -t A myapp-headless.default.svc.cluster.local. @10.244.0.22

NodePort：

在 ClusterIP 基礎上為 Service 在每臺機器上繫結一個埠，這樣就可以通過 NodePort 來訪問該服務。

 [root@zr-k8s-master01 ~]# cat nodeport-myapp-service.yamlapiVersion: v1kind: Servicemetadata:  name: myapp  namespace: defaultspec:  type: NodePort #和clusterip的svc的區別就是這個type不一樣  selector:    app: myapp    release: stabel  ports:  - name: http    port: 80    targetPort: 80

kubectl apply -f nodeport-myapp-service.yaml

kubectl get svc

netstat -anpt |grep 31056

LoadBalancer

loadBalancer 和 nodePort 其實是同一種方式。區別在於 loadBalancer可以呼叫cloud provider供應商去建立LB來向節點導流。

ExternalName

ExternalName Service 是 Service 的特例，它沒有 selector，也沒有定義任何的埠和Endpoint。

[root@zr-k8s-master01 ~]# cat externalname-service.yamlkind: ServiceapiVersion: v1metadata:  name: my-service-1  namespace: defaultspec:  type: ExternalName  externalName: www.k8smaster.com

kubectl apply -f externalname-service.yaml

kubectl get svc

dig -t A my-service-1.default.svc.cluster.local. @10.244.0.22

如果訪問主機 my-service-1.defalut.svc.cluster.local ( SVC_NAME.NAMESPACE.svc.cluster.local )時，就會被寫為master135.251.206.137。