本文必须会iptables知识，B站随便找个视频，2倍数一小时肯定能看完了。
第七章 Service详解
k8s的流量负载组件：Service和Ingress。
一、service介绍
一个Kubernetes的Service是一种抽象，它定义了一组Pods的逻辑集合和一个用于访问它们的策略（有的时候被称之为微服务）。一个Service的目标Pod集合通常是由Label Selector 来决定的（下面有讲一个没有选择器的Service 有什么用处）。
举个例子，想象一个处理图片的后端运行了三个副本。这些副本都是可以替代的 - 前端不关心它们使用的是哪一个后端。尽管实际组成后端集合的Pod可能会变化，前端的客户端却不需要知道这个变化，也不需要自己有一个列表来记录这些后端服务。Service抽象能让你达到这种解耦。
通俗的讲：SVC负责检测Pod的状态信息，不会因pod的改动IP地址改变（因为关注的是标签），导致Nginx负载均衡影响
不像 Pod 的 IP 地址，它实际路由到一个固定的目的地，Service 的 IP 实际上不能通过单个主机来进行应答。相反，我们使用 iptables（Linux 中的数据包处理逻辑）来定义一个虚拟IP地址（VIP），它可以根据需要透明地进行重定向。当客户端连接到 VIP 时，它们的流量会自动地传输到一个合适的 Endpoint。环境变量和 DNS，实际上会根据 Service 的 VIP 和端口来进行填充。
endpoint是什么；TCP
1）service启用的原因
在kubernetes中，pod是应用程序的载体，我们可以通过pod的ip来访问应用程序，但是pod的ip地址不是固定的，这也就意味着不方便直接采用pod的ip对服务进行访问。
为了解决这个问题，kubernetes提供了Service资源，Service会对提供同一个服务的多个pod进行聚合，并且提供一个统一的入口地址。通过访问Service的入口地址就能访问到后面的pod服务。
假设当我们的前端页面有多个Pod时候，同时后端也多个Pod，这个时候，他们之间的相互访问，就需要通过注册中心，拿到Pod的IP地址，然后去访问对应的Pod
2）deployment的缺陷
Deployment只是保证了支撑服务的微服务Pod的数量，但是没有解决如何访问这些服务的问题。一个Pod只是一个运行服务的实例，随时可能在一个节点上停止，在另一个节点以一个新的IP启动一个新的Pod，因此不能以确定的IP和端口号提供服务。要稳定地提供服务需要服务发现和负载均衡能力。服务发现完成的工作，是针对客户端访问的服务，找到对应的后端服务实例。在K8S集群中，客户端需要访问的服务就是Service对象。每个Service会对应一个集群内部有效的虚拟IP，集群内部通过虚拟IP访问一个服务。
3）IP
从service分析下IP
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 90d
service/nginx NodePort 10.99.202.231 <none> 80:30440/TCP 90d
service/tomcat6 NodePort 10.111.109.200 <none> 80:30138/TCP 4m2s
可以看到service的类型。
可以把service当做是虚拟机里的进程，所以我们可以直接访问service的端口
pod和service建立关联的方式：标签
我们在访问service的时候，其实也是需要有一个ip地址，这个ip肯定不是pod的ip地址，而是 虚拟IP ，简称vip
service与pod的关系
service-》endpoints-》pod
kubectl describe endpoints service1
会发现endpoints标记这IP数字，可用和不可用
endpoints是和service同步创建删除的
4）端口
- port
- targetPort：pod端口，也就是容器端口
- NodePort：类型是NodePort时才有效，自己配置时候要确保每个node上该端口都没被占用。不指定的话就是动态分配
4）原理
Service在很多情况下只是一个概念，真正起作用的其实是kube-proxy服务进程，每个Node节点上都运行着一个kube-proxy服务进程。当创建Service的时候会通过api-server向etcd写入创建的service的信息，而kube-proxy会基于监听的机制发现这种Service的变动，然后它会将最新的Service信息转换成对应的访问规则。
在K8S集群中，微服务的负载均衡是由kube-proxy实现的。kube-proxy是k8s集群内部的负载均衡器。它是一个分布式代理服务器，在K8S的每个节点上都有一个；这一设计体现了它的伸缩性优势，需要访问服务的节点越多，提供负载均衡能力的kube-proxy就越多，高可用节点也随之增多。与之相比，我们平时在服务器端使用反向代理作负载均衡，还要进一步解决反向代理的高可用问题。
service存在的意义：
- 防止pod失联（服务发现）
- 定义pod访问策略（负载均衡）
页面前端的Pod访问到后端的Pod，中间会通过
Service一层，而Service在这里还能做负载均衡，负载均衡的策略有很多种实现策略，例如：
- 随机
- 轮询
- 响应比
# 10.97.97.97:80 是service提供的访问入口
# 当访问这个入口的时候，可以发现后面有三个pod的服务在等待调用，
# kube-proxy会基于rr（轮询）的策略，将请求分发到其中一个pod上去
# 这个规则会同时在集群内的所有节点上都生成，所以在任何一个节点上访问都可以。
[root@node1 ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 10.97.97.97:80 rr
-> 10.244.1.39:80 Masq 1 0 0
-> 10.244.1.40:80 Masq 1 0 0
-> 10.244.2.33:80 Masq 1 0 0
service导论
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-gfklcKrh-1636721333037)(https://pics7.baidu.com/feed/9c16fdfaaf51f3de9eb2bbca234789183b297948.jpeg?token=6b33942e4d8d3a0636069832368be3c6)]
- 客户端访问节点时通过 iptables实现的
- iptables规则是通过 kube-proxy写入的（iptables不再master中，在工作结点中）
- apiserver通过监控 kube-proxy去进行对服务和端点的监控
- kube-proxy通过 pod的标签（ lables）去判断这个断点信息是否写入到 Endpoints里
代理
VIP 和 Service 代理
在 Kubernetes集群中，每个 Node运行一个 kube-proxy进程。 kube-proxy负责为 Service实现了一种 VIP（虚拟 IP）的形式，而不是 ExternalName的形式。
- 在 Kubernetes v1.0版本，代理完全在
userspace。 - 在 Kubernetes v1.1版本，新增了
iptables代理，但并不是默认的运行模式。 - 从 Kubernetes v1.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版本，新增了 Ingress API（ beta版），用来表示 7 层（ HTTP）服务为何不使用 round-robin DNS？
DNS会在很多的客户端里进行缓存，很多服务在访问 DNS进行域名解析完成、得到地址后不会对 DNS的解析进行清除缓存的操作，所以一旦有他的地址信息后，不管访问几次还是原来的地址信息，导致负载均衡无效
三、service的三种代理模式
举个例子，想象一个处理图片的后端运行了三个副本。这些副本都是可以替代的 - 前端不关心它们使用的是哪一个后端。尽管实际组成后端集合的
Pod可能会变化，前端的客户端却不需要知道这个变化，也不需要自己有一个列表来记录这些后端服务。Service抽象能让你达到这种解耦。不像
Pod的 IP 地址，它实际路由到一个固定的目的地，Service的 IP 实际上不能通过单个主机来进行应答。 相反，我们使用iptables（Linux 中的数据包处理逻辑）来定义一个虚拟IP地址（VIP），它可以根据需要透明地进行重定向。 当客户端连接到 VIP 时，它们的流量会自动地传输到一个合适的Endpoint。 环境变量和 DNS，实际上会根据Service的 VIP 和端口来进行填充。
kube-proxy目前支持三种工作模式（代理模式）：下面3个模式也是k8s的发展历程
- userspace：1.1-
- iptables：1.10-
- ipvs：1.11+
1）userspace 模式
userspace模式下，kube-proxy会为每一个Service创建一个监听端口，发向Cluster IP的请求被Iptables规则重定向到kube-proxy监听的端口上，kube-proxy根据LB算法选择一个提供服务的Pod并和其建立链接，以将请求转发到Pod上。
作为一个例子，考虑前面提到的图片处理应用程序。 当创建 backend
Service时，k8s master 会给它指派一个虚拟 V IP 地址，比如10.0.0.1。 假设Service的端口是 1234，该Service会被集群中所有的kube-proxy实例观察到。 当kube-proxy看到一个新的Service， 它会打开一个新的端口，建立一个从该 VIP 重定向到新端口的 iptables，并开始接收请求连接。当一个客户端连接到一个 VIP，iptables 规则开始起作用，它会重定向该数据包到
Service代理的端口。Service代理选择一个 backend，并将客户端的流量代理到 backend 上。这意味着
Service的所有者能够选择任何他们想使用的端口，而不存在冲突的风险。 客户端可以简单地连接到一个 IP 和端口，而不需要知道实际访问了哪些Pod。
该模式下，kube-proxy充当了一个四层负责均衡器的角色。由于kube-proxy运行在userspace中，在进行转发处理时会增加内核和用户空间之间的数据拷贝，虽然比较稳定，但是效率比较低。
比如下图中的client Pod，
- 请求某个结点时先到达ipvs（就是service规则），这里是内核空间
- 然后转到用户空间的kube-proxy，
- 处理完后再转给ipvs（serviceIP），
- 然后再转给右面的kube-proxy，
- 然后再转给pod2
下面图的流程：client发起
2）iptables 模式
iptables是什么？
我强烈建议你先花半天时间学习iptables。iptables是系统内核管理网络的，他是防火墙的一种，在iptables里可以指定什么样的报文可以访问本机，也可以指定在发送的过程中报文的IP、端口等信息如何变化才能使得报文正常发送出去
iptables模式下，kube-proxy为service后端的每个Pod创建对应的iptables规则，直接将发向Cluster IP的请求重定向到一个Pod IP。
该模式下kube-proxy不承担四层负责均衡器的角色，只负责创建iptables规则。
再次考虑前面提到的图片处理应用程序。 当创建 backend
Service时，Kubernetes 控制面板会给它指派一个虚拟 IP 地址，比如 10.0.0.1。 假设Service的端口是 1234，该Service会被集群中所有的kube-proxy实例观察到。 当代理看到一个新的Service， 它会配置一系列的 iptables 规则，从 VIP 重定向到 per-Service规则。 该 per-Service规则连接到 per-Endpoint规则，该 per-Endpoint规则会重定向（目标 NAT）到 backend。当一个客户端连接到一个 VIP，iptables 规则开始起作用。一个 backend 会被选择（或者根据会话亲和性，或者随机），数据包被重定向到这个 backend。 不像 userspace 代理，数据包从来不拷贝到用户空间，kube-proxy 不是必须为该 VIP 工作而运行，并且客户端 IP 是不可更改的。 当流量打到 Node 的端口上，或通过负载均衡器，会执行相同的基本流程，但是在那些案例中客户端 IP 是可以更改的。
优点：
- 较userspace模式效率更高，
缺点：
- 不能提供灵活的LB策略，
- 当后端Pod不可用时也无法进行重试。
直接请求iptables 不请求kube-proxy了
下面图是流程，client发起
3）ipvs 模式
ipvs模式和iptables类似，kube-proxy监控Pod的变化并创建相应的ipvs规则。
ipvs相对iptables转发效率更高。除此以外，ipvs支持更多的LB算法。
在大规模集群（例如10,000个服务）中，iptables 操作会显着降低速度。IPVS 专为负载平衡而设计，并基于内核内哈希表。因此，您可以通过基于 IPVS 的 kube-proxy 在大量服务中实现性能一致性。同时，基于 IPVS 的 kube-proxy 具有更复杂的负载平衡算法（最小连接，局部性，加权，持久性）。
新增pod时会反映到api-service上，然后Kube-proxy监听到变化后，转为ipvs
ipvs代理模式中 kube-proxy会监视 Kubernetes Service对象和 Endpoints，调用 netlink接口以相应地创建 ipvs规则并定期与 Kubernetes Service对象和 Endpoints对象同步 ipvs规则，以确保 ipvs状态与期望一致。访问服务时，流量将被重定向到其中一个后端 Pod。
与 iptables类似， ipvs于 netfilter的 hook功能，但使用哈希表作为底层数据结构并在内核空间中工作。这意味着 ipvs可以更快地重定向流量，并且在同步代理规则时具有更好的性能。此外， ipvs为负载均衡算法提供了更多选项，例如：
rr：轮询调度lc：最小连接数dh：目标哈希sh：源哈希sed：最短期望延迟nq：不排队调度
# 此模式必须安装ipvs内核模块，否则会降级为iptables
# 开启ipvs
[root@master ~]# kubectl edit cm kube-proxy -n kube-system
[root@master ~]# kubectl delete pod -l k8s-app=kube-proxy -n kube-system
[root@node1 ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 10.97.97.97:80 rr
-> 10.244.1.39:80 Masq 1 0 0
-> 10.244.1.40:80 Masq 1 0 0
-> 10.244.2.33:80 Masq 1 0 0
四、service类型
ClusterIP、NodePort、LoadBalancer、ExternalName
- ClusterIP：（默认值），它是Kubernetes系统自动分配的虚拟IP，只能在集群内部访问
- NodePort：将Service通过指定的Node上的端口暴露给外部，通过此方法，就可以在集群外部访问服务
- [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KwAoQxdA-1636721333046)(https://pics7.baidu.com/feed/9a504fc2d56285351ba8bbad24460fc1a6ef6327.jpeg?token=c187920e3eb7dc022dfbf88128e74b33)]
- LoadBalancer：使用外接负载均衡器完成到服务的负载分发，注意此模式需要外部云环境支持
- 正常情况下是填冲个外部负载到一个node上，然后再由service负载到一个pod上，这叫2级负载均衡。
- 在NodePort的基础上，借助Cloud Provider创建一个外部负载均衡器，并将请求转发到NodePort
- [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VfrMnotj-1636721333047)(https://pics1.baidu.com/feed/80cb39dbb6fd5266a48f33a41eb1ee2cd507360e.jpeg?token=8e5440ea8bb9dff121cd8a08a6af5a39)]
- ExternalName： 把集群外部的服务引入集群内部，直接使用
Service的资源清单文件：
kind: Service # 资源类型
apiVersion: v1 # 资源版本
metadata: # 元数据
name: service # 资源名称
namespace: dev # 命名空间
spec: # 描述
selector: # 标签选择器，用于确定当前service代理哪些pod
app: nginx
type: # Service类型，指定service的访问方式
clusterIP: # 虚拟服务的ip地址
sessionAffinity: # session亲和性，支持ClientIP、None两个选项
ports: # 端口信息
- protocol: TCP
port: 3017 # service端口
targetPort: 5003 # pod端口
nodePort: 31122 # 主机端口
3.1 ClusterIp
ClusterIP主要在每个node节点使用iptables，将发向ClusterIP对应端口的数据，转发到kube-proxy中。然后kube-proxy自己内部实现有负载均衡的方法，并可以查询到这个service下对应pod的地址和端口，进而把数据转发给对应的pod的地址和端口。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8S8snXfw-1636721333048)(https://pics2.baidu.com/feed/7acb0a46f21fbe09736a0844ddc975348644addf.jpeg?token=a2f401bcfddedf77bbdb07cba64d04ca)]
为了实现图上的功能，主要需要以下几个组件的协同工作：
- apiserver：用户通过 kubectl命令向 apiserver发送创建 service的命令， apiserver接收到请求后将数据存储到 etcd中
- kube-proxy： Kubernetes的每个节点中的 kube-porxy进程负责感知 service、 pod的变化，并将变化的信息写入本地的 iptables规则中
- iptables：使用 NAT等技术将 virtualIP的流量转至 endpoint中
创建 myapp-deploy.yaml文件
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0NnbEH3M-1636721333049)(https://pics3.baidu.com/feed/241f95cad1c8a78624f9df41d3a0b03a72cf50db.png?token=37a7e659ea2bd921a20ad45d2bfb433a)]
创建 Service信息：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-oiohm216-1636721333050)(https://pics1.baidu.com/feed/314e251f95cad1c86f530ab4ca971e0ecb3d51ee.png?token=727010dc64c8900dfe91caae263bd382)]
执行命令：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wT2DxPaY-1636721333051)(https://pics4.baidu.com/feed/e1fe9925bc315c60318637583918b214485477a2.png?token=51de57a4fe640f8a45bb18ed90f6b018)]
3.2 Handless Service
有时不需要或不想要负载均衡，以及单独的 Service IP。遇到这种情况，可以通过指定 spec.clusterIP的值为 None来创建 Headless Service 。这类 Service并不会分配 Cluster IP， kube-proxy不会处理它们，而且平台也不会为它们进行负载均衡和路由。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-g517B2BX-1636721333051)(https://pics0.baidu.com/feed/5ab5c9ea15ce36d3c4f1ad758e5a4380e850b12a.png?token=ef69575134070dc2288effd7dce20ea5)]
3.3 NodePort
NodePort的原理在于在 Node上开了一个端口，将向该端口的流量导入到 kube-proxy，然后由 kube-proxy进一步到给对应的 pod。
创建 Service信息：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-sE5XCPNj-1636721333053)(https://pics5.baidu.com/feed/0df431adcbef76099b0ddbfc9a74dacb7dd99e84.png?token=839edf2983f5631e02ddf234bc2a8530)]
执行命令：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-r3kZyPXg-1636721333054)(https://pics5.baidu.com/feed/72f082025aafa40f3875b4a71dcd7a4879f0194d.png?token=177d5f77a08c7bfa1d420250e61bc589)]
3.4 LoadBalancer
LoadBalancer和NodePort其实是同一种方式。区别在于LoadBalancer比NodePort多了一步，就是可以调用Cloud provider去创建LB来向节点导流。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-XFc8T0Je-1636721333054)(https://pics5.baidu.com/feed/3801213fb80e7bec5b7875649b87c03f99506bc1.jpeg?token=cb51203f28cf70d653079ec5e348f628)]
3.5 ExternalName
这种类型的 Service通过返回 CNAME和它的值，可以将服务映射到 externalName字段的内容( 例： hub.hc.com )。
ExternalName Service是 Service的特例，它没有 selector，也没有定义任何的端口和 Endpoint。相反的，对于运行在集群外部的服务，它通过返回该外部服务的别名这种方式来提供服务。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7AjGNdkt-1636721333055)(https://pics4.baidu.com/feed/4a36acaf2edda3cc6433bfe5b4404006233f9254.png?token=70a2320412bf455391545d35547ed481)]
当查询主机 my-service.defalut.svc.cluster.local时，集群的 DNS服务将返回一个值 hub.hc.com的 CNAME记录。访问这个服务的工作方式和其他的相同，唯一不同的是重定向发生在 DNS层，而且不会进行代理或转发。
3个端口区别
口诀：2长夹一短
1. nodePort
外部机器可访问的端口。
比如一个Web应用需要被其他用户访问，那么需要配置type=NodePort，而且配置nodePort=30001，那么其他机器就可以通过浏览器访问scheme://node:30001访问到该服务，例如http://node:30001。
例如MySQL数据库可能不需要被外界访问，只需被内部服务访问，那么不必设置NodePort
2. targetPort
容器的端口（最根本的端口入口），与制作容器时暴露的端口一致（DockerFile中EXPOSE），例如docker.io官方的nginx暴露的是80端口。
docker.io官方的nginx容器的DockerFile参考https://github.com/nginxinc/docker-nginx
3. port
kubernetes中的服务之间访问的端口，尽管mysql容器暴露了3306端口（参考https://github.com/docker-library/mysql/的DockerFile），但是集群内其他容器需要通过3306端口访问该服务，外部机器不能访问mysql服务，因为他没有配置NodePort类型
五、Service使用
实验环境准备
在使用service之前，首先利用Deployment创建出3个pod，注意要为pod设置app=nginx-pod的标签
创建deployment.yaml，内容如下：
apiVersion: apps/v1
kind: Deployment #
metadata:
name: pc-deployment
namespace: dev
spec:
replicas: 3
selector:
matchLabels:
app: nginx-pod # 标签
template:
metadata:
labels:
app: nginx-pod
spec:
containers:
- name: nginx
image: nginx:1.17.1
ports:
- containerPort: 80
[root@master ~]# kubectl create -f deployment.yaml
deployment.apps/pc-deployment created
# 查看pod详情
[root@master ~]# kubectl get pods -n dev -o wide --show-labels
NAME READY STATUS IP NODE LABELS
pc-deployment-66cb59b984-8p84h 1/1 Running 10.244.1.40 node1 app=nginx-pod
pc-deployment-66cb59b984-vx8vx 1/1 Running 10.244.2.33 node2 app=nginx-pod
pc-deployment-66cb59b984-wnncx 1/1 Running 10.244.1.39 node1 app=nginx-pod
# 为了方便后面的测试，修改下三台nginx的index.html页面（三台修改的IP地址不一致）
# kubectl exec -it pc-deployment-66cb59b984-8p84h -n dev /bin/sh
# echo "10.244.1.40" > /usr/share/nginx/html/index.html
#修改完毕之后，访问测试
[root@master ~]# curl 10.244.1.40
10.244.1.40
[root@master ~]# curl 10.244.2.33
10.244.2.33
[root@master ~]# curl 10.244.1.39
10.244.1.39
在虚拟机上可以访问pod的IP
在大规模集群（例如10,000个服务）中，iptables 操作会显着降低速度。 IPVS 专为负载平衡而设计，并基于内核内哈希表。 因此，您可以通过基于 IPVS 的 kube-proxy 在大量服务中实现性能一致性。 同时，基于 IPVS 的 kube-proxy 具有更复杂的负载平衡算法（最小连接，局部性，加权，持久性）。
下面我们详细说下k8s支持的4种类型的Service。
1）ClusterIP类型
apiVersion: v1
kind: Service
metadata:
name: service-python
spec:
ports:
- port: 3000 # service端口
protocol: TCP
targetPort: 443 # pod端口
selector:
run: pod-python
type: ClusterIP
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-D23LHG26-1636721333057)(https://segmentfault.com/img/remote/1460000023125590)]
类型为ClusterIP的service，这个service有一个Cluster-IP，其实就一个VIP。具体实现原理依靠kubeproxy组件，通过iptables或是ipvs实现。
这种类型的service 只能在集群内访问。
创建service-clusterip.yaml文件
apiVersion: v1
kind: Service
metadata:
name: service-clusterip
namespace: dev
spec:
selector:
app: nginx-pod
clusterIP: 10.97.97.97 # service的ip地址，如果不写，默认会生成一个
type: ClusterIP
ports:
- port: 80 # Service端口
targetPort: 80 # pod端口
# 创建service
[root@master ~]# kubectl create -f service-clusterip.yaml
service/service-clusterip created
# 查看service
[root@master ~]# kubectl get svc -n dev -o wide
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
service-clusterip ClusterIP 10.97.97.97 <none> 80/TCP 13s app=nginx-pod
# 查看service的详细信息
# 在这里有一个Endpoints列表，里面就是当前service可以负载到的服务入口
[root@master ~]# kubectl describe svc service-clusterip -n dev
Name: service-clusterip
Namespace: dev
Labels: <none>
Annotations: <none>
Selector: app=nginx-pod
Type: ClusterIP
IP: 10.97.97.97
Port: <unset> 80/TCP
TargetPort: 80/TCP
Endpoints: 10.244.1.39:80,10.244.1.40:80,10.244.2.33:80
Session Affinity: None
Events: <none>
# 查看ipvs的映射规则
[root@master ~]# ipvsadm -Ln
TCP 10.97.97.97:80 rr
-> 10.244.1.39:80 Masq 1 0 0
-> 10.244.1.40:80 Masq 1 0 0
-> 10.244.2.33:80 Masq 1 0 0
# 访问10.97.97.97:80观察效果
[root@master ~]# curl 10.97.97.97:80
10.244.2.33
Endpoint
Endpoint是kubernetes中的一个资源对象，存储在etcd中，用来记录一个service对应的所有pod的访问地址，它是根据service配置文件中selector描述产生的。
一个Service由一组Pod组成，这些Pod通过Endpoints暴露出来，Endpoints是实现实际服务的端点集合。换句话说，service和pod之间的联系是通过endpoints实现的。
[root@master ~]# kubectl get endpoints -n dev -o wide
NAME ENDPOINTS AGE
service-clusterip 172.17.0.2:80,172.17.0.3:80,172.17.0.4:80 5m38s
负载分发策略
对Service的访问被分发到了后端的Pod上去，目前kubernetes提供了两种负载分发策略：
-
如果不定义，默认使用kube-proxy的策略，比如随机、轮询
-
基于客户端地址的会话保持模式，即来自同一个客户端发起的所有请求都会转发到固定的一个Pod上
此模式可以使在spec中添加
sessionAffinity:ClientIP选项
# 查看ipvs的映射规则【rr 轮询】
[root@master ~]# ipvsadm -Ln
TCP 10.97.97.97:80 rr
-> 10.244.1.39:80 Masq 1 0 0
-> 10.244.1.40:80 Masq 1 0 0
-> 10.244.2.33:80 Masq 1 0 0
# 循环访问测试
[root@master ~]# while true;do curl 10.97.97.97:80; sleep 5; done;
10.244.1.40
10.244.1.39
10.244.2.33
10.244.1.40
10.244.1.39
10.244.2.33
# 修改分发策略----sessionAffinity:ClientIP
# 查看ipvs规则【persistent 代表持久】
[root@master ~]# ipvsadm -Ln
TCP 10.97.97.97:80 rr persistent 10800
-> 10.244.1.39:80 Masq 1 0 0
-> 10.244.1.40:80 Masq 1 0 0
-> 10.244.2.33:80 Masq 1 0 0
# 循环访问测试
[root@master ~]# while true;do curl 10.97.97.97; sleep 5; done;
10.244.2.33
10.244.2.33
10.244.2.33
# 删除service
[root@master ~]# kubectl delete -f service-clusterip.yaml
service "service-clusterip" deleted
1.2）HeadLiness类型
无头service
在某些场景中，开发人员可能不想使用Service提供的负载均衡功能，而希望自己来控制负载均衡策略，针对这种情况，kubernetes提供了HeadLiness Service，这类Service不会分配Cluster IP，如果想要访问service，只能通过service的域名进行查询。
在一个集群中有这个几个组件：pod-a，svc-b，pod-b1，pod-b2。当 pod-a 想访问 pod-b 中的应用程序时，先会把请求打到 svc-b，再由 svc-b 将请求随机转发到 pod-b1或 pod-b2。
如果有个需求：pod-a 需要同时连接到 pod-b1和 pod-b2 ，这时再采用 svc-b 转发显然已经不能满足需求了。那 pod-a 该如何获取到 pod-b1和 pod-b2 的 IP 地址呢？采用 handless service 就可以实现。即无头service。
当 service 的 type: ClusterIP、clusterIP = None 时，该 service 就是 handless service。
无需使用外部IP
apiVersion: v1
kind: Service
metadata:
name: service-headliness
namespace: dev
spec:
selector:
app: nginx-pod
clusterIP: None # 将clusterIP设置为None，即可创建headliness Service
type: ClusterIP # type还是ClusterIP
ports:
- port: 80
targetPort: 80
# 创建service
[root@master ~]# kubectl create -f service-headliness.yaml
service/service-headliness created
# 获取service， 发现CLUSTER-IP未分配
[root@master ~]# kubectl get svc service-headliness -n dev -o wide
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
service-headliness ClusterIP None <none> 80/TCP 11s app=nginx-pod
# 查看service详情
[root@master ~]# kubectl describe svc service-headliness -n dev
Name: service-headliness
Namespace: dev
Labels: <none>
Annotations: <none>
Selector: app=nginx-pod
Type: ClusterIP
IP: None
Port: <unset> 80/TCP
TargetPort: 80/TCP
Endpoints: 10.244.1.39:80,10.244.1.40:80,10.244.2.33:80
Session Affinity: None
Events: <none>
# 查看域名的解析情况
[root@master ~]# kubectl exec -it pc-deployment-66cb59b984-8p84h -n dev /bin/sh
/ # cat /etc/resolv.conf
nameserver 10.96.0.10
search dev.svc.cluster.local svc.cluster.local cluster.local
[root@master ~]# dig @10.96.0.10 service-headliness.dev.svc.cluster.local
service-headliness.dev.svc.cluster.local. 30 IN A 10.244.1.40
service-headliness.dev.svc.cluster.local. 30 IN A 10.244.1.39
service-headliness.dev.svc.cluster.local. 30 IN A 10.244.2.33
自己对该k8s网络部分认识有限，多贴点内容理解一下
最近在基于K8S开发平台的过程中遇到了有个问题没有弄懂，就是CoreDNS的作用，就好像在Docker Swarm里面，我们可以通过Service name来访问一组容器，在K8S里，我们想要通过name来访问服务的方式就是在Deployment上面添加一层Servic，这样我们就可以通过Service name来访问服务了，那其中的原理就是和CoreDNS有关，它将Service name解析成Cluster IP，这样我们访问Cluster IP的时候就通过Cluster IP作负载均衡，把流量分布到各个POD上面。
我想的问题是CoreDNS是否会直接解析POD的name，在Service的服务里，是不可以的，因为Service有Cluster IP，直接被CoreDNS解析了，那怎么才能让它解析POD呢，有大牛提出了可以使用Headless Service，所以我们就来探究一下什么是Headless Service。
Headless Service也是一种Service，但不同的是会定义spec:clusterIP: None，也就是不需要Cluster IP的Service。
我们首先想想Service的Cluster IP的工作原理：一个Service可能对应多个EndPoint(Pod)，client访问的是Cluster IP，通过iptables规则转到Real Server，从而达到负载均衡的效果。具体操作如下所示：# kubectl get svc NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx-service 10.107.124.218 192.168.128.158 80/TCP,443/TCP 1d # kubectl describe svc nginx-service Name: nginx-service Namespace: default Labels: Selector: component=nginx Type: ClusterIP IP: 10.107.124.218 External IPs: 192.168.128.158 Port: nginx-http 80/TCP Endpoints: 10.244.2.9:80 Port: nginx-https 443/TCP Endpoints: 10.244.2.9:443 Session Affinity: None No events. # nslookup nginx-service.default.svc.cluster.local 10.96.0.10 Server: 10.96.0.10 Address: 10.96.0.10#53 Name: nginx-service.default.svc.cluster.local Address: 10.107.124.218从上面的结果中我们可以看到虽然
Service有2个endpoint，但是dns查询时只会返回Service的地址。具体client访问的是哪个Real Server，是由iptables来决定的。那么我们再来看看
Headless Service的效果呢？# kubectl get service NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx None 80/TCP 1h # kubectl describe service nginx Name: nginx Namespace: default Labels: app=nginx Selector: app=nginx Type: ClusterIP IP: None Port: web 80/TCP Endpoints: 10.244.2.17:80,10.244.2.18:80 Session Affinity: None No events. # nslookup nginx.default.svc.cluster.local 10.96.0.10 Server: 10.96.0.10 Address: 10.96.0.10#53 Name: nginx.default.svc.cluster.local Address: 10.244.2.17 Name: nginx.default.svc.cluster.local Address: 10.244.2.18根据结果得知dns查询会如实的返回2个真实的endpoint。
所以，顾名思义，Headless Service就是没头的Service。有什么使用场景呢？
第一种：自主选择权
有时候client想自己来决定使用哪个Real Server，可以通过查询DNS来获取Real Server的信息。
第二种：Headless Services还有一个用处（PS：也就是我们需要的那个特性）
Headless Service的对应的每一个Endpoints，即每一个Pod，都会有对应的DNS域名；这样Pod之间就可以互相访问。我们还是看上面的这个例子。# kubectl get statefulsets web NAME DESIRED CURRENT AGE web 2 2 1h kubectl get pods web-0 1/1 Running 0 1h web-1 1/1 Running 0 1h # nslookup nginx.default.svc.cluster.local 10.96.0.10 Server: 10.96.0.10 Address: 10.96.0.10#53 Name: nginx.default.svc.cluster.local Address: 10.244.2.17 Name: nginx.default.svc.cluster.local Address: 10.244.2.18 # nslookup web-1.nginx.default.svc.cluster.local 10.96.0.10 Server: 10.96.0.10 Address: 10.96.0.10#53 Name: web-1.nginx.default.svc.cluster.local Address: 10.244.2.18 # nslookup web-0.nginx.default.svc.cluster.local 10.96.0.10 Server: 10.96.0.10 Address: 10.96.0.10#53 Name: web-0.nginx.default.svc.cluster.local Address: 10.244.2.17如上，web为我们创建的StatefulSets，对应的pod的域名为web-0，web-1，他们之间可以互相访问，这样对于一些集群类型的应用就可以解决互相之间身份识别的问题了。
总结
带Headless Services的pod可以通过以下域名进行访问。这个有什么用呢？这可以在k8s中部署数据库集群时使用，比如启动一个3节点的etcd集群，启动时便可以通过以下方式指定3个pod的具体地址。<PodName>.<ServiceName>.<NamespaceName>.svc.cluster.local
Headless Service使用场景
有状态应用，例如数据库
例如主节点可以对数据库进行读写操作，而其它的两个工作节点只能读，在这里客户端就没必要指定pod服务的集群地址，直接指定数据库Pod ip地址即可，这里需要绑定dns，客户端访问dns，dns会自动返回pod IP地址列表
总结
无头服务不需要指定集群地址
无头服务适用有状态应用例如数据库
无头服务dns查询会返回pod列表，开发人员可以自定义负载均衡策略
普通Service可以通过负载均衡路由到不同的容器应用
2）NodePort类型
在之前的样例中，创建的Service的ip地址只有集群内部才可以访问，如果希望将Service暴露给集群外部使用，那么就要使用到另外一种类型的Service，称为NodePort类型。NodePort的工作原理其实就是将service的端口映射到Node的一个端口上，然后就可以通过NodeIp:NodePort来访问service了。
注意service在每个node上都占用了端口，所以访问哪个IP都可以
apiVersion: v1
kind: Service
metadata:
name: service-python
spec:
ports:
- port: 3000
protocol: TCP
targetPort: 443
nodePort: 30080
selector:
run: pod-python
type: NodePort
使用 kuebctl get svc :
此时我们可以通过http://4.4.4.1:30080或http://4.4.4.2:30080 对pod-python访问。该端口有一定的范围，比如默认Kubernetes 控制平面将在–service-node-port-range标志指定的范围内分配端口（默认值：30000-32767）。
每个端口子女使用一次，一个端口对应一个应用
创建service-nodeport.yaml
apiVersion: v1
kind: Service
metadata:
name: service-nodeport
namespace: dev
spec:
selector:
app: nginx-pod
type: NodePort # service类型
ports:
- port: 80
nodePort: 30002 # 指定绑定的node的端口(默认的取值范围是：30000-32767), 如果不指定，会默认分配
targetPort: 80
# 创建service
[root@master ~]# kubectl create -f service-nodeport.yaml
service/service-nodeport created
# 查看service
[root@master ~]# kubectl get svc -n dev -o wide
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) SELECTOR
service-nodeport NodePort 10.105.64.191 <none> 80:30002/TCP app=nginx-pod
# 接下来可以通过电脑主机的浏览器去访问集群中任意一个nodeip的30002端口，即可访问到pod
3）LoadBalancer类型
LoadBalancer和NodePort很相似，目的都是向外部暴露一个端口，区别在于LoadBalancer会在集群的外部再来做一个负载均衡设备，而这个设备需要外部环境支持的，外部服务发送到这个设备上的请求，会被设备负载之后转发到集群中。
LoadBalancer类型的service 是可以实现集群外部访问服务的另外一种解决方案。不过并不是所有的k8s集群都会支持，大多是在公有云托管集群中会支持该类型。负载均衡器是异步创建的，关于被提供的负载均衡器的信息将会通过Service的status.loadBalancer字段被发布出去。
apiVersion: v1
kind: Service
metadata:
name: service-python
spec:
ports:
- port: 3000
protocol: TCP
targetPort: 443
nodePort: 30080
selector:
run: pod-python
type: LoadBalancer
使用 kuebctl get svc :
可以看到external-ip。我们就可以通过该ip来访问了。
当然各家公有云支持诸多的其他设置。大多是公有云负载均衡器的设置参数，都可以通过svc的注解来设置，例如下面的aws：
metadata:
name: my-service
annotations:
service.beta.kubernetes.io/aws-load-balancer-access-log-enabled: "true"
# Specifies whether access logs are enabled for the load balancer
service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval: "60"
# The interval for publishing the access logs. You can specify an interval of either 5 or 60 (minutes).
service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name: "my-bucket"
# The name of the Amazon S3 bucket where the access logs are stored
service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix: "my-bucket-prefix/prod"
# The logical hierarchy you created for your Amazon S3 bucket, for example `my-bucket-prefix/prod`
4）ExternalName类型
ExternalName类型的Service用于引入集群外部的服务，它通过externalName属性指定外部一个服务的地址，然后在集群内部访问此service就可以访问到外部的服务了。
类型为 ExternalName 的service将服务映射到 DNS 名称，而不是典型的选择器，例如my-service或者cassandra。您可以使用spec.externalName参数指定这些服务。
创建 ExternalName 类型的服务的 yaml 如下：
kind: Service
apiVersion: v1
metadata:
name: service-python
spec:
ports:
- port: 3000
protocol: TCP
targetPort: 443
type: ExternalName
externalName: remote.server.url.com
**说明：**您需要 CoreDNS 1.7 或更高版本才能使用
ExternalName类型。
当查找主机 service-python.default.svc.cluster.local时，集群DNS服务返回CNAME记录，其值为my.database.example.com。 访问service-python的方式与其他服务的方式相同，但主要区别在于重定向发生在 DNS 级别，而不是通过代理或转发。
将生产工作负载迁移到Kubernetes集群并不容易。大多数我们不可以停止所有服务并在Kubernetes集群上启动它们。有时，尝试迁移轻量且不会破坏你服务的服务是很好的。在此过程中，一个可能不错的解决方案是使用现有的有状态服务（例如DB），并首先从无状态容器开始。
从Pod中访问外部服务的最简单正确的方法是创建ExternalName service。例如，如果您决定保留AWS RDS，但您还希望能够将MySQL容器用于测试环境。让我们看一下这个例子：
kind: Service
apiVersion: v1
metadata:
name: test-service
namespace: default
spec:
type: ExternalName
externalName: test.database.example.com
你已将Web应用程序配置为使用URL测试服务访问数据库，但是在生产集群上，数据库位于AWS RDS上，并且具有以下URL test.database.example.com。创建ExternalName service 并且你的Web Pod尝试访问test-service上的数据库之后，Kubernetes DNS服务器将返回值为test.database.example.com的CNAME记录。问题解决了。
ExternalName service 也可以用于从其他名称空间访问服务。例如：
kind: Service
apiVersion: v1
metadata:
name: test-service-1
namespace: namespace-a
spec:
type: ExternalName
externalName: test-service-2.namespace-b.svc.cluster.local
ports:
- port: 80
在这里，我可以使用名称空间a中定义的test-service-1访问命名空间b中的服务 test-service-2。
这个意义在哪里？
ExternalName service 也是一种service，那么ingress controller 会支持，那么就可以实现跨namespace的ingress。
原文链接：https://segmentfault.com/a/1190000023125587
apiVersion: v1
kind: Service
metadata:
name: service-externalname
namespace: dev
spec:
type: ExternalName # service类型
externalName: www.baidu.com #改成ip地址也可以
# 创建service
[root@master ~]# kubectl create -f service-externalname.yaml
service/service-externalname created
# 域名解析
[root@master ~]# dig @10.96.0.10 service-externalname.dev.svc.cluster.local
service-externalname.dev.svc.cluster.local. 30 IN CNAME www.baidu.com.
www.baidu.com. 30 IN CNAME www.a.shifen.com.
www.a.shifen.com. 30 IN A 39.156.66.18
www.a.shifen.com. 30 IN A 39.156.66.14
示例
我们可以导出一个文件 包含service的配置信息
kubectl expose deployment web --port=80 --target-port=80 --dry-run -o yaml > service.yaml
service.yaml 如下所示
apiVersion: v1
kind: Service #
metadata:
creationTimestamp: null
labels:
app: web
name: web
spec:
ports:
- port: 80 #
protocol: TCP
targetPort: 80 #
selector:
app: web
# type: ClusterIp # 默认值 只能在集群内部使用
# type: NodePort # 指定service的类型
# type: LoadBalanced 对外访问应用使用公有云
status:
loadBalancer: {}
修改完命令后，我们使用创建一个pod
kubectl apply -f service.yaml
node一般是在内网进行部署，而外网一般是不能访问到的，那么如何访问的呢？
- 找到一台可以通过外网访问机器，安装nginx，反向代理
- 手动把可以访问的节点添加到nginx中
如果我们使用LoadBalancer，就会有负载均衡的控制器，类似于nginx的功能，就不需要自己添加到nginx上
Ingress篇章
六、Ingress介绍
Service只支持4层负载均衡，而Ingress有7层功能
Nginx可以通过虚拟主机域名区分不同的服务，而每个服务通过 upstream进行定义不同的负载均衡池，再加上 location进行负载均衡的反向代理，在日常使用中只需要修改 nginx.conf即可实现，但是在 K8S中又该如何实现这种方式调度呢
在前面课程中已经提到，Service对集群之外暴露服务的主要方式有两种：NotePort和LoadBalancer，但是这两种方式，都有一定的缺点：
- NodePort方式的缺点是会占用很多集群机器的端口，那么当集群服务变多的时候，这个缺点就愈发明显
- LoadBalancer方式的缺点是每个service需要一个LB，浪费、麻烦，并且需要kubernetes之外设备的支持
基于这种现状，kubernetes提供了Ingress资源对象，Ingress只需要一个NodePort或者一个LB就可以满足暴露多个Service的需求。工作机制大致如下图表示：
- 首先service就是关联我们的pod
- 然后ingress作为入口，首先需要到service，然后发现一组pod
- 发现pod后，就可以做负载均衡等操作
实际上，Ingress相当于一个7层的负载均衡器，是kubernetes对反向代理的一个抽象，它的工作原理类似于Nginx，可以理解成在Ingress里建立诸多映射规则，Ingress Controller通过监听这些配置规则并转化成Nginx的反向代理配置 , 然后对外部提供服务。
K8S引入了 ingress自动进行服务的调度， ingress包含两大组件： ingress controller和 ingress。
- ingress：kubernetes中的一个对象，作用是定义请求如何转发到service的规则
- 修改 Nginx配置操作被抽象成了 ingress对象。
- ingress controller：具体实现反向代理及负载均衡的程序，对ingress定义的规则进行解析，根据配置的规则来实现请求转发，实现方式有很多，比如Nginx, Contour, Haproxy等等
- ingress controller通过与 kubernetes API交互，动态的去感知进集群中 Ingress规则变化，然后读取它，然后读取它，按照它自己的模板生成一段 nginx配置，再写到 nginx Pod中，最后 reload以下，工作流程如下图：
- [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lgfpYpz2-1636721333058)(https://pics0.baidu.com/feed/810a19d8bc3eb135c30c0d1810b7d1d4ff1f44ff.jpeg?token=0335fe82d9a01dddec5ab7d0dd7649e1)]
Ingress（以Nginx为例）的工作原理如下：
- 用户编写Ingress规则，说明哪个域名对应kubernetes集群中的哪个Service
- Ingress控制器动态感知Ingress服务规则的变化，然后生成一段对应的Nginx反向代理配置
- Ingress控制器会将生成的Nginx配置写入到一个运行着的Nginx服务中，并动态更新
- 到此为止，其实真正在工作的就是一个Nginx了，内部配置了用户定义的请求转发规则
在实际的访问中，我们都是需要维护很多域名， a.com 和 b.com
然后不同的域名对应的不同的Service，然后service管理不同的pod
七、Ingress使用
环境准备
需要注意，ingress不是内置的组件，需要我们单独的安装
搭建ingress环境
# 创建文件夹
[root@master ~]# mkdir ingress-controller
[root@master ~]# cd ingress-controller/
#
# 获取ingress-nginx，本次案例使用的是0.30版本
[root@master ingress-controller]# wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/mandatory.yaml
[root@master ingress-controller]# wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/provider/baremetal/service-nodeport.yaml
# 修改mandatory.yaml文件中的仓库
# 修改quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.30.0
# 为quay-mirror.qiniu.com/kubernetes-ingress-controller/nginx-ingress-controller:0.30.0
# 创建ingress-nginx
[root@master ingress-controller]# kubectl apply -f ./
# 查看ingress-nginx
[root@master ingress-controller]# kubectl get pod -n ingress-nginx
NAME READY STATUS RESTARTS AGE
pod/nginx-ingress-controller-fbf967dd5-4qpbp 1/1 Running 0 12h
# 查看service
[root@master ingress-controller]# kubectl get svc -n ingress-nginx
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
ingress-nginx NodePort 10.98.75.163 <none> 80:32240/TCP,443:31335/TCP 11h
准备service和pod
为了后面的实验比较方便，创建如下图所示的模型
创建tomcat-nginx.yaml、俩个Deployment&&俩个service
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
namespace: dev
spec:
replicas: 3
selector:
matchLabels:
app: nginx-pod
template:
metadata:
labels:
app: nginx-pod
spec:
containers:
- name: nginx
image: nginx:1.17.1
ports:
- containerPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: tomcat-deployment
namespace: dev
spec:
replicas: 3
selector:
matchLabels:
app: tomcat-pod
template:
metadata:
labels:
app: tomcat-pod
spec:
containers:
- name: tomcat
image: tomcat:8.5-jre10-slim
ports:
- containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: nginx-service
namespace: dev
spec:
selector:
app: nginx-pod
clusterIP: None
type: ClusterIP
ports:
- port: 80
targetPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: tomcat-service
namespace: dev
spec:
selector:
app: tomcat-pod
clusterIP: None
type: ClusterIP
ports:
- port: 8080
targetPort: 8080
# 创建
[root@master ~]# kubectl create -f tomcat-nginx.yaml
# 查看
[root@master ~]# kubectl get svc -n dev
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx-service ClusterIP None <none> 80/TCP 48s
tomcat-service ClusterIP None <none> 8080/TCP 48s
Http代理
创建ingress-http.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: ingress-http
namespace: dev
spec:
rules:
- host: nginx.itheima.com
http:
paths:
- path: /
backend:
serviceName: nginx-service
servicePort: 80 # service的端口
- host: tomcat.itheima.com
http:
paths:
- path: /
backend:
serviceName: tomcat-service
servicePort: 8080
# 创建
[root@master ~]# kubectl create -f ingress-http.yaml
ingress.extensions/ingress-http created
# 查看
[root@master ~]# kubectl get ing ingress-http -n dev
NAME HOSTS ADDRESS PORTS AGE
ingress-http nginx.itheima.com,tomcat.itheima.com 80 22s
# 查看详情
[root@master ~]# kubectl describe ing ingress-http -n dev
...
Rules:
Host Path Backends
---- ---- --------
nginx.itheima.com / nginx-service:80 (10.244.1.96:80,10.244.1.97:80,10.244.2.112:80)
tomcat.itheima.com / tomcat-service:8080(10.244.1.94:8080,10.244.1.95:8080,10.244.2.111:8080)
...
# 接下来,在本地电脑上配置host文件,解析上面的两个域名到192.168.109.100(master)上
# 然后,就可以分别访问tomcat.itheima.com:32240 和 nginx.itheima.com:32240 查看效果了
访问的是ingress的端口
Https代理
创建证书
# 生成证书
openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/C=CN/ST=BJ/L=BJ/O=nginx/CN=itheima.com"
# 创建密钥
kubectl create secret tls tls-secret --key tls.key --cert tls.crt
创建ingress-https.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: ingress-https
namespace: dev
spec:
tls:
- hosts:
- nginx.itheima.com
- tomcat.itheima.com
secretName: tls-secret # 指定秘钥
rules:
- host: nginx.itheima.com
http:
paths:
- path: /
backend:
serviceName: nginx-service
servicePort: 80
- host: tomcat.itheima.com
http:
paths:
- path: /
backend:
serviceName: tomcat-service
servicePort: 8080
# 创建
[root@master ~]# kubectl create -f ingress-https.yaml
ingress.extensions/ingress-https created
# 查看
[root@master ~]# kubectl get ing ingress-https -n dev
NAME HOSTS ADDRESS PORTS AGE
ingress-https nginx.itheima.com,tomcat.itheima.com 10.104.184.38 80, 443 2m42s
# 查看详情
[root@master ~]# kubectl describe ing ingress-https -n dev
...
TLS:
tls-secret terminates nginx.itheima.com,tomcat.itheima.com
Rules:
Host Path Backends
---- ---- --------
nginx.itheima.com / nginx-service:80 (10.244.1.97:80,10.244.1.98:80,10.244.2.119:80)
tomcat.itheima.com / tomcat-service:8080(10.244.1.99:8080,10.244.2.117:8080,10.244.2.120:8080)
...
# 下面可以通过浏览器访问https://nginx.itheima.com:31335 和 https://tomcat.itheima.com:31335来查看了
1320
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
