|NO.Z.00155|——————————|CloudNative|——|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而言,它会有一个固定的名称,一旦创建就固定不变。
Walter Savage Landor:strove with none,for none was worth my strife.Nature I loved and, next to Nature, Art:I warm'd both hands before the fire of life.It sinks, and I am ready to depart
——W.S.Landor
浙公网安备 33010602011771号