k8s七层代理Ingress-nginx-controller
一、Ingress与Ingress Controller概述
1.1 回顾service四层代理
在 k8s 中为什么要做负载均衡?
Pod 漂移问题,可以理解成 Pod IP 是变化的
Kubernetes 具有强大的副本控制能力,能保证在任意副本(Pod)挂掉时自动从其他机器启动一个新的,还可以动态扩容等。通俗地说,这个 Pod 可能在任何时刻出现在任何节点上,也可能在任何时刻死在任何节点上;那么自然随着 Pod 的创建和销毁,Pod IP肯定会动态变化,
那么如何把这个动态的Pod IP 暴露出去?这里借助于 Kubernetes 的 Service 机制,Service 可以以标签的形式选定一组带有指定标签的 Pod,并监控和自动负载他们的 Pod IP,那么我们向外暴露只暴露 Service IP 就行了;这就是 NodePort 模式:
即在每个节点上开起一个端口,然后转发到内部 Pod IP 上。 Service 可以通过标签选择器找到它所关联的 Pod。但是属于四层代理,只能基于 IP 和端口代理。 Service 存在一个问题,什么问题呢?
Service 的 type 类型有很多,如 NodePort、clusterIp、loadbalancer、externalname,如果Service 想要被 k8s 集群外部访问,需要用 NodePort 类型,但是 NodePort 类型的 svc 有如下几个问题:
nodeport 会在物理机映射一个端口,绑定到物理机上,这样就导致,每个服务都要映射一个端口, 端口过多,维护困难,还有就是 Service 底层使用的是 iptables 或者 ipvs,仅支持四层代理,无法基于https 协议做代理,
因此我们这节课讲解的是 ingress-nginx-controller 七层代理。
1.1.1 四层代理和七层代理的区别对比
区别:
1)四层负载:四层的负载均衡就是基于 IP+端口的负载均衡:在三层负载均衡的基础上,通过发布三层的 IP 地址(VIP),然后加四层的端口号,来决定哪些流量需要做负载均衡,对需要处理的流量进行 NAT 处理,转发至后台服务器,并记录下这个 TCP 或者 UDP 的流量
是由哪台服务器处理的,后续这个连接的所有流量都同样转发到同一台服务器处理。 2)七层的负载均衡就是基于虚拟的 URL 或主机 IP 的负载均衡:在四层负载均衡的基础上(没有四层是绝对不可能有七层的),再考虑应用层的特征,比如同一个 Web 服务器的负载均衡,除了根据 VIP加 80 端口辨别是否需要处理的流量,
还可根据七层的 URL、浏览器类别、语言来决定是否要进行负载均衡。举个例子,如果你的 Web 服务器分成两组,一组是中文语言的,一组是英文语言的,那么七层负载均衡就可以当用户来访问你的域名时,自动辨别用户语言,然后选择对应的语言服务器组进行负载均衡处理。 3)四层负载均衡工作在传输层,七层负载均衡工作在应用层
OSI七层模型
1.2 Ingress介绍
https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress/
Ingress 官网定义:Ingress 可以把进入到集群内部的请求转发到集群中的一些服务上,从而可以把服务映射到集群外部。Ingress 能把集群内 Service 配置成外网能够访问的 URL,流量负载均衡,提供基于域名访问的虚拟主机等。 Ingress 简单的理解就是你原来需要改 Nginx 配置,然后配置各种域名对应哪个 Service,现在把这个动作抽象出来,变成一个 Ingress 对象,你可以用 yaml 创建,每次不要去改 Nginx 了,直接改yaml 然后创建/更新就行了;
那么问题来了:”Nginx 该怎么处理?” Ingress 总结:ingress 是 k8s 中的资源,主要是管理 ingress-controller 这个代理的配置文件 Ingress Controller 这东西就是解决 “Nginx 的处理方式” 的;Ingress Controller 通过与Kubernetes API 交互,动态的去感知集群中 Ingress 规则变化,然后读取他,按照他自己模板生成一段 Nginx 配置,再写到 Nginx Pod 里,最后 reload 一下
1.3 Ingress Controller 介绍
Ingress Controller 是一个七层负载均衡调度器,客户端的请求先到达这个七层负载均衡调度器, 由七层负载均衡器在反向代理到后端 pod,常见的七层负载均衡器有 nginx、traefik,以我们熟悉的nginx 为例:
假如请求到达nginx,会通过 upstream 反向代理到后端 pod 应用,但是后端 pod 的 ip 地址是一直在变化的,因此在后端 pod 前需要加一个 service,这个 service 只是起到分组的作用,那么我们 upstream 只需要填写service 地址即可。 Ingress-controller 里面封装就是 nginx,有的同学问?我直接在物理机上装个 nginx 就行了啊,为啥还弄个 Ingress-controller? Nginx:nginx 配置文件一改动,你还需要手动 reload 一下才可以生效,但是如果用 ingress- controller 封装的nginx,你ingress 维护配置,ingress 创建好之后,会自动的把配置文件传到ingress-controller 这个 pod 里,
会自动进行 reload,然后配置就生效了。
解释:客户端访问域名到Ingress Controller,通过Ingress规则标签选择器识别对应的域名,转发到后端拥有相同对应的标签选择器
1.4 Ingress 和 Ingress Controller总结
Ingress Controller Ingress Controller 结合 Ingress 定义的规则生成配置,然后动态更新 ingress-controller 里的Nginx 或者 trafik 负载均衡器,并刷新使配置生效,来达到服务自动发现的作用。 Ingress 则是定义规则,通过它定义某个域名的请求过来之后转发到集群中指定的 Service。它可以通过 Yaml 文件定义,可以给一个或多个 Service 定义一个或多个 Ingress 规则。
1.5 使用Ingress Controller代理k8s内部Pod的流程
(1) 部署 Ingress controller,我们 ingress controller 使用的是 nginx
(2) 创建 Pod 应用,可以通过控制器创建 pod
(3) 创建 Service,用来分组 pod
(4) 创建 Ingress http,测试通过 http 访问应用
(5) 创建 Ingress https,测试通过 https 访问应用
客户端通过七层调度器访问后端 pod 的方式:
使用七层负载均衡调度器 ingress controller 时,当客户端访问 kubernetes 集群内部的应用时, 数据包走向如下图流程所示
二、Ingress-Controller高可用
2.1 Ingress-controller安装
Ingress Controller 是集群流量的接入层,对它做高可用非常重要,可以基于 keepalive 实现
nginx-ingress-controller 高可用,具体实现如下:
Ingress-controller 根据 Deployment+ nodeSeletor+pod 反亲和性方式部署在 k8s 指定的两个work 节点,nginx-ingress-controller 这个 pod 共享宿主机 ip,然后通过 keepalive+nginx 实现nginx-ingress-controller 高可用 参考:https://github.com/kubernetes/ingress-nginx
https://github.com/kubernetes/ingress- nginx/tree/main/deploy/static/provider/baremetal
1.工作节点下载:
wget https://github.com/kubernetes/ingress-nginx/tree/main/deploy/static/provider/baremetal/deploy.yaml
ctr -n=k8s.io image pull registry.cn-hangzhou.aliyuncs.com/google_containers/kube-webhook-certgen:v1.5.2
ctr -n=k8s.io image pull registry.cn-hangzhou.aliyuncs.com/google_containers/nginx-ingress-controller:v1.8.1
2.修改deploy.yaml中image下载地址为上面的地址
已经准备好了的镜像导入命令,例如:
ctr -n=k8s.io images import nginx-ingress-controllerv1.8.1.tar.gz
# 1.8.1 ingress-nginx-admission-patch报错 [root@master xc]# kubectl apply -f ingress-deploy-1.8.1.yaml
namespace/ingress-nginx created
serviceaccount/ingress-nginx created
serviceaccount/ingress-nginx-admission created
role.rbac.authorization.k8s.io/ingress-nginx created
role.rbac.authorization.k8s.io/ingress-nginx-admission created
clusterrole.rbac.authorization.k8s.io/ingress-nginx created
clusterrole.rbac.authorization.k8s.io/ingress-nginx-admission created
rolebinding.rbac.authorization.k8s.io/ingress-nginx created
rolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created
configmap/ingress-nginx-controller created
service/ingress-nginx-controller created
service/ingress-nginx-controller-admission created
deployment.apps/ingress-nginx-controller created
job.batch/ingress-nginx-admission-create created
job.batch/ingress-nginx-admission-patch created
ingressclass.networking.k8s.io/nginx created
validatingwebhookconfiguration.admissionregistration.k8s.io/ingress-nginx-admission created [root@master xc]# kubectl get svc -n ingress-nginx
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
ingress-nginx-controller NodePort 10.109.79.199 <none> 80:31476/TCP,443:31690/TCP 37m
ingress-nginx-controller-admission ClusterIP 10.106.65.1 <none> 443/TCP 37m [root@master xc]# kubectl get pods -n ingress-nginx -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
ingress-nginx-admission-create-9rb7x 0/1 Completed 0 37m 10.244.104.4 node2 <none> <none>
ingress-nginx-controller-67b9c5567c-cxdp4 1/1 Running 0 37m 10.244.104.6 node2 <none> <none>
ingress-deploy-1.8.1执行
# 1.1.0版本在k8s-1.27版本前都适合使用
# 1.工作节点导入
ctr -n=k8s.io images import kube-webhook-certgen-
v1.1.0.tar.gz
ctr -n=k8s.io images import ingress-nginx- controllerv1.1.0.tar.gz # 2.执行deploy配置文件
[root@master ingress]# kubectl apply -f ingress-deploy.yaml
namespace/ingress-nginx created
serviceaccount/ingress-nginx created
configmap/ingress-nginx-controller created
clusterrole.rbac.authorization.k8s.io/ingress-nginx created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx created
role.rbac.authorization.k8s.io/ingress-nginx created
rolebinding.rbac.authorization.k8s.io/ingress-nginx created
service/ingress-nginx-controller-admission created
service/ingress-nginx-controller created
deployment.apps/ingress-nginx-controller created
ingressclass.networking.k8s.io/nginx created
validatingwebhookconfiguration.admissionregistration.k8s.io/ingress-nginx-admission created
serviceaccount/ingress-nginx-admission created
clusterrole.rbac.authorization.k8s.io/ingress-nginx-admission created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created
role.rbac.authorization.k8s.io/ingress-nginx-admission created
rolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created
job.batch/ingress-nginx-admission-create created
job.batch/ingress-nginx-admission-patch created [root@master ingress]# kubectl get pods -n ingress-nginx -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
ingress-nginx-admission-create-75js9 0/1 Completed 0 17s 10.244.104.17 node2 <none> <none>
ingress-nginx-admission-patch-5gf2n 0/1 Completed 0 17s 10.244.104.18 node2 <none> <none>
ingress-nginx-controller-678b9b68c4-5ttpv 1/1 Running 0 17s 192.168.10.12 node2 <none> <none>
ingress-nginx-controller-678b9b68c4-fv5w7 0/1 Running 0 17s 192.168.10.11 node1 <none> <none> [root@master ingress]# kubectl get deploy -n ingress-nginx
NAME READY UP-TO-DATE AVAILABLE AGE
ingress-nginx-controller 2/2 2 2 70s
[root@master ingress]# kubectl get svc -n ingress-nginx
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
ingress-nginx-controller NodePort 10.96.129.166 <none> 80:32396/TCP,443:30834/TCP 90s
ingress-nginx-controller-admission ClusterIP 10.99.164.203 <none> 443/TCP 91s
2.2 通过keepalived+nginx实现ingress-nginx-controller高可用
# node1和2节点安装
yum install nginx keepalived nginx-mod-stream -y #2.修改nginx.conf配置文件,注意下upstream
# stream模块和http模块
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid; # Load dynamic modules. See /usr/share/doc/nginx/README.dynamic.
include /usr/share/nginx/modules/*.conf; events {
worker_connections 1024;
} stream {
log_format main '$remote_addr $upstream_addr - [$time_local] $status $upstream_bytes_sent';
access_log /var/log/nginx/k8s-access.log main;
# 四层负载均衡,为两台 Master apiserver 组件提供负载均衡
upstream k8s-ingress-controller {
server 192.168.10.11:80 weight=5 max_fails=3 fail_timeout=30s; # Master1 APISERVER IP:PORT
server 192.168.10.12:80 weight=5 max_fails=3 fail_timeout=30s; # Master2 APISERVER IP:PORT
} server {
listen 38999;
proxy_pass k8s-ingress-controller;
}
} 注意:nginx 监听端口变成大于 30000 的端口,比方说 30080,这样访问域名:30080 就可以了,必须是满足大于 30000 以上,才能代理 ingress-controller # 3.配置keepalived.conf配置文件
global_defs {
notification_email {
acassen@firewall.loc
failover@firewall.loc
sysadmin@firewall.loc
}
notification_email_from Alexandre.Cassen@firewall.loc
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id NGINX_MASTER #备用服NGINX_BACKUP
} vrrp_script check_nginx {
script "/etc/keepalived/check_nginx.sh"
} vrrp_instance VI_1 {
state MASTER # 备用服BACKUP
interface ens33 # 修改为实际网卡名
virtual_router_id 50 # VRRP 路由 ID实例,每个实例是唯一的,备用服改为51
priority 100 # 优先级,备服务器设置 90
advert_int 1 # 指定VRRP 心跳包通告间隔时间,默认1秒
authentication {
auth_type PASS
auth_pass 1111
}
# 虚拟IP
virtual_ipaddress {
192.168.10.15/24
}
track_script {
check_nginx
}
} #vrrp_script:指定检查nginx工作状态脚本(根据nginx状态判断是否故障转移)
#virtual_ipaddress:虚拟IP(VIP) # 4.nginx检查脚本
[root@node2 keepalived]# cat check_nginx.sh
#!/bin/bash
#1、判断Nginx是否存活
counter=$(ps -ef |grep nginx | grep sbin | egrep -cv "grep|$$" )
if [ $counter -eq 0 ]; then
#2、如果不存活则尝试启动Nginx
service nginx start
sleep 2
#3、等待2秒后再次获取一次Nginx状态
counter=$(ps -ef |grep nginx | grep sbin | egrep -cv "grep|$$" )
#4、再次进行判断,如Nginx还不存活则停止Keepalived,让地址进行漂移
if [ $counter -eq 0 ]; then
service keepalived stop
fi
fi chmod +x /etc/keepalived/check_nginx.sh
[root@node1 keepalived]# ip addr
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:0c:29:95:60:dd brd ff:ff:ff:ff:ff:ff
inet 192.168.10.11/24 brd 192.168.10.255 scope global noprefixroute ens33
valid_lft forever preferred_lft forever
inet 192.168.10.15/24 scope global secondary ens33
valid_lft forever preferred_lft forever
inet6 fe80::c94e:2729:9c6d:7fee/64 scope link tentative noprefixroute dadfailed
valid_lft forever preferred_lft forever
inet6 fe80::5c9b:f359:cfa0:c018/64 scope link noprefixroute
valid_lft forever preferred_lft forever
测试keepalived方法:停止node1上keepalived,看看192.168.10.15是否飘移到node2上,启动node1的keepalived后,IP是否漂移回来
2.3 测试Ingress HTTP代理k8s内部Pod
2.3.1 部署后端tomcat服务
[root@master ingress]# cat ingress-demo.yaml
apiVersion: v1
kind: Service
metadata:
name: tomcat
namespace: default
spec:
selector:
app: tomcat
release: canary
ports:
- name: http
targetPort: 8080
port: 8080
- name: ajp
targetPort: 8009
port: 8009
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: tomcat-deploy
namespace: default
spec:
replicas: 2
selector:
matchLabels:
app: tomcat
release: canary
template:
metadata:
labels:
app: tomcat
release: canary
spec:
containers:
- name: tomcat
image: tomcat:8.5.34-jre8-alpine
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 8080
name: ajp
containerPort: 8009 [root@master ingress]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
tomcat-deploy-695ff4ff9c-8t92m 1/1 Running 0 3m21s 10.244.104.19 node2 <none> <none>
tomcat-deploy-695ff4ff9c-q9p94 1/1 Running 0 3m21s 10.244.166.157 node1 <none> <none> [root@master ingress]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 6d1h
tomcat ClusterIP 10.105.250.63 <none> 8080/TCP,8009/TCP 3m49s [root@master ingress]# kubectl describe svc tomcat
Name: tomcat
Namespace: default
Labels: <none>
Annotations: <none>
Selector: app=tomcat,release=canary
Type: ClusterIP
IP Family Policy: SingleStack
IP Families: IPv4
IP: 10.105.250.63
IPs: 10.105.250.63
Port: http 8080/TCP
TargetPort: 8080/TCP
Endpoints: 10.244.104.19:8080,10.244.166.157:8080
Port: ajp 8009/TCP
TargetPort: 8009/TCP
Endpoints: 10.244.104.19:8009,10.244.166.157:8009
Session Affinity: None
Events: <none>
2.3.2 Ingress 字段
[root@master ingress]# kubectl explain ingress
KIND: Ingress
VERSION: networking.k8s.io/v1 FIELDS:
apiVersion <string>
kind <string>
metadata <Object>
spec <Object>
status <Object> [root@master ingress]# kubectl explain ingress.spec
FIELDS:
defaultBackend <Object>
ingressClassName <string>
rules <[]Object>
- host <string> 域名
- http <Object>
- paths <[]Object> -required-
- backend <Object> -required- 关联后端
- resource <Object>
- service <Object>
- name <string> -required-:关联的service名字
- port <Object>
- name <string>
- number <integer>
- path <string> 指定路由
- pathType <string> -required-
tls <[]Object>
2.3.3 编写ingress规则:http访问
[root@master ingress]# cat ingress-nginx.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress-myapp
namespace: default
# 注解:可能其它版本不能用,1.25版本换方法
#annotations:
# 将创建的ingress规则交给ingress-nginx-controller这2个pod
# kubernetes.io/ingress.class: "nginx"
spec:
# 代替上面的注解
ingressClassName: nginx
rules:
- host: tomcat.lucky.com
http:
paths:
- backend:
service:
name: tomcat
port:
number: 8080
path: /
pathType: Prefix [root@master ingress]# kubectl apply -f ingress-nginx.yaml
ingress.networking.k8s.io/ingress-myapp created
[root@master ingress]# kubectl get ingress
NAME CLASS HOSTS ADDRESS PORTS AGE
ingress-myapp nginx tomcat.lucky.com 192.168.10.11,192.168.10.12 80 23s
[root@master ingress]# kubectl describe ingress ingress-myapp
Name: ingress-myapp
Labels: <none>
Namespace: default
Address: 192.168.10.11,192.168.10.12
Ingress Class: nginx
Default backend: <default>
Rules:
Host Path Backends
---- ---- --------
tomcat.lucky.com
/ tomcat:8080 (10.244.104.19:8080,10.244.166.157:8080)
Annotations: <none>
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Sync 11m (x2 over 12m) nginx-ingress-controller Scheduled for sync
Normal Sync 11m (x2 over 12m) nginx-ingress-controller Scheduled for sync
# 登录一个ingress-nginx-controller查看nginx配置
[root@master ingress]# kubectl get pods -n ingress-nginx
NAME READY STATUS RESTARTS AGE
ingress-nginx-admission-create-75js9 0/1 Completed 0 110m
ingress-nginx-admission-patch-5gf2n 0/1 Completed 0 110m
ingress-nginx-controller-678b9b68c4-5ttpv 1/1 Running 0 110m
ingress-nginx-controller-678b9b68c4-fv5w7 1/1 Running 0 110m [root@master ingress]# kubectl exec -it ingress-nginx-controller-678b9b68c4-5ttpv -n ingress-nginx -- /bin/sh
cat nginx.conf # 本地绑定hosts域名
192.168.10.15 tomcat.lucky.com # 浏览器访问
http://tomcat.lucky.com:38999/
访问代理流程:浏览器访问tomcat.lucky.com:38999--->192.168.10.15:30080--->192.168.10.11:80,192.168.10.12:80--->svc:tomcat:8080--->pod:tomcat-deploy
2.3.4 基于 Ingress https 代理k8s内部pod
# 1.构建TLS站点
# 1.1 准备证书
[root@master home]# openssl genrsa -out tls.key 2048
[root@master home]# openssl req -new -x509 -key tls.key -out tls.crt -subj /C=CN/ST=Beijing/L=Beijing/O=DevOps/CN=tomcat.lucky.com
# 1.2 master上生成secret
[root@master home]# kubectl create secret tls tomcat-ingress-secret --cert=tls.crt --key=tls.key
secret/tomcat-ingress-secret created
[root@master home]# kubectl get secret
NAME TYPE DATA AGE
tomcat-ingress-secret kubernetes.io/tls 2 21s
[root@master home]# kubectl describe secret tomcat-ingress-secret
Name: tomcat-ingress-secret
Namespace: default
Labels: <none>
Annotations: <none> Type: kubernetes.io/tls Data
====
tls.crt: 1294 bytes
tls.key: 1675 bytes # 2.创建Ingress
Ingress 规则可以参考官方:
https://kubernetes.io/zh/docs/concepts/services-networking/ingress/
# 帮助命令
kubectl explain ingress.spec.tls
kubectl explain ingress.spec.rules.http.paths.backend.service [root@master ingress]# cat ingress-tomcat-tls.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress-tomcat-tls
namespace: default
spec:
ingressClassName: nginx
tls:
- hosts:
- test.lucky.com
secretName: tomcat-ingress-secret
rules:
- host: test.lucky.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: tomcat
port:
number: 8080
# 上面使用过tomcat.lucky.com这个域名,https的时候不能使用,否则报错
[root@master ingress]# kubectl apply -f ingress-tomcat-tls.yaml
ingress.networking.k8s.io/ingress-tomcat-tls created
[root@master ingress]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 6d2h
tomcat ClusterIP 10.105.250.63 <none> 8080/TCP,8009/TCP 77m [root@master ingress]# kubectl describe svc tomcat
Name: tomcat
Namespace: default
Labels: <none>
Annotations: <none>
Selector: app=tomcat,release=canary
Type: ClusterIP
IP Family Policy: SingleStack
IP Families: IPv4
IP: 10.105.250.63
IPs: 10.105.250.63
Port: http 8080/TCP
TargetPort: 8080/TCP
Endpoints: 10.244.104.19:8080,10.244.166.157:8080
Port: ajp 8009/TCP
TargetPort: 8009/TCP
Endpoints: 10.244.104.19:8009,10.244.166.157:8009
Session Affinity: None
Events: <none>
[root@master ingress]# kubectl get ingress
NAME CLASS HOSTS ADDRESS PORTS AGE
ingress-myapp nginx tomcat.lucky.com 192.168.10.11,192.168.10.12 80 45m
ingress-tomcat-tls nginx test.lucky.com 192.168.10.11,192.168.10.12 80, 443 6m38s
# 本地hosts绑定后,页面访问:https://tomcat.lucky.com/
k8s七层代理Ingress-nginx-controller的更多相关文章
- kubernetes系列(十) - 通过Ingress实现七层代理
1. Ingress入门 1.1 Ingress简介 1.2 原理和组成部分 1.3 资料信息 2. Ingress部署的几种方式 2.1 前言 2.1 Deployment+LoadBalancer ...
- Nginx的四层和七层代理
理论部分: 所谓四层负载均衡,也就是主要通过报文中的目标地址和端口,再加上负载均衡设备设置的服务器选择方式,决定最终选择的内部服务器,它一般走的是tcp,udp协议 所谓七层负载均衡,也称为“内 ...
- 基于Netty的四层和七层代理性能方面的一些压力测试
本文我们主要是想测试和研究几点: 基于Netty写的最简单的转发HTTP请求的程序,四层和七层性能的差异 三种代理线程模型性能的差异,下文会详细解释三种线程模型 池和非池化ByteBuffer性能的差 ...
- 老斜两宗事-七层代理模式还是IP层VPN
1.七层代理模式还是IP层VPN 非常多人会问,我究竟是使用代理模式呢,还是使用VPN模式,假设我想数据在中间不安全的链路上实现加密保护的话.这个问题有一个背景.那就是,你想保护你的数据,能够使用VP ...
- 阿里云负载均衡SLB 七层https协议 nginx 获取真实IP
https://www.cnblogs.com/baylorqu/p/8565667.html https://help.aliyun.com/document_detail/54007.html
- 搭建Nginx七层反向代理
基于https://www.cnblogs.com/Dfengshuo/p/11911406.html这个基础上,在来补充下七层代理的配置方式.简单理解下四层和七层协议负载的区别吧,四层是网络层,负载 ...
- nginx 七层负载均衡
[tcp] nginx 七层负载均衡 nginx负载均衡概述 当我们的Web服务器直接面向用户,往往要承载大量并发请求,单台服务器难以负荷,我使用多台Web服务器组成集群,前端使用Nginx负载均衡, ...
- 云原生之旅 - 8)云原生时代的网关 Ingress Nginx
前言 当我们在Kubernetes部署的服务需要暴露给外部用户使用时,有三种选择:LoadBalancer,NodePort, Ingress. LoadBalancer类型得结合各个Cloud Pr ...
- linux负载均衡总结性说明(四层负载/七层负载)
在常规运维工作中,经常会运用到负载均衡服务.负载均衡分为四层负载和七层负载,那么这两者之间有什么不同?废话不多说,详解如下: 一,什么是负载均衡1)负载均衡(Load Balance)建立在现有网络结 ...
- 四层and七层负载均衡
四层负载/七层负载 在常规运维工作中,经常会运用到负载均衡服务.负载均衡分为四层负载和七层负载,那么这两者之间有什么不同? 废话不多说,详解如下: 1. 什么是负载均衡 1)负载均衡(Load ...
随机推荐
- pycharm 常见易错的PEP8规范
PEP8规范 ( Python Enhancement Proposal ) PEP 8: E231 missing whitespace after ','这个意思是逗号后面要有一个空格 PEP 8 ...
- vue初学核心基础
一.初识vue 1.vue的使用 导入vue之后创建vue模块,el属性表示控制区域的id名称,data表示该区域内的数据 在vue中我们都是用表中模板的标准语法来传递数据 <head> ...
- 深入在线文档系统的 MarkDown/Word/PDF 导出能力设计
深入在线文档系统的 MarkDown/Word/PDF 导出能力设计 当我们实现在线文档的系统时,通常需要考虑到文档的导出能力,特别是对于私有化部署的复杂ToB产品来说,文档的私有化版本交付能力就显得 ...
- BIO ,NIO ,AIO
一.同步阻塞I/O(BIO): 服务器实现模式: 一个连接一个线程,即客户端有连接请求时服务器就需要启动一个线程进行处理 弊端:如果这个连接不做任何事情会造成不必要的线程开销 解决措施:可以通过线程池 ...
- #双指针#洛谷 7521 [省选联考 2021 B 卷] 取模
题目传送门 分析 将 \(a\) 排序后从大到小枚举 \(a_k\),注意枚举的时候重复的只考虑一次,那么可以将其它数按照模 \(a_k\) 后排序, 答案只可能来自最大值与次大值之和取模或者之和最接 ...
- 记一次 .NET某管理局检测系统 内存暴涨分析
一:背景 1. 讲故事 前些天有位朋友微信找到我,说他们的WPF程序有内存泄漏的情况,让我帮忙看下怎么回事?并且dump也抓到了,网上关于程序内存泄漏,内存暴涨的文章不计其数,看样子这个dump不是很 ...
- 深入学习 XML 解析器及 DOM 操作技术
所有主要的浏览器都内置了一个XML解析器,用于访问和操作XML XML 解析器 在访问XML文档之前,必须将其加载到XML DOM对象中 所有现代浏览器都有一个内置的XML解析器,可以将文本转换为XM ...
- 深入解析 Java 面向对象编程与类属性应用
Java 面向对象编程 面向对象编程 (OOP) 是一种编程范式,它将程序组织成对象.对象包含数据和操作数据的方法. OOP 的优势: 更快.更易于执行 提供清晰的结构 代码更易于维护.修改和调试 提 ...
- C 多维数组、特殊字符和字符串函数详解
C 多维数组 数组,也称为单维数组.这些非常棒,是您在 C 语言编程中会经常使用的东西.然而,如果您想要将数据存储为表格形式,例如带有行和列的表格,则需要熟悉多维数组. 二维数组 二维数组也称为矩阵, ...
- C语言 04 基本数据类型
整数 整数就是不包含小数点的数字,整数包含以下几种类型: short :占用 2 个字节,16 个 bit 位. int:占用 4 个字节,32 个 bit 位,能够表示 -2^32 到 2^32 之 ...