文章目录

k8s网络模型

Kubernetes 的网络利用了 Docker 的网络原理，并在此基础上实现了跨 Node 容器间的网络通信。

在这里插入图片描述

Kubernetes之POD、容器之间的网络通信

同一节点

在这里插入图片描述
三个网络设备:
eth0: 节点主机网卡
docker0: docker网桥
veth0: 虚拟网卡

同一个POD上Container通信

在k8s中每个Pod容器有一个pause容器有独立的网络命名空间(netns)，在Pod内启动Docker容器时候使用 –net=container就可以让当前Docker容器加入到Pod容器拥有的网络命名空间(pause容器)

这里就是为什么k8s在调度pod时，尽量把关系紧密的服务放到一个pod中，这样网络的请求耗时就可以忽略，因为容器之间通信共享了网络空间，就像local本地通信一样。

在k8s中每个Pod中管理着一组Docker容器，这些Docker容器共享同一个网络命名空间，Pod中的每个Docker容器拥有与Pod相同的IP和port地址空间，并且由于他们在同一个网络命名空间，他们之间可以通过localhost相互访问。

什么机制让同一个Pod内的多个docker容器相互通信?就是使用Docker的一种网络模型：–net=container

container模式指定新创建的Docker容器和已经存在的一个容器共享一个网络命名空间，而不是和宿主机共享。新创建的Docker容器不会创建自己的网卡，配置自己的 IP，而是和一个指定的容器共享 IP、端口范围等

同一个 Node 下 不同Pod 间通信模型：

pod与pod之间的网络：首先pod自身拥有一个IP地址，不同pod之间直接使用IP地址进行通信即可

正常交换路由通信

如容器⽹络模型⼀样，对于同⼀主机上的 pod 之间，通过 docker0 ⽹桥设备直接⼆层(数据链路层)⽹络上通过 MAC 地址直接通信：

在这里插入图片描述
veth（虚拟网络设备）
eth0（网卡）

pod1–>pod2（同一台node上），pod1通过自身eth0网卡发送数据，eth0连接着veth0，网桥把veth0和veth1组成了一个以太网，然后数据到达veth0之后，网桥通过转发表，发送给veth1，veth1直接把数据传给pod2的eth0。

不同pod之间的通信，就是使用linux虚拟以太网设备或者说是由两个虚拟接口组成的veth对使不同的网络命名空间链接起来，这些虚拟接口分布在多个网络命名空间上(这里是指多个Pod上)。

通过网桥把veth0和veth1组成为一个以太网，他们直接是可以直接通信的，另外这里通过veth对让pod1的eth0和veth0、pod2的eth0和veth1关联起来，从而让pod1和pod2相互通信。

不同节点

常见k8S容器互通网络方案就是两种，路由模式和覆盖网络overlay 隧道模式

在这里插入图片描述

不同node节点上pod和pod通信

vxlan封装一层node ip进行普通路由交换
在这里插入图片描述

上图就是不同node之间的pod通信，Node1中的Pod1如何和Node2的Pod4进行通信的，我们来看看具体流程：

1)首先pod1通过自己的以太网设备eth0把数据包发送到关联到root命名空间的veth0上

2)然后数据包被Node1上的网桥设备（dcoker0）接收到，网桥查找转发表发现找不到pod4的Mac地址，则会把包转发到默认路由(root命名空间的eth0设备)

3)然后数据包经过eth0（主机网卡）就离开了Node1，被发送到网络。

4)数据包到达Node2后，首先会被root命名空间的eth0设备

5)然后通过网桥把数据路由到虚拟设备veth1,最终数据表会被流转到与veth1配对的另外一端(pod4的eth0)

每个Node都知道如何把数据包转发到其内部运行的Pod，当一个数据包到达Node后，其内部数据流就和Node内Pod之间的流转类似了

k8s网络接口 CNI

在这里插入图片描述

在这里插入图片描述

  • Overlay 模式的典型特征是容器独⽴于主机的 IP 段，这个 IP 段进⾏跨主机⽹络通信时是通过在主机之间创建隧道的⽅式，将整个容器⽹段的包全都封装成底层的物理⽹络中主机之间的包。该⽅式的好处在于它不依赖于底层⽹络；
  • 路由模式中主机和容器也分属不同的⽹段，它与 Overlay 模式的主要区别在于它的跨主机通信是通过路由打通，⽆需在不同主机之间
    做⼀个隧道封包。但路由打通就需要部分依赖于底层⽹络，⽐如说要求底层⽹络有⼆层可达的⼀个能⼒；
  • Underlay 模式中容器和宿主机位于同⼀层⽹络，两者拥有相同的地位。容器之间⽹络的打通主要依靠于底层⽹络。因此该模式是强依赖于底层能⼒的。

路由网络

在这里插入图片描述

修改主机路由：把容器⽹络加到主机路由表中，把主机⽹络设备当作容器⽹关，通过路由规则转发到指定的主机，实现容器的三层互通。

⽬前通过路由技术实现容器跨主机通信的⽹络如 Flannel host-gw、Calico 等

覆盖网络

在这里插入图片描述

隧道传输(overlay)：将容器的数据包封装到原主机⽹络的三层或者四层数据包中，然后使⽤主机⽹络的 IP 或者 TCP/UDP 传输到⽬标主机，⽬标主机拆包后再转发给⽬标容器。overlay 隧道传输常见⽅案包括 Vxlan、ipip 等，⽬前使⽤ overlay 隧道传输技术的主流容器⽹络有 Flannel 等；

pod与service之间的网络

pod的ip地址是不持久的，当集群中pod的规模缩减或者pod故障或者node故障重启后，新的pod的ip就可能与之前的不一样的。所以k8s中衍生出来Service来解决这个问题。

Service管理了多个Pods，每个Service有一个虚拟的ip,要访问service管理的Pod上的服务只需要访问你这个虚拟ip就可以了，这个虚拟ip是固定的，当service下的pod规模改变、故障重启、node重启时候，对使用service的用户来说是无感知的，因为他们使用的service的ip没有变。

当数据包到达Service虚拟ip后，数据包会被通过k8s给该servcie自动创建的负载均衡器路由到背后的pod容器。

在k8s里，iptables规则是由kube-proxy配置，kube-proxy监视APIserver的更改，因为集群中所有service（iptables）更改都会发送到APIserver上，所以每台kubelet-proxy监视APIserver，当对service或pod虚拟IP进行修改时，kube-proxy就会在本地更新，以便正确发送给后端pod

Service网络

在这里插入图片描述

在这里插入图片描述

Ingress

Ingress构成

Ingress 主要有两部分组成：

  • Ingress 对象：提供 Ingress kubernetes 对象，能够通过 yaml 进行创建和更新，用于将服务与域名对应起来；
  • Ingress Controller：部署在集群中的公共组件，将 Ingress 服务的配置转化成外部负载均衡的配置，对负载均衡器进行管理和更新。

Ingress 实现原理

在Ingress的使用过程中，常常会遇到一些问题，比如客户端访问偶尔报：“502”或“504”错误、域名证书配置不生效、获取不到客户端真实IP地址等。

了解Ingress路由的实现原理，对于解决Ingress各种问题十分有帮助。本节将讲解Ingress是如何实现复杂的七层路由策略的。

以阿里云的Ingress组件为例，Ingress可以分为三个部分，分别是入口SLB（由Nginx-ingress-lb这个Service创建）、控制器以及Nginx代理，如下图所示。

在这里插入图片描述

Ingress的实现包含了两部分内容，一个是Controller，即Ingress控制器，另一个是Nginx代理。当创建一个Ingress对象的时候，控制器会作为Ingress对象和Nginx之间的翻译官，把Ingress中定义的路由配置转换为Nginx的配置。

如果Ingress定义有错误，翻译工作会失败，导致最新的规则没有办法下发到Nginx里。控制器日志的Nginx的Access/Error日志，都会汇总到Nginx

Ingress Controller这个Pod的标准输出，可以从Pod的标准输出查看控制器的日志或者Nginx的访问日志。

一般情况下，如果需要查看生效的Nginx配置，我们可登录到Nginx Ingress Controller容器里，查看配置文件/etc/nginx/nginx.conf。

为了减少对Nginx配置高频率加载这样的操作，Nginx Ingress Controller引入了Lua模块。Lua模块可以协助Nginx低“成本”地更新Upstream，以避免此类操作对业务的影响。

在Ingress控制器里获取Lua配置的方法如下。

  • 进入Pod。

    kubectl -n kube-system exec -ti nginx-ingress-controller-7d7c69b5b8-d7qxw /bin/bash

  • 查看配置

    cur lhttp://127.0.0.1:10246/configuration/backends

https://www.jianshu.com/p/727e5aa93c58

ingress流量分析

在这里插入图片描述

在这里插入图片描述

我们可以看到，因为 nginx-ingress 这个 pod 做了所有 service 的代理，在高并发情况下将承受巨大压力，我们可以增加多个 pod 实例。

->域名请求
->lb(监听node（部分或全部 看配置）)
->node上lvs路由规则负责均衡转发 nginx-ingress-controller所有pod
->nginx ingress路由匹配cluster_ip(controller监听)
->cluster_ip通过ipvs将请求转发给pod(kube-proxy监听pod、service变化，维护node ipvs或iptable规则)

查看nginx配置，路由转发对应 namespace-service-name-port

<<K9s-Shell>> Pod: kube-system/nginx-ingress-controller-f-scbdd | Container: nginx-ingress-controller
bash-5.1$ cat nginx.conf

	## start server test-app.com
	server {
		server_name test-app.com ;

		listen 80  ;
		listen [::]:80  ;
		listen 443  ssl http2 ;
		listen [::]:443  ssl http2 ;

		set $proxy_upstream_name "-";

		ssl_certificate_by_lua_block {
			certificate.call()
		}

		location / {

			set $namespace      "service";
			set $ingress_name   "test";
			set $service_name   "test";
			set $service_port   "9443";
			set $location_path  "/";
			set $global_rate_limit_exceeding n;

			rewrite_by_lua_block {
				lua_ingress.rewrite({
					force_ssl_redirect = false,
					ssl_redirect = true,
					force_no_ssl_redirect = false,
					preserve_trailing_slash = false,
					use_port_in_redirects = false,
					global_throttle = { namespace = "", limit = 0, window_size = 0, key = { }, ignored_cidrs = { } },
				})
				balancer.rewrite()
				plugins.run()
			}

			# be careful with `access_by_lua_block` and `satisfy any` directives as satisfy any
			# will always succeed when there's `access_by_lua_block` that does not have any lua code doing `ngx.exit(ngx.DECLINED)`
			# other authentication method such as basic auth or external auth useless - all requests will be allowed.
			#access_by_lua_block {
			#}

			header_filter_by_lua_block {
				lua_ingress.header()
				plugins.run()
			}

			body_filter_by_lua_block {
				plugins.run()
			}

			log_by_lua_block {
				balancer.log()

				monitor.call()

				plugins.run()
			}

			port_in_redirect off;

			set $balancer_ewma_score -1;
			set $proxy_upstream_name "service-test-app-9443";
			set $proxy_host          $proxy_upstream_name;
			set $pass_access_scheme  $scheme;

			set $pass_server_port    $server_port;

			set $best_http_host      $http_host;
			set $pass_port           $pass_server_port;

			set $proxy_alternative_upstream_name "";

			client_max_body_size                    20m;

			proxy_set_header Host                   $best_http_host;

			# Pass the extracted client certificate to the backend

			# Allow websocket connections
			proxy_set_header                        Upgrade           $http_upgrade;

			proxy_set_header                        Connection        $connection_upgrade;

			proxy_set_header X-Request-ID           $req_id;
			proxy_set_header X-Real-IP              $remote_addr;

			proxy_set_header X-Forwarded-For        $remote_addr;

			proxy_set_header X-Forwarded-Host       $best_http_host;
			proxy_set_header X-Forwarded-Port       $pass_port;
			proxy_set_header X-Forwarded-Proto      $pass_access_scheme;
			proxy_set_header X-Forwarded-Scheme     $pass_access_scheme;

			proxy_set_header X-Scheme               $pass_access_scheme;

			# Pass the original X-Forwarded-For
			proxy_set_header X-Original-Forwarded-For $http_x_forwarded_for;

			# mitigate HTTPoxy Vulnerability
			# https://www.nginx.com/blog/mitigating-the-httpoxy-vulnerability-with-nginx/
			proxy_set_header Proxy                  "";

			# Custom headers to proxied server

			proxy_connect_timeout                   10s;
			proxy_send_timeout                      60s;
			proxy_read_timeout                      60s;

			proxy_buffering                         off;
			proxy_buffer_size                       4k;
			proxy_buffers                           4 4k;

			proxy_max_temp_file_size                1024m;

			proxy_request_buffering                 on;
			proxy_http_version                      1.1;

			proxy_cookie_domain                     off;
			proxy_cookie_path                       off;

			# In case of errors try the next upstream server before returning an error
			proxy_next_upstream                     error timeout;
			proxy_next_upstream_timeout             0;
			proxy_next_upstream_tries               3;

			proxy_pass http://upstream_balancer;

			proxy_redirect                          off;

		}

	}
	## end server test-app.com

部署多套Ingress Controller

有时需要部署多套Ingress Controller，一套给VPC内网使用，另一套给公网使用。

在这里插入图片描述

ExternalTrafficPolicy的影响

ExternalTrafficPolicy字段通常出现在LoadBalancer类型的服务中，它有两个值：Local和Cluster。

在这里插入图片描述

在Local模式下，SLB会将流量发往Pod所在的节点，即节点1和节点3，然后转发到本节点的Pod上。

在这里插入图片描述

在Cluster模式下，SLB会将流量随机转发到任意一个Worker节点，然后Worker节点再随机转发到其中一个Pod上，既可能是转发到本届点的Pod上，有可能是转发到其他节点的Pod上。

跨节点转发是由SNAT实现的，而SNAT会修改掉报文的Source IP地址，Pod收到的报文的Source IP地址就是节点的IP地址，这样就把前一级的真实IP地址替换掉了。

前面讲过，SLB再四层的情况下，Client的真实IP地址是透传（不经过代理修改，直接转发）的。因此，Ingress-nginx无法获取客户端的真实IP地址。

如何获取客户端真实IP地址

根据上节所讲，需要将ExternelTrafficPolicy的值设置为Local，才能保证Ingress-nginx可以获取客户端的真实IP地址。这里分两种情况。

（1）SLB为四层转发时，Ingress-nginx可以正确获取到客户端真实IP地址，不需要做任何改动，Pod需要从Header里获取客户端真实IP地址。

（2）SLB为七层转发时，Tenginx会将客户端真实IP地址放到X-Forwarded-For里，同样，Ingress-nginx也会添加Tenginx的IP地址到X-Forwarded-For并传递给Pod。当Tenginx前面有多层代理时也是一样的。同时，我们需要再SLB和Ingress-nginx上开启X-Forwarded-For。SLB默认开启，Ingress-nginx开启X-Forwarded-For需要修改nginx-configuration，在data中添加：

https://www.jianshu.com/p/7079094c6518

1.2 Pod IP 地址的由来

https://www.cnblogs.com/sammyliu/p/8274478.html

coredns解析流程和corefile配置

CoreDNS简介

CoreDNS 是一个 Go 语言编写的灵活可扩展的 DNS 服务器，在 Kubernetes 中，作为一个服务发现的配置中心，在 Kubernetes 中创建的 Service 和 Pod 都会在其中自动生成相应的 DNS 记录。Kubernetes 服务发现的特性，使 CoreDNS 很适合作为企业云原生环境的 DNS 服务器，保障企业容器化和非容器化业务服务的稳定运行。

Core-DNS解析流程

当pod1应用想通过dns域名的方式访问pod2则首先根据容器中/etc/resolv.conf内容配置的nameserver地址，向dns服务器发出请求，由service将请求抛出转发给kube-dns service，由它进行调度后端的core-dns进行域名解析。

解析后请求给kubernetes service进行调度后端etcd数据库返回数据，pod1得到数据后由core-dns转发目的pod2地址解析，最终pod1请求得到pod2。

在这里插入图片描述

k8s服务发现 coredns

在这里插入图片描述

core dns配置

3.1 K8s DNS策略

Kubernetes 中 Pod 的 DNS 策略有四种类型。

1.Default：Pod 继承所在主机上的 DNS 配置；

2.ClusterFirst：K8s 的默认设置；先在 K8s 集群配置的 coreDNS 中查询，查不到的再去继承自主机的上游 nameserver 中查询；

3.ClusterFirstWithHostNet：对于网络配置为 hostNetwork 的 Pod 而言，其 DNS 配置规则与 ClusterFirst 一致；

4.None：忽略 K8s 环境的 DNS 配置，只认 Pod 的 dnsConfig 设置。

3.2 resolv.conf

在部署 pod 的时候，如果用的是 K8s 集群的 DNS，那么 kubelet 在起 pause 容器的时候，会将其 DNS 解析配置初始化成集群内的配置。

比如创建了一个叫 my-nginx 的 deployment，其 pod 中的 resolv.conf 文件如下：

# DNS 服务的 IP，即coreDNS 的 clusterIP
nameserver 169.254.25.10

# DNS search 域。解析域名的时候，将要访问的域名依次带入 search 域，进行 DNS 查询
# 比如访问your-nginx，其进行的 DNS 域名查询的顺序是：your-nginx.default.svc.cluster.local. -> your-nginx.svc.cluster.local. -> your-nginx.cluster.local.
search default.svc.cluster.local svc.cluster.local cluster.local

# 其他项，最常见的是 dnots。dnots 指的是如果查询的域名包含的点 “.” 小于 5，则先走search域，再用绝对域名；如果查询的域名包含点数大于或等于 5，则先用绝对域名，再走search域
# K8s 中默认的配置是 5。
options ndots:5

DNS
在 k8s 中做服务发现，最常用的方式是通过 DNS 解析。

在我们的 k8s 集群配置了 dns 服务（最常用的是 coredns）的前提下，我们就可以直接通过全限定域名（FQDN）来访问别的服务。

全限定域名的格式如下：

 # 格式
 <service-name>.<namespace>.svc.cluster.local  # 域名 .svc.cluster.local 是可自定义的
 
 # 举例：访问 default 名字空间下的 nginx 服务
 nginx.default.svc.cluster.local

如果两个服务在同一个名字空间内，可以省略掉后面的 ..svc.cluster.local，直接以服务名称为 DNS 访问别的服务

P.S. DNS 服务发现的实现方式：修改每个容器的 /etc/resolv.conf，使容器访问 k8s 自己的 dns 服务器。而该 dns 服务器知道系统中的所有服务，所以它能给出正确的响应。

4.2 NodeLocal DNSCache

NodeLocal DNSCache通过在集群上运行一个dnsCache daemonset来提高clusterDNS性能和可靠性。相比于纯coredns方案，nodelocaldns + coredns方案能够大幅降低DNS查询timeout的频次，提升服务稳定性。

通过 DaemonSet 在集群的每个节点上部署一个 hostNetwork 的 Pod，该 Pod 是 node-cache，可以缓存本节点上 Pod 的 DNS 请求。如果存在 cache misses ，该 Pod 将会通过 TCP 请求上游 kube-dns 服务进行获取。原理图如下所示：

在这里插入图片描述

NodeLocal DNS Cache 没有高可用性（High Availability，HA），会存在单点 nodelocal dns cache 故障（Pod Evicted/ OOMKilled/ConfigMap error/DaemonSet Upgrade），但是该现象其实是任何的单点代理（例如 kube-proxy，cni pod）都会存在的常见故障问题。

coredns解析流程和corefile配置

使用 NodeLocal DNS Cache

Kubernetes中如何通过DNS name找到IP

kubectl describe service kube-dns -n kube-system

在这里插入图片描述

minikube上自动安装了coredns组件，并为这个组件创建了一个Service，叫kube-dns。通过Service（ip=10.96.0.10:53）可以找到coredns的Pod（ip=172.17.0.3:9153）。

可以看到这里的nameserver IP即为上述的kube-system下的Service为kube-dns的IP。
在这里插入图片描述

另外，我们在Pod的terminal界面中，还可以用nslookup命令来通过name在dns中查找ip

nslookup test-ab-test-srv

在这里插入图片描述

在这里插入图片描述

kube-proxy

kube-proxy 的主要作用是watch apiserver，当监听到pod 或service变化时，修改本地的iptables规则或ipvs规则。

clusterIP如何转换为pod ip呢

linux内核功能
在这里插入图片描述

每台机器上都运行一个kube-proxy服务，它监听api-server 和endpoint变化情况，维护service和pod之间的一对多的关系，通过iptable或者ipvs为服务提供负载均衡的能力。通常kube-proxy作为deemonset运行在各种节点中。

kube-proxy 常支持以下二种：

1）iptables：iptable模式是目前的默认模式，可以看成是userspace模式的升级版，它将请求的代理转发规则全部写入iptable中，砍掉了kube-proxy转发的部分。整个过程全部发生在内核空间，提高了转发性能。但是，iptable的规则是基于链表实现的，规则数量随着Service数量的增加线性增加，查找时间复杂度为O(n)。当Service数量到达一定量级时，CPU消耗和延迟增加显著

2）ipvs：ipvs模式是基于章文嵩博士开发的LVS实现的，ipvs和iptables都是基于内核的netfilter框架实现的，不同的是iptable主攻防火墙，ipvs主攻内核态4层负载均衡。可以说先天上，ipvs就比iptable更适合做Service的实现。

iptables

iptables 模式与 userspace 相同，kube-proxy 持续监听 Service 以及 Endpoints 对象的变化；但它并不在本地节点开启反向代理服务，而是把反向代理全部交给 iptables 来实现；即 iptables 直接将对 VIP 的请求转发给后端 Pod，通过 iptables 设置转发策略。其工作流程大体如下:

在这里插入图片描述

由此分析: 该模式相比 userspace 模式，克服了请求在用户态-内核态反复传递的问题，性能上有所提升，但使用 iptables NAT 来完成转发，存在不可忽视的性能损耗，而且在大规模场景下，iptables 规则的条目会十分巨大，性能上还要再打折扣。

ipvs模式下k8s的网络通信

这种模式，Kube-Proxy 会监视 Kubernetes Service 对象 和 Endpoints，调用 Netlink 接口以相应地创建 IPVS 规则并定期与 Kubernetes Service 对象 和 Endpoints 对象同步 IPVS 规则，以确保 IPVS 状态与期望一致。访问服务时，流量将被重定向到其中一个后端 Pod。

$ ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  10.0.0.1:443 rr persistent 10800
  -> 192.168.0.1:6443             Masq    1      1          0
TCP  10.0.0.10:53 rr
  -> 172.17.0.2:53                Masq    1      0          0
UDP  10.0.0.10:53 rr
  -> 172.17.0.2:53                Masq    1      0          0

网络插件

在这里插入图片描述

阿里云k8s

k8s信息
在这里插入图片描述

在pod内访问 ecs自建数据库

ECS的安全组 放行一下 内网的pod 和vpc的网段
10.0.0.0/8
192.168.0.0/16

在这里插入图片描述

在这里插入图片描述

在pod内测试结果, 内网可以访问:

/data # ping 192.168.0.63
PING 192.168.0.63 (192.168.0.63): 56 data bytes
64 bytes from 192.168.0.63: seq=0 ttl=63 time=0.379 ms
64 bytes from 192.168.0.63: seq=1 ttl=63 time=0.290 ms
64 bytes from 192.168.0.63: seq=2 ttl=63 time=0.294 ms
64 bytes from 192.168.0.63: seq=3 ttl=63 time=0.294 ms
64 bytes from 192.168.0.63: seq=4 ttl=63 time=0.321 ms

从外网访问k8s内部pod流程

进入nginx-ingress-controller pod

cat nginx.conf 可以查看到，通过nginx转发到不同命名空间服务的service

	## start server test-www.ap-inc.com
	server {
		server_name test-www.ap-inc.com ;

		listen 80  ;
		listen 443  ssl http2 ;

		set $proxy_upstream_name "-";

		ssl_certificate_by_lua_block {
			certificate.call()
		}

		location / {
			set $namespace      "ap-fe";
			set $ingress_name   "test-ap-homepage-pc";
			set $service_name   "test-ap-homepage-pc";
			set $service_port   "80";
			set $location_path  "/";
			set $global_rate_limit_exceeding n;

			rewrite_by_lua_block {
				lua_ingress.rewrite({
					force_ssl_redirect = false,
					ssl_redirect = false,
					force_no_ssl_redirect = false,
					preserve_trailing_slash = false,
					use_port_in_redirects = false,
					global_throttle = { namespace = "", limit = 0, window_size = 0, key = { }, ignored_cidrs = { } },
				})
				balancer.rewrite()
				plugins.run()
			}

			# be careful with `access_by_lua_block` and `satisfy any` directives as satisfy any
			# will always succeed when there's `access_by_lua_block` that does not have any lua code doing `ngx.exit(ngx.DECLINED)`
			# other authentication method such as basic auth or external auth useless - all requests will be allowed.
			#access_by_lua_block {
			#}

			header_filter_by_lua_block {
				lua_ingress.header()
				plugins.run()
			}

			body_filter_by_lua_block {
				plugins.run()
			}

			log_by_lua_block {
				balancer.log()

				monitor.call()

				plugins.run()
			}

			port_in_redirect off;

			set $balancer_ewma_score -1;
			set $proxy_upstream_name "ap-fe-test-p-homepage-pc-80";
			set $proxy_host          $proxy_upstream_name;
			set $pass_access_scheme  $scheme;

			set $pass_server_port    $server_port;

			set $best_http_host      $http_host;
			set $pass_port           $pass_server_port;

			set $proxy_alternative_upstream_name "";

			client_max_body_size                    20m;

			proxy_set_header Host                   $best_http_host;

			# Pass the extracted client certificate to the backend

			# Allow websocket connections
			proxy_set_header                        Upgrade           $http_upgrade;

			proxy_set_header                        Connection        $connection_upgrade;

			proxy_set_header X-Request-ID           $req_id;
			proxy_set_header X-Real-IP              $remote_addr;

			proxy_set_header X-Forwarded-For        $remote_addr;

			proxy_set_header X-Forwarded-Host       $best_http_host;
			proxy_set_header X-Forwarded-Port       $pass_port;
			proxy_set_header X-Forwarded-Proto      $pass_access_scheme;
			proxy_set_header X-Forwarded-Scheme     $pass_access_scheme;

			proxy_set_header X-Scheme               $pass_access_scheme;

			# Pass the original X-Forwarded-For
			proxy_set_header X-Original-Forwarded-For $http_x_forwarded_for;

			# mitigate HTTPoxy Vulnerability
			# https://www.nginx.com/blog/mitigating-the-httpoxy-vulnerability-with-nginx/
			proxy_set_header Proxy                  "";

			# Custom headers to proxied server

			proxy_connect_timeout                   10s;
			proxy_send_timeout                      60s;
			proxy_read_timeout                      60s;

			proxy_buffering                         off;
			proxy_buffer_size                       4k;
			proxy_buffers                           4 4k;

			proxy_max_temp_file_size                1024m;

			proxy_request_buffering                 on;
			proxy_http_version                      1.1;

			proxy_cookie_domain                     off;
			proxy_cookie_path                       off;

			# In case of errors try the next upstream server before returning an error
			proxy_next_upstream                     error timeout;
			proxy_next_upstream_timeout             0;
			proxy_next_upstream_tries               3;

			proxy_pass http://upstream_balancer;

			proxy_redirect                          off;

		}

	}
	## end server test-www.ap-inc.com

curl service-name.namespace.svc.cluster.local:port

在这里插入图片描述

在这里插入图片描述

总结：nginx-> service-name -> kube-proxy -> podip

常用命令

进入集群环境 查看pod之间是否可以访问

BusyBox 是一个集成了三百多个最常用Linux命令和工具的软件。 BusyBox
包含了一些简单的工具，例如ls、cat和echo等等，还包含了一些更大、更复杂的工具，例grep、find、mount以及telnet。
有些人将 BusyBox 称为 Linux 工具里的瑞士军刀。 简单的说BusyBox就好像是个大工具箱，它集成压缩了 Linux
的许多工具和命令，也包含了 Linux 系统的自带的shell。

kubectl run busybox --rm=true --image=busybox --restart=Never -it
# kubernetes # 网络 # docker
Logo
K8S/Kubernetes

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐

【深度】阿里巴巴万级规模 K8s 集群全局高可用体系之美

作者 |  韩堂、柘远、沉醉来源 | 阿里巴巴云原生公众号​前言台湾作家林清玄在接受记者采访的时候，如此评价自己 30 多年写作生涯：“第一个十年我才华横溢，‘贼光闪现’，令周边黯然失色；第二个十年，我终于‘宝光现形’，不再去抢风头，反而与身边的美丽相得益彰；进入第三个十年，繁华落尽见真醇，我进入了‘醇光初现’的阶段，真正体味到了境界之美”。​长夜有穷，真水无香。领略过了 K8s“身在江

avatar K8S/Kubernetes

如何基于 K8s 构建下一代 DevOps 平台？

作者 | 孙健波（天元）导读：当前云原生 DevOps 体系现状如何？面临哪些挑战？如何通过 OAM 解决云原生 DevOps 场景下的诸多问题？云原生开发应用模型 OAM(Open Application Model) 社区核心成员孙健波将为大家一一解答，并分享如何基于 OAM 和 Kubernetes 打造无限能力的下一代 DevOps 平台。什么是 DevOps？为什么基于 Kub

avatar K8S/Kubernetes

k8s 火了！

2020，上云之年，产品云端化成为一种趋势。在一线城市，很多公司都已经构建了自己的私有云环境，比如阿里云、网易云、华为云等。而Kubernetes 作为基于容器编排领域的王者，具备扩展...

avatar K8S/Kubernetes