selector:
matchLabels:
app: myapp
release: stabel
template:
metadata:
1abels:
app: myapp
release: stabel
env: test
spec:
containers:
- name: myapp
image: fanqisoft/myapp:v2
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 80
apiVersion: v1
kind: Service
metadata:
name: myapp
namespace: default
spec:
type: ClusterIP
selector:
app: myapp
release: stabel
ports:
- name: http
port: 80
targetPort: 80
Headless Service【无头服务，无头服务也是一种Cluster IP,只不过是一种特殊的Cluster IP】
-
有时不需要或不想要负载均衡，以及单独的Service IP。遇到这种情况，可以通过指定 ClusterIP(spec.clusterIP)的值为“None”来创建 Headless Service。这类Service 并不会分配 Cluster IP,kube-proxy 不会处理它们，而且平台也不会为它们进行负载均衡和路由
-
主要的特点是通过无头服务的方式去解决hostname和portname的变化问题，也就是通过它去进行绑定
apiVersion: v1
kind: Service
metadata:
name: myapp-headless
namespace: default
spec:
selector:
app: myapp
clusterIP: “None”
ports:
- port: 80
targetPort: 80
- 对于svc，一旦创建成功以后，它会写入到coreDNS中去，我们的svc的创建会有一个主机名会被写入到coreDNS，写入的格式体就是 svc的名称+命名空间的名称+当前集群的域名
yum -y install bind-utils
dig -t A myapp-headless.default.svc.cluster.local. @10.96.0.10
- 意味着在无头服务中，虽然它没有ip了，但可以通过访问域名的方案依然可以访问服务下的pod
NodePort【外部访问】
- nodePort的原理在于在node上开了一个端口，将向该端口的流量导入到kube-proxy，然后由 kube-proxy进一步到给对应的pod
apiVersion: v1
kind: Service
metadata:
name: myapp
namespace: default
spec:
type: NodePort
selector:
app: myapp
release: stabel
ports:
- name: http
port: 80
targetPort: 80
- 查询流程
iptables -t nat -nvL
KUBE-NODEPORTS
LoadBalancer【外部负载均衡】
- loadBalancer和nodePort 其实是同一种方式。区别在于 loadBalancer 比nodePort多了一步，就是可以调用cloud provider【云供应商】 去创建LB【负载均衡】来向节点导流
ExternalName【直达模式】
- 这种类型的 Service 通过返回 CNAME和它的值，可以将服务映射到externalName字段的内容（例如：hub.coreqi.cn)。ExternalName Service 是Service的特例，它没有 selector，也没有定义任何的端口和Endpoint。相反的，对于运行在集群外部的服务，它通过返回该外部服务的别名这种方式来提供服务
apiVersion: v1
kind: Service
metadata:
name: my-service
namespace: default
spec:
type: ExternalName
externalName: hub.coreqi.cn
当查询主机 my-service.defalut.svc.cluster.local（SVC_NAME.NAMESPACE.svc.cluster.local)时，集群的DNS 服务将返回一个值my.database.example.com的CNAME记录。访问这个服务的工作方式和其他的相同，唯一不同的是重定向发生在DNS层，而且不会进行代理或转发。
实现原理
-
总结：
-
客户端访问节点【pod】时通过iptables实现的
-
iptables规则是通过kube-proxy写入的
-
apiserver通过监控kube-proxy去进行对服务和端点的监控
-
apiserver通过监控kube-proxy去实现服务端点信息的发现
-
kube-proxy通过pod的标签（lables）去判断这个断点信息是否写入到Endpoints里去
-
kube-proxy:通过选择标签去监控对应的pod并写入到iptable规则里面去
-
客户端访问服务时通过iptables中的规则被定向到pod的地址信息
=========================================================================
-
在Kubernetes集群中，每个Node 运行一个kube-proxy 进程。kube-proxy负责为service 实现了一种VIP（虚拟IP）的形式【可以在集群内部直接访问】，而不是ExternalName【返回集群外部的地址信息】 的形式。在Kubernetes v1.0版本，代理完全由userspace实现。在Kubernetesv1.1版本，新增了iptables代理，但并不是默认的运行模式。从Kubernetesv1.2起，默认就是iptables 代理。在Kubernetes v1.8.0-beta.0中，添加了ipvs代理
-
在Kubernetes 1.14版本开始默认使用ipvs代理
-
在Kubernetes v1.0版本，service是“4层”（TCP/UDP over IP)概念。在Kubernetes v1.1版本，新增了IngressAPI(beta版)，用来表示“7层”（HTTP）服务！可以进行7层的负载均衡。正是因为有了Ingress的API接口，我们才有了7层调度的功能。
k8s不管是历史还是现在都没有使用过DNS，不采用DNS负载均衡集群，最大最有意义的一点就是DNS会在很多的客户端里进行缓存，很对服务访问DNS进行域名解析的时候解析完成以后得到地址以后很多的服务都不会对DNS的缓存进行清除，也就意味着只要缓存存在服务在下次访问的时候还是这个地址信息，因此也就达不到我们负载均衡的要求了，因此DNS一般仅仅作为负载均衡的一种辅助手段
- 客户端首先访问iptables通过iptables访问到kube-proxy然后访问到具体的pod上
也就是说每次访问的时候都需要Kube-proxy进行一次代理
也就是说kube-proxy压力是非常大的
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新
如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注Java）
最后
由于篇幅限制，小编在此截出几张知识讲解的图解
一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
MR2vPi-1712790759807)]
[外链图片转存中…(img-GszYJ3l0-1712790759808)]
[外链图片转存中…(img-nSHHjxWh-1712790759808)]
[外链图片转存中…(img-w6REH6Co-1712790759808)]
[外链图片转存中…(img-VKWUU9Y7-1712790759808)]
一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
[外链图片转存中…(img-h51Hjmqj-1712790759809)]
6051
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
