k8s ingress
k8s ingress
官网地址: 跳转
原本k8s的service只能实现4层代理，因为ingress的加入，k8s实现了7层代理
ingress是什么
我们常见的ingress-nginx-controller 安装，是两个组件组成，一个是nginx，一个是control，他的作用就是把我们写的ingress的yaml转发规则，转换成nginx配置。里面运行了一个nginx， /etc/nginx/nginx.conf 里面就是转换后的nginx配置。
服务通过域名解析，请求打到服务端，ingress就会解析，然后转发给后端的service》pod去处理
Ingress 公开从集群外部到集群内服务的 HTTP 和 HTTPS 路由。 流量路由由 Ingress 资源上定义的规则控制。下面是一个将所有流量都发送到同一 Service 的简单 Ingress 示例
ngress 是对集群中服务的外部访问进行管理的 API 对象，典型的访问方式是 HTTP。
Ingress 可以提供负载均衡、SSL 终结和基于名称的虚拟托管
Ingress 可为 Service 提供外部可访问的 URL、负载均衡流量、终止 SSL/TLS，以及基于名称的虚拟托管。 Ingress 控制器 通常负责通过负载均衡器来实现 Ingress，尽管它也可以配置边缘路由器或其他前端来帮助处理流量。
Ingress 不会公开任意端口或协议。 将 HTTP 和 HTTPS 以外的服务公开到 Internet 时，通常使用 Service.Type=NodePort 或 Service.Type=LoadBalancer 类型的 Service。
ingress-nginx下载
ingress-nginx是在国外，国内是下载不了的，我这里下载好备份到网盘上了,这个版本的ingress配套k8s 1.15版本，其他版本需要去官网下载
链接：https://pan.baidu.com/s/1mT45TRpDiSuX4STNW1ULxQ
提取码：68f5
也可以参考官网部署，有很多种安装方法 https://kubernetes.github.io/ingress-nginx/deploy/
tar zxvf ingress-nginx.tar.gz
//将ingress通过k8s控制器部署在k8s集群内部称为Pod
mandatory.yaml
//将ingress通过nodeport的方式暴露端口对外提供服务
service-nodeport.yaml
docker load -i ingress-nginx/ingress.tar
解压后scp把ingress镜像拷贝到其他机器并导入镜像
部署ingress
kubectl create -f mandatory.yaml
//检查ingress是否部署成功
kubectl get pod -A
//部署完后，外部还无法访问，需要对外暴露端口
kubectl create -f service-nodeport.yaml
//查看ingress的svc
kubectl get svc -A
我们访问ingress对外暴露的随机端口会报404，因为没服务，这是正常的
部署完后我们就可以使用ingress了
Ingress 资源
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: minimal-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
ingressClassName: nginx-example
rules:
- http:
paths:
- path: /testpath
pathType: Prefix
backend:
service:
name: test
port:
number: 80
-
Ingress 需要指定 apiVersion、kind、 metadata和 spec 字段。 Ingress 对象的命名必须是合法的 DNS 子域名名称。dns合法域名规范： https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names
-
关于如何使用配置文件，请参见部署应用、 配置容器、 管理资源。 Ingress 经常使用注解（annotations）来配置一些选项，具体取决于 Ingress 控制器，例如重写目标注解。 不同的 Ingress 控制器支持不同的注解。 查看你所选的 Ingress 控制器的文档，以了解其支持哪些注解
-
Ingress 规约 提供了配置负载均衡器或者代理服务器所需的所有信息。 最重要的是，其中包含与所有传入请求匹配的规则列表。 Ingress 资源仅支持用于转发 HTTP(S) 流量的规则
-
如果 ingressClassName 被省略，那么你应该定义一个默认 Ingress 类。
-
有一些 Ingress 控制器不需要定义默认的 IngressClass。比如：Ingress-NGINX 控制器可以通过参数 --watch-ingress-without-class 来配置。 不过仍然推荐 按下文所示来设置默认的 IngressClass。
Ingress 规则
每个 HTTP 规则都包含以下信息：
- 可选的 host。在此示例中，未指定 host，因此该规则适用于通过指定 IP 地址的所有入站 HTTP 通信。 如果提供了 host（例如 foo.bar.com），则 rules 适用于该 host。
- 路径列表 paths（例如，/testpath）,每个路径都有一个由 serviceName 和 servicePort 定义的关联后端。 在负载均衡器将流量定向到引用的服务之前，主机和路径都必须匹配传入请求的内容。
- backend（后端）是 Service 文档中所述的服务和端口名称的组合。 与规则的 host 和 path 匹配的对 Ingress 的 HTTP（和 HTTPS ）请求将发送到列出的 backend。
通常在 Ingress 控制器中会配置 defaultBackend（默认后端），以服务于无法与规约中 path 匹配的所有请求
默认后端
没有设置规则的 Ingress 将所有流量发送到同一个默认后端，而 .spec.defaultBackend 则是在这种情况下处理请求的那个默认后端。 defaultBackend 通常是 Ingress 控制器的配置选项，而非在 Ingress 资源中指定。 如果未设置任何的 .spec.rules，那么必须指定 .spec.defaultBackend。 如果未设置 defaultBackend，那么如何处理所有与规则不匹配的流量将交由 Ingress 控制器决定（请参考你的 Ingress 控制器的文档以了解它是如何处理那些流量的）。
如果没有 hosts 或 paths 与 Ingress 对象中的 HTTP 请求匹配，则流量将被路由到默认后端
资源后端
Resource 后端是一个引用，指向同一命名空间中的另一个 Kubernetes 资源，将其作为 Ingress 对象。 Resource 后端与 Service 后端是互斥的，在二者均被设置时会无法通过合法性检查。 Resource 后端的一种常见用法是将所有入站数据导向带有静态资产的对象存储后端
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress-resource-backend
spec:
defaultBackend:
resource:
apiGroup: k8s.example.com
kind: StorageBucket
name: static-assets
rules:
- http:
paths:
- path: /icons
pathType: ImplementationSpecific
backend:
resource:
apiGroup: k8s.example.com
kind: StorageBucket
name: icon-assets
创建了如上的 Ingress 之后，你可以使用下面的命令查看它
kubectl describe ingress ingress-resource-backend
Name: ingress-resource-backend
Namespace: default
Address:
Default backend: APIGroup: k8s.example.com, Kind: StorageBucket, Name: static-assets
Rules:
Host Path Backends
---- ---- --------
*
/icons APIGroup: k8s.example.com, Kind: StorageBucket, Name: icon-assets
Annotations: <none>
Events: <none>
路径类型
Ingress 中的每个路径都需要有对应的路径类型（Path Type）。未明确设置 pathType 的路径无法通过合法性检查。当前支持的路径类型有三种：
-
ImplementationSpecific：对于这种路径类型，匹配方法取决于 IngressClass。 具体实现可以将其作为单独的 pathType 处理或者与 Prefix 或 Exact 类型作相同处理。
-
Exact：精确匹配 URL 路径，且区分大小写。
-
Prefix：基于以 / 分隔的 URL 路径前缀匹配。匹配区分大小写，并且对路径中的元素逐个完成。 路径元素指的是由 / 分隔符分隔的路径中的标签列表。 如果每个 p 都是请求路径 p 的元素前缀，则请求与路径 p 匹配。
说明： 如果路径的最后一个元素是请求路径中最后一个元素的子字符串，则不会匹配 （例如：/foo/bar 匹配 /foo/bar/baz, 但不匹配 /foo/barbaz）。
类型 路径 请求路径 匹配与否？
Prefix / （所有路径） 是
Exact /foo /foo 是
Exact /foo /bar 否
Exact /foo /foo/ 否
Exact /foo/ /foo 否
Prefix /foo /foo, /foo/ 是
Prefix /foo/ /foo, /foo/ 是
Prefix /aaa/bb /aaa/bbb 否
Prefix /aaa/bbb /aaa/bbb 是
Prefix /aaa/bbb/ /aaa/bbb 是，忽略尾部斜线
Prefix /aaa/bbb /aaa/bbb/ 是，匹配尾部斜线
Prefix /aaa/bbb /aaa/bbb/ccc 是，匹配子路径
Prefix /aaa/bbb /aaa/bbbxyz 否，字符串前缀不匹配
Prefix /, /aaa /aaa/ccc 是，匹配 /aaa 前缀
Prefix /, /aaa, /aaa/bbb /aaa/bbb 是，匹配 /aaa/bbb 前缀
Prefix /, /aaa, /aaa/bbb /ccc 是，匹配 / 前缀
Prefix /aaa /ccc 否，使用默认后端
混合 /foo (Prefix), /foo (Exact) /foo 是，优选 Exact 类型
多重匹配
在某些情况下，Ingress 中的多条路径会匹配同一个请求。 这种情况下最长的匹配路径优先。 如果仍然有两条同等的匹配路径，则精确路径类型优先于前缀路径类型
主机名通配符
主机名可以是精确匹配（例如“foo.bar.com”）或者使用通配符来匹配 （例如“*.foo.com”）。 精确匹配要求 HTTP host 头部字段与 host 字段值完全匹配。 通配符匹配则要求 HTTP host 头部字段与通配符规则中的后缀部分相同。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress-wildcard-host
spec:
rules:
- host: "foo.bar.com"
http:
paths:
- pathType: Prefix
path: "/bar"
backend:
service:
name: service1
port:
number: 80
- host: "*.foo.com"
http:
paths:
- pathType: Prefix
path: "/foo"
backend:
service:
name: service2
port:
number: 80
Ingress 类
Ingress 可以由不同的控制器实现，通常使用不同的配置。 每个 Ingress 应当指定一个类，也就是一个对 IngressClass 资源的引用。 IngressClass 资源包含额外的配置，其中包括应当实现该类的控制器名称。
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: external-lb
spec:
controller: example.com/ingress-controller
parameters:
apiGroup: k8s.example.com
kind: IngressParameters
name: external-lb
IngressClass 中的 .spec.parameters 字段可用于引用其他资源以提供额外的相关配置。
参数（parameters）的具体类型取决于你在 .spec.controller 字段中指定的 Ingress 控制器。
IngressClass 的作用域
ngressClass 的参数默认是集群范围的。
集群作用域
如果你设置了 .spec.parameters 字段且未设置 .spec.parameters.scope 字段，或是将 .spec.parameters.scope 字段设为了 Cluster，那么该 IngressClass 所指代的即是一个集群作用域的资源。 参数的 kind（和 apiGroup 一起）指向一个集群作用域的 API（可能是一个定制资源（Custom Resource）），而它的 name 则为此 API 确定了一个具体的集群作用域的资源。
示例：
---
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: external-lb-1
spec:
controller: example.com/ingress-controller
parameters:
# 此 IngressClass 的配置定义在一个名为 “external-config-1” 的
# ClusterIngressParameter（API 组为 k8s.example.net）资源中。
# 这项定义告诉 Kubernetes 去寻找一个集群作用域的参数资源。
scope: Cluster
apiGroup: k8s.example.net
kind: ClusterIngressParameter
name: external-config-1
命名空间作用域
特性状态： Kubernetes v1.23 [stable]
如果你设置了 .spec.parameters 字段且将 .spec.parameters.scope 字段设为了 Namespace，那么该 IngressClass 将会引用一个命名空间作用域的资源。 .spec.parameters.namespace 必须和此资源所处的命名空间相同。
参数的 kind（和 apiGroup 一起）指向一个命名空间作用域的 API（例如：ConfigMap），而它的 name 则确定了一个位于你指定的命名空间中的具体的资源。
命名空间作用域的参数帮助集群操作者将控制细分到用于工作负载的各种配置中（比如：负载均衡设置、API 网关定义）。如果你使用集群作用域的参数，那么你必须从以下两项中选择一项执行：
- 每次修改配置，集群操作团队需要批准其他团队的修改。
- 集群操作团队定义具体的准入控制，比如 RBAC 角色与角色绑定，以使得应用程序团队可以修改集群作用域的配置参数资源。
IngressClass API 本身是集群作用域的。
这里是一个引用命名空间作用域的配置参数的 IngressClass 的示例：
---
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: external-lb-2
spec:
controller: example.com/ingress-controller
parameters:
# 此 IngressClass 的配置定义在一个名为 “external-config” 的
# IngressParameter（API 组为 k8s.example.com）资源中，
# 该资源位于 “external-configuration” 命名空间中。
scope: Namespace
apiGroup: k8s.example.com
kind: IngressParameter
namespace: external-configuration
name: external-config
默认 Ingress 类
你可以将一个特定的 IngressClass 标记为集群默认 Ingress 类。 将一个 IngressClass 资源的 ingressclass.kubernetes.io/is-default-class 注解设置为 true 将确保新的未指定 ingressClassName 字段的 Ingress 能够分配为这个默认的 IngressClass
注意： 如果集群中有多个 IngressClass 被标记为默认，准入控制器将阻止创建新的未指定 ingressClassName 的 Ingress 对象。 解决这个问题只需确保集群中最多只能有一个 IngressClass 被标记为默认
有一些 Ingress 控制器不需要定义默认的 IngressClass。比如：Ingress-NGINX 控制器可以通过参数 --watch-ingress-without-class 来配置。 不过仍然推荐 设置默认的 IngressClass。
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
labels:
app.kubernetes.io/component: controller
name: nginx-example
annotations:
ingressclass.kubernetes.io/is-default-class: "true"
spec:
controller: k8s.io/ingress-nginx
Ingress 类型
由单个 Service 来完成的 Ingress
现有的 Kubernetes 概念允许你暴露单个 Service (参见替代方案)。 你也可以通过指定无规则的 默认后端 来对 Ingress 进行此操作。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: test-ingress
spec:
defaultBackend:
service:
name: test
port:
number: 80
如果使用 kubectl apply -f 创建此 Ingress，则应该能够查看刚刚添加的 Ingress 的状态
kubectl get ingress test-ingress
NAME CLASS HOSTS ADDRESS PORTS AGE
test-ingress external-lb * 203.0.113.123 80 59s
//其中 203.0.113.123 是由 Ingress 控制器分配以满足该 Ingress 的 IP。
说明： 入口控制器和负载平衡器可能需要一两分钟才能分配 IP 地址。 在此之前，你通常会看到地址字段的值被设定为
简单扇出
一个扇出（fanout）配置根据请求的 HTTP URI 将来自同一 IP 地址的流量路由到多个 Service。 Ingress 允许你将负载均衡器的数量降至最低。例如，这样的设置：
将需要一个如下所示的 Ingress：
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: simple-fanout-example
spec:
rules:
- host: foo.bar.com
http:
paths:
- path: /foo
pathType: Prefix
backend:
service:
name: service1
port:
number: 4200
- path: /bar
pathType: Prefix
backend:
service:
name: service2
port:
number: 8080
kubectl describe ingress simple-fanout-example
Name: simple-fanout-example
Namespace: default
Address: 178.91.123.132
Default backend: default-http-backend:80 (10.8.2.3:8080)
Rules:
Host Path Backends
---- ---- --------
foo.bar.com
/foo service1:4200 (10.8.0.90:4200)
/bar service2:8080 (10.8.0.91:8080)
Annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ADD 22s loadbalancer-controller default/test
Ingress 控制器将提供实现特定的负载均衡器来满足 Ingress， 只要 Service (service1，service2) 存在。 当它这样做时，你会在 Address 字段看到负载均衡器的地址。
说明： 取决于你所使用的 Ingress 控制器， 你可能需要创建默认 HTTP 后端服务。
基于名称的虚拟托管
基于名称的虚拟主机支持将针对多个主机名的 HTTP 流量路由到同一 IP 地址上
以下 Ingress 让后台负载均衡器基于host 头部字段 来路由请求
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: name-virtual-host-ingress
spec:
rules:
- host: foo.bar.com
http:
paths:
- pathType: Prefix
path: "/"
backend:
service:
name: service1
port:
number: 80
- host: bar.foo.com
http:
paths:
- pathType: Prefix
path: "/"
backend:
service:
name: service2
port:
number: 80
如果你创建的 Ingress 资源没有在 rules 中定义的任何 hosts，则可以匹配指向 Ingress 控制器 IP 地址的任何网络流量，而无需基于名称的虚拟主机。
例如，以下 Ingress 会将请求 first.bar.com 的流量路由到 service1，将请求 second.bar.com 的流量路由到 service2，而所有其他流量都会被路由到 service3。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: name-virtual-host-ingress-no-third-host
spec:
rules:
- host: first.bar.com
http:
paths:
- pathType: Prefix
path: "/"
backend:
service:
name: service1
port:
number: 80
- host: second.bar.com
http:
paths:
- pathType: Prefix
path: "/"
backend:
service:
name: service2
port:
number: 80
- http:
paths:
- pathType: Prefix
path: "/"
backend:
service:
name: service3
port:
number: 80
TLS
你可以通过设定包含 TLS 私钥和证书的Secret 来保护 Ingress。 Ingress 只支持单个 TLS 端口 443，并假定 TLS 连接终止于 Ingress 节点（与 Service 及其 Pod 之间的流量都以明文传输）。 如果 Ingress 中的 TLS 配置部分指定了不同的主机，那么它们将根据通过 SNI TLS 扩展指定的主机名（如果 Ingress 控制器支持 SNI）在同一端口上进行复用。 TLS Secret 的数据中必须包含用于 TLS 的以键名 tls.crt 保存的证书和以键名 tls.key 保存的私钥。 例如：
apiVersion: v1
kind: Secret
metadata:
name: testsecret-tls
namespace: default
data:
tls.crt: base64 编码的证书
tls.key: base64 编码的私钥
type: kubernetes.io/tls
在 Ingress 中引用此 Secret 将会告诉 Ingress 控制器使用 TLS 加密从客户端到负载均衡器的通道。 你需要确保创建的 TLS Secret 创建自包含 https-example.foo.com 的公用名称（CN）的证书。 这里的公共名称也被称为全限定域名（FQDN）。
说明：
注意，默认规则上无法使用 TLS，因为需要为所有可能的子域名发放证书。 因此，tls 字段中的 hosts 的取值需要与 rules 字段中的 host 完全匹配。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: tls-example-ingress
spec:
tls:
- hosts:
- https-example.foo.com
secretName: testsecret-tls
rules:
- host: https-example.foo.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: service1
port:
number: 80
各种 Ingress 控制器所支持的 TLS 功能之间存在差异。请参阅有关 nginx、 GCE 或者任何其他平台特定的 Ingress 控制器的文档，以了解 TLS 如何在你的环境中工作。
负载均衡
Ingress 控制器启动引导时使用一些适用于所有 Ingress 的负载均衡策略设置，例如负载均衡算法、后端权重方案等。 更高级的负载均衡概念（例如持久会话、动态权重）尚未通过 Ingress 公开。 你可以通过用于服务的负载均衡器来获取这些功能。
值得注意的是，尽管健康检查不是通过 Ingress 直接暴露的，在 Kubernetes 中存在并行的概念，比如 就绪检查， 允许你实现相同的目的。 请检查特定控制器的说明文档（nginx、 GCE）以了解它们是怎样处理健康检查的。
更新 Ingress
要更新现有的 Ingress 以添加新的 Host，可以通过编辑资源来对其进行更新
kubectl describe ingress test
Name: test
Namespace: default
Address: 178.91.123.132
Default backend: default-http-backend:80 (10.8.2.3:8080)
Rules:
Host Path Backends
---- ---- --------
foo.bar.com
/foo service1:80 (10.8.0.90:80)
Annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ADD 35s loadbalancer-controller default/test
kubectl edit ingress test
跨可用区失败
不同的云厂商使用不同的技术来实现跨故障域的流量分布。详情请查阅相关 Ingress 控制器的文档。 请查看相关 Ingress 控制器的文档以了解详细信息
替代方案
不直接使用 Ingress 资源，也有多种方法暴露 Service：
使用 Service.Type=LoadBalancer
使用 Service.Type=NodePort
deployment、Service、Ingress Yaml 文件
使用yml部署环境 kubectl create -f xxx.yml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nginx-dm
spec:
replicas: 2
template:
metadata:
labels:
name: nginx
spec:
containers:
- name: nginx
image: wangyanglinux/myapp:v1
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: nginx-svc
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
selector:
name: nginx
---
apiVersion: extensions/v1beta1
kind: Ingress //ingress是依赖svc的，因为后端是个动态的结果集
metadata:
name: nginx-test
spec:
rules:
- host: www1.hongfu.com //访问域名。七层代理
http:
paths:
- path: /
backend:
serviceName: nginx-svc
servicePort: 80
创建完后，我们在访问 www1.hongfu.com 就会访问到我们部署的这服务里面了，前提是需要修改下本地的hosts文件，否则他会根据公网的dns解析到别的地方。www1.hongfu.com 这个域名当然不会指定我们本地，所以要在hosts本地写死，强制访问本地
修改 C:\Windows\System32\drivers\etc\hosts
//添加保存
//192.168.50.121是我们刚才部署的ingress， kubectl get svc -n ingress-nginx 的那台机器
192.168.50.121 www1.hongfu.com
然后在浏览器页面访问 http://www1.hongfu.com/ 这个非加密端口
或者 http://www1.hongfu.com:31771 这个加密端口
可以再 kubectl create -f *yml 绑定另外一个域名
就可以通过访问 http://www1.alexaaa.com/ 另外一个域名
Ingress HTTPS 代理访问
创建证书，以及 cert 存储方式
//自己玩的证书可以自己做，但是外网访问一定要买的
openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=nginxsvc/O=nginxsvc"
kubectl create secret tls tls-secret --key tls.key --cert tls.crt
tls 类型
tls-secret 证书类型
tls.key 公钥
tls.crt 私钥
deployment、Service、Ingress Yaml 文件
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: nginx-test
spec:
tls:
- hosts:
- foo.bar.com //域名
secretName: tls-secret
rules:
- host: foo.bar.com
http:
paths:
- path: /
backend:
serviceName: nginx-svc
servicePort: 80
Nginx 进行 BasicAuth
nginx 认证
annotations： 同label类似，label是官方认定的标签，而annotations相当于是我们私下协商的标签，比如我跟你说，如果你今天开心就穿个红色衣服，在我们之间，这个生效，除了我们，这个就没有意义了，加上annotations，放在别的位置，它没有任何影响，而与特定的ingress里，key和value就会有特殊意义，这些意义分别代表什么意思可以在官方博客，github上看到
yum -y install httpd
htpasswd -c auth foo
kubectl create secret generic basic-auth --from-file=auth
kubectl get basic-auth
[root@master1 ingress]# cat auth
foo:$apr1$hQs.yjlS$ChEREG72vgpFXjVP4qiDU0 //base64加密的
nginx-ingress.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: ingress-with-auth
annotations:
//这是我们和nginx之间的私有约定，只有我和nginx之间有作用
nginx.ingress.kubernetes.io/auth-type: basic //基础认证类型
nginx.ingress.kubernetes.io/auth-secret: basic-auth //认证对象
nginx.ingress.kubernetes.io/auth-realm: 'Authentication Required - foo' //欢迎信息
spec:
rules:
- host: foo2.bar.com
http:
paths:
- path: /
backend:
serviceName: nginx-svc
servicePort: 80
kubectl apply -f nginx-ingress.yaml
kubectl get svc
//ingress-nginx的端口是固定的，443和80暴露一个随机端口，访问 foo2.bar.com:随机端口可以看到
Nginx 进行重写
| 名称 | 描述 | 值 |
|---|---|---|
| nginx.ingress.kubernetes.io/rewrite-target | 必须重定向流量的目标URI串 | 串 |
| nginx.ingress.kubernetes.io/ssl-redirect | 指示位置部分是否仅可访问SSL（当Ingress包含证书时默认为True） | 布尔 |
| nginx.ingress.kubernetes.io/force-ssl-redirect | 即使Ingress未启用TLS，也强制重定向到HTTPS | 布尔 |
| nginx.ingress.kubernetes.io/app-root | 定义Controller必须重定向的应用程序根，如果它在'/'上下文中 | 串 |
| nginx.ingress.kubernetes.io/use-regex | 指示Ingress上定义的路径是否使用正则表达式 | 布尔 |
//把https://foo10.bar.com:随机端口 访问重写到 http://foo.bar.com:31795/hostname.html
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: nginx-test
annotations:
nginx.ingress.kubernetes.io/rewrite-target: http://foo.bar.com:31795/hostname.html
spec:
rules:
- host: foo10.bar.com
http:
paths:
- path: /
backend:
serviceName: nginx-svc
servicePort: 80
生产案例
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
kubernetes.io/ingress.class: "nginx"
nginx.ingress.kubernetes.io/use-regex: "true"
nginx.ingress.kubernetes.io/rewrite-target: /
nginx.ingress.kubernetes.io/proxy-body-size: "100M"
name: ${ENVIRONMENT_NAME}-ingress
namespace: ${ENVIRONMENT_NAME}
spec:
rules:
- host: ${ENVIRONMENT_NAME}.192.168.48.85.nip.io
http:
paths:
- backend:
serviceName: nginx
servicePort: 8080
//部署后生成
apiVersion: v1
items:
- apiVersion: extensions/v1beta1
kind: Ingress
metadata:
gx22091601-ingress","hostname":"zhougx22091601.192.168.48.85.nip.io","allNodes":true}]' kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/proxy-body-size: 100M
nginx.ingress.kubernetes.io/rewrite-target: /
nginx.ingress.kubernetes.io/use-regex: "true"
creationTimestamp: "2022-09-16T07:19:00Z"
generation: 1
name: zhougx22091601-ingress
namespace: zhougx22091601
resourceVersion: "281855666"
spec:
rules:
- host: zhougx22091601.192.168.48.85.nip.io
http:
paths:
- backend:
serviceName: nginx
servicePort: 8080
status:
loadBalancer:
ingress:
- ip: 192.168.48.85
- ip: 192.168.58.127
- ip: 192.168.58.128
- ip: 192.168.58.67
- ip: 192.168.58.94
- ip: 192.168.59.14
- ip: 192.168.59.16
- ip: 192.168.59.17
- ip: 192.168.59.19
- ip: 192.168.59.44
- ip: 192.168.60.119
- ip: 192.168.60.12
- ip: 192.168.60.124
- ip: 192.168.60.136
- ip: 192.168.60.153
- ip: 192.168.60.167
- ip: 192.168.60.168
- ip: 192.168.60.178
- ip: 192.168.60.198
- ip: 192.168.60.199
- ip: 192.168.60.25
- ip: 192.168.60.30
- ip: 192.168.60.38
- ip: 192.168.61.112
- ip: 192.168.61.123
- ip: 192.168.61.141
- ip: 192.168.61.172
- ip: 192.168.61.175
- ip: 192.168.61.184
- ip: 192.168.61.213
- ip: 192.168.61.214
- ip: 192.168.61.32
- ip: 192.168.61.58
- ip: 192.168.61.74
- ip: 192.168.61.75
- ip: 192.168.61.98
kind: List
metadata:
resourceVersion: ""
nginx针对ingress做了优化
- 你必须拥有一个 Ingress 控制器 才能满足 Ingress 的要求。 仅创建 Ingress 资源本身没有任何效果。
- 你可能需要部署 Ingress 控制器，例如 ingress-nginx。 你可以从许多 Ingress 控制器 中进行选择。
- 理想情况下，所有 Ingress 控制器都应符合参考规范。但实际上，不同的 Ingress 控制器操作略有不同。
ingress控制器列表： https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress-controllers/
ingress-nginx： https://kubernetes.github.io/ingress-nginx/deploy/
Ingress-Nginx github 地址：https://github.com/kubernetes/ingress-nginx
如上图所示，nginx针对ingress也做了优化
- nignxcontroller是主进程，会开辟两个协程store和syncqueue
- store会监听api-server对ingress的改动，同时分位急和缓两种事件，比较急的会直接发送给syncqueue处理，比如Pod死了这类不着急的事件会放到updateChannel里面，然后发送到主进程，主程序会定期的读取并把这些事件发送给syncqueue，让重新加载变的不那么频繁，除非特别紧急的事情再重新加载
