【Kubernetes】k8s的svc所有概念和实操详细说明（含镜像和代码）【1】【svc作用是端口转发相关

由于篇幅限制，小编在此截出几张知识讲解的图解一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！[外链图片转存中…(img-GszYJ3l0-1712790759808)][外链图片转存中…(img-nSHHjxWh-1712790759808)][外链

2401_84140734

1363人浏览 · 2024-04-11 07:12:55

2401_84140734 · 2024-04-11 07:12:55 发布

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:

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:

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:

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:

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的地址信息

k8s代理模式的分类

=========================================================================

VIP 和 Service 代理

在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层调度的功能。

为何不使用 round-robin DNS?

k8s不管是历史还是现在都没有使用过DNS，不采用DNS负载均衡集群，最大最有意义的一点就是DNS会在很多的客户端里进行缓存，很对服务访问DNS进行域名解析的时候解析完成以后得到地址以后很多的服务都不会对DNS的缓存进行清除，也就意味着只要缓存存在服务在下次访问的时候还是这个地址信息，因此也就达不到我们负载均衡的要求了，因此DNS一般仅仅作为负载均衡的一种辅助手段

userspace代理模式