本篇内容介绍了“服务和端点的原理和作用是什么”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!
私营化程度
服务是将运行在一组圆荚体上的应用程序公开为网络服务的抽象方法。如果我们使用部署部署仓,则可以以部署为对象创建服务。
在美丽中,每个豆荚都有其自己唯一的ip地址,而服务可以为多个吊舱(一组)提供相同的DNS名,并且可以在他们直接进行负载均衡。
假如有一组nginx仓,如果nginx动态伸缩改变或因为某些原因ip/端口发生改变,那么其ip和端口都不是固定的,而且我们很难确定它新扩容的豆荚的地址是什么,又万一舱被删除,ip不再可用。
又假如一组圆荚体称为前端,如web服务,另一组圆荚体称为后端,例如mysql。那么前端如何查找并跟踪要连接的ip地址,以便前端可以使用工作负载的后端部分吗?
这真是 Service 要解决的问题。Kubernetes Service 定义了一种抽象：逻辑上的一组 Pod，一种可以访问它们的策略 —— 通常称为微服务。当使用 Service 为一组 pod (Deployment 的方式创建的)创建服务时，无论我们创建了多少个 pod 副本，这些 pod 怎么变化，前端不需要关心它们调用了哪个后端副本，而且不需要知道后端 pod 的状态也不需要跟踪 pod。Service 把前后端的这种关联抽象化，把它们解耦了。
Service 的创建及现象
现在按照下面的命令快速创建 pod，pod 将会在各个节点中部署运行。
kubectl create deployment nginx --image=nginx:latest --replicas=3
kubectl expose deployment nginx --type=LoadBalancer --port=80
然后执行命令查看 Service：
kubectl get services
也就是说外部访问端口是 30424。
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 443/TCP 3d6h
nginx LoadBalancer 10.101.132.236 80:30424/TCP 39s
这时，我们可以通过公网和端口访问这个 Service。
我们可以查看此 Service 的 yaml 文件：
kubectl get service nginx -o yaml
apiVersion: v1kind: Servicemetadata:
creationTimestamp: "2021-04-23T07:40:35Z"
labels:
app: nginx
name: nginx
namespace: default
resourceVersion: "369738"
uid: 8dc49805-2fc8-4407-adc0-8e31dc24fa79spec:
clusterIP: 10.101.132.236
clusterIPs:
- 10.101.132.236
externalTrafficPolicy: Cluster
ipFamilies:
- IPv4
ipFamilyPolicy: SingleStack
ports:
- nodePort: 30424
port: 80
protocol: TCP
targetPort: 80
selector:
app: nginx
sessionAffinity: None
type: LoadBalancerstatus:
loadBalancer: {}
有了标准的 yaml 文件模板，我们可以很方便地修改并定制一个 Service。
我们查看通过 Deployment 创建的 pod：
kubectl get pods -o wide
NAME IP NODE NOMINATED NODE READINESS GATESnginx-55649fd747-9fzlr 192.168.56.56 instance-2 nginx-55649fd747-ckhrw 192.168.56.57 instance-2 nginx-55649fd747-ldzkf 192.168.23.138 instance-1
注：pod 在哪个节点中运行，我们是不一样的。
当我们通过外部网络访问时，Service 会自动提供其中一个 pod 给我们，但是这个过程较为复杂，我们这里先将表面现象。
------------
| |
--- 公网ip --> | pod1 |
| pod2 |
| pod3 |
- - - - - - - - - - - -
然后我们通过命令查看iptables配置:
iptables-save
然后查随机找关键字:
你可以看到有三个默认的/nginx,第一个豆荚被访问的机会都是0.33333……,然后2/3的概率中,2/3的0.5的概率选择第二个吊舱,剩下的1/3概率选择第三个仓。
如果要访问仓,可以以任意部署了nginx pod的节点的ip进行访问。由于主人不能部署仓,所以不能通过主人的ip进行访问。
当然,它并不是直接都是0.33333 . .这样的，iptables 的规则有点复杂，这里难以讲清楚，我们只需要知道 外网能够访问 Service，而 Service 通过 iptable 为我们转发流量。即使 Deployment 部署的 pod 不在同一个节点上， k8s 的 dns 服务等会正确处理的，我们不需要手动配置这些网络。
Service 定义
在上一小节中，介绍了 Service 的创建方法(kubectl expose ...)，也介绍了其依赖的 iptables，这里将继续学习 Service 的定义方法。
