在k8s中,pod可以随时被建立,也可以随时被移除。
如透过Deployments
来建立时,它时可是被k8s动态的建立或是移除,因为前面文章有提到hpa或是self healing都会造成pod的异动。
每个pod都有自己的ip,只要一建立就会产生一组ip,基於这个原因,如果pod间的沟通是透过ip的话,
会变成随时要改ip才能打到pod,因为你不会知道pod何时更动。
官方对service的解释如下
Kubernetes Service 定义了这样一种抽象:逻辑上的一组 Pod,一种可以访问它们的策略 —— 通常称为微服务。 Service 所针对的 Pods 集合通常是通过选择算符来确定的。 要了解定义服务端点的其他方法,请参阅不带选择算符的服务。
举个例子,考虑一个图片处理後端,它运行了 3 个副本。 这些副本是可互换的 —— 前端不需要关心它们调用了哪个後端副本。 然而组成这一组後端程序的 Pod 实际上可能会发生变化, 前端用户端不应该也没必要知道,而且也不需要跟踪这一组後端的状态。
Service 定义的抽象能够解耦这种关联。
网路看到一张可以解释上面说明的图
图片来源
简单来说,有了Service这一层,对使用者来说只要认识到Service
就够了,使用者不用了解Deployments有几个pod,我要打哪个pod,pod ip是什麽,不用担心我会打到无效的pod,一切都交给Service层处理
apiVersion: v1
kind: Service
metadata:
name: test-myapp #服务名称
spec:
type: ClusterIP # Service类型:ClusterIP,NodePort,LoadBalancer,ExternalName,预设是ClusterIP
selector:
app.kubernetes.io/name=test-myapp #要被存取的pod 名称
ports: # 在service上面可以开多个接口,只要不重覆port就好了,像是服务有支援REST或是gRPC,就可以分别开二个port出来对应Http server跟gRPC server
- protocol: TCP
port: 80
targetPort: 80
- protocol: TCP
port: 8787
targetPort: 8787
除了写service yaml外,也可以透过kubectl expose 做到一样的是事情
kubectl expose deployment test-myapp --type=ClusterIP --name=test-myapp
selector对应的关系图可以参考官方这张图,简单说就是透过selector的label去对应Deployment
图片来源
kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
test-myapp ClusterIP 10.182.153.226 <none> 80/TCP,8787/TCP 10m
ClusterIP
: only for cluster内部使用,也是default Service type
NodePort
: 可以让pod透过设定好的NodePort供外部服务存取,有点像是在Node上面打个小小洞,让外面服务可以透过这个小小洞与内部pod沟通,这种做法有几个缺点
LoadBalancer
:如果要把服务暴露给外部使用时,就可以使用LoadBalancer模式,一般是在AKS,GKE,EKS公有云上使用时才会使用。
ExternalName
:将服务mapping到dns名称,因为这个没什麽使用的情境..所以可以参加这边的说明 官方externalname说明
透过Service就可以轻松的把Deployment expose出去给其他服务呼叫罗
这边推荐一下官方的tutorials,手把手教你使用service吧服务expose出去
>>: AI ninja project [day 18] Multi-Modal and Multi-Task
终於开赛第29天已经无梗很多天罗,因为实在不太想写一些平常入坑scss基本原理东西,毕竟觉得有碰就会...
前言: 之前提到 我一直在想办法让原本的训练模型 转成IOS可以用的模型 但找了许多方法後 还是没成...
我把从第一天到现在每天的 Home 目录都放上 GitHub 了,README.md 里面有说明 ...
@前言 今年规划好的新产品准备上市,所以开始准备"安装包"的设计与规划, 自告奋...
此刻所发生的所有事,都是你之前选择的结果。 Everything that is happening...