# 我们先来创建一个nginx的deployment资源
kubectl create deployment nginx --image=nginx --replicas=3# 等服务pod都运行好，这时候按我们期待的状态就是3个pod，没问题
kubectl get pod -w# 我们现在来修改其中一个pod的label，你会发现这个pod会被deployment抛弃，因为失去了labels这个标签，deployment已经不认识这个pod了，它就成了无主的pod，这时我们直接删除这个pod，它就会直接消失，就和我们用kubectl run 一个独立的pod资源一样# 我们再来基于这个nginx的deployment来创建一个service服务
kubectl expose deployment nginx --port=80 --target-port=80 --name=nginx# 直接利用svc的ip来请求下，发现都是正常的对吧
kubectl get svc nginx# 这个时候我来来修改下svc资源的选择labels，看看会出现什么情况
kubectl patch services nginx -p '{"spec":{"selector":{"app": "nginxaaa"}}}'
# 这时再请求这个svc的ip，你会发现已经请求不通了，这也证明了它已经关联不到后面对应label的pod了# 我们修改回来后，会发现一切恢复正常了
kubectl patch services nginx -p '{"spec":{"selector":{"app": "nginx"}}}'

# 我们先来创建一个 nginx 的 deployment 资源
kubectl create deployment nginx --image=nginx --replicas=3# 等服务pod都运行好，这时候按我们期待的状态就是 3 个 pod，没问题
kubectl get pod -w# 我们现在来修改其中一个 pod 的 label，你会发现这个 pod 会被 deployment 抛弃，因为失去了 labels 这个标签，deployment 已经不认识这个 pod 了，它就成了无主的 pod，这时我们直接删除这个 pod，它就会直接消失，就和我们用 kubectl run 一个独立的 pod 资源一样# 我们再来基于这个 nginx 的 deployment 来创建一个 service 服务
kubectl expose deployment nginx --port=80 --target-port=80 --name=nginx# 直接利用svc的ip来请求下，发现都是正常的对吧
kubectl get svc nginx# 这个时候我来来修改下 svc 资源的选择 labels，看看会出现什么情况
kubectl patch services nginx -p '{"spec":{"selector":{"app": "nginxaaa"}}}'
# 这时再请求这个svc的ip，你会发现已经请求不通了，这也证明了它已经关联不到后面对应label的pod了# 我们修改回来后，会发现一切恢复正常了
kubectl patch services nginx -p '{"spec":{"selector":{"app": "nginx"}}}'