CC00155.CloudKubernetes——|KuberNetes&服务发布.V06|——|service.v02|service代理内部服务|

一、service：创建nginx-deployment

### --- 创建nginx-deployment.yaml配置文件

[root@k8s-master01 ~]# cat nginx-deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx
  namespace: default
spec:
  progressDeadlineSeconds: 600
  replicas: 2
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: nginx
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.15.2
        imagePullPolicy: IfNotPresent
        name: nginx
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30

### --- 创建nginx-deployment服务

[root@k8s-master01 ~]# kubectl create -f nginx-deploy.yaml 
deployment.apps/nginx created

### --- 查看创建的pod
~~~     起来之后会有一个IP地址，且每个nginx起来之后会暴露一个80端口；
~~~     若是使用curl访问地址，是可以访问到主页的

[root@k8s-master01 ~]# kubectl get po -owide
NAME                     READY   STATUS    RESTARTS   AGE   IP               NODE           NOMINATED NODE   READINESS GATES
busybox                  1/1     Running   8          18h   172.25.244.211   k8s-master01   <none>           <none>
nginx-66bbc9fdc5-5mwvb   1/1     Running   0          49s   172.25.244.212   k8s-master01   <none>           <none>
nginx-66bbc9fdc5-lm5xz   1/1     Running   0          49s   172.18.195.15    k8s-master03   <none>           <none>

### --- 测试pod地址是否正常解析
~~~     我们既然可以使用IP地址访问到主页，那么我们为什么要引入一个Pod呢？
~~~     在传统部署中，部署之后宿主机就固定了，一般情况下是不会发生变化的。
~~~     所以说宿主机的IP地址和端口是不会发生变化的。所以说可以通过宿主机和端口访问到这个地址服务
~~~     但是在k8s中，没做一次更新或者每删除一次pod，它的IP地址都会发生一次更改，
~~~     重新申请一个PodIP地址

[root@k8s-master01 ~]# curl  172.25.244.212 
<h1>Welcome to nginx!</h1>

二、为pod引入service的必要性

### --- 删除pod后容器的地址发生变化
~~~     查看创建的pod

[root@k8s-master01 ~]# kubectl get po -owide
NAME                     READY   STATUS    RESTARTS   AGE    IP               NODE           NOMINATED NODE   READINESS GATES
busybox                  1/1     Running   8          19h    172.25.244.211   k8s-master01   <none>           <none>
nginx-66bbc9fdc5-5mwvb   1/1     Running   0          5m1s   172.25.244.212   k8s-master01   <none>           <none>
nginx-66bbc9fdc5-lm5xz   1/1     Running   0          5m1s   172.18.195.15    k8s-master03   <none>           <none>

### --- 重启pod后容器的地址发生变化

~~~     可以看到新起的Pod的地址发生了变化
~~~     为什么k8s要改变这个Pod的IP地址，
~~~     因为：k8s是随机部署，弹性调度，而且随时的会去保持Pod的副本数是我们期望的那个值。
~~~     它在重建的过程中，会随机的调度最适合自己的宿主机去部署。
~~~     有可能会调度到之前损坏节点为宿主机。若是IP地址不发生变化，
~~~     就会造成宿主机上这2个Pod的IP地址一致，造成网段的重复，造成网络不通的情况。
~~~     所以说每次弹性部署的时候都会重启创建一个新的Pod，这个Pod就会重新申请一下IP地址。
~~~     传统架构里面是不会出现这种情况，因为我们是把之前的服务给停掉，在重新起来，
~~~     但是在k8s的Pod中，是经过弹性计算的，不会去保持Pod的IP地址。

[root@k8s-master01 ~]# kubectl delete po nginx-66bbc9fdc5-5mwvb 
pod "nginx-66bbc9fdc5-5mwvb" deleted
[root@k8s-master01 ~]# kubectl get po -owide
NAME                     READY   STATUS    RESTARTS   AGE     IP               NODE           NOMINATED NODE   READINESS GATES
busybox                  1/1     Running   8          19h     172.25.244.211   k8s-master01   <none>           <none>
nginx-66bbc9fdc5-lm5xz   1/1     Running   0          6m29s   172.18.195.15    k8s-master03   <none>           <none>
nginx-66bbc9fdc5-tq7gw   1/1     Running   0          77s     172.17.125.11    k8s-node01     <none>           <none>

### --- 所以说我们不能通过Pod的IP地址去访问服务的。
### --- 这个service可以理解为一个反向代理。

~~~     所以k8s引出来一个理念，service：可以简单的理解为逻辑上的一组Pod。
~~~     一种可以访问Pod的策略，而且其他Pod可以通过这个Service访问到这个Service代理的Pod。
~~~     相对于Pod而言，它会有一个固定的名称，一旦创建就固定不变。