kubernetes核心概念 Service
service作用
使用kubernetes集群运行工作负载时,由于Pod经常处于用后即焚状态,Pod经常被重新生成,因此Pod对应的IP地址也会经常变化,导致无法直接访问Pod提供的服务,Kubernetes中使用了Service来解决这一问题,即在Pod前面使用Service对Pod进行代理,无论Pod怎样变化 ,只要有Label,就可以让Service能够联系上Pod,把Pod IP地址添加到Service对应的端点列表(Endpoints)实现对Pod IP跟踪,进而实现通过Service访问Pod目的。可以将多个Pod对外暴露一个Service,让客户端可以通过Service访问到这一组Pod,并且可以实现负载均衡
- 通过service为pod客户端提供访问pod方法,即可客户端访问pod入口
- 通过标签动态感知pod IP地址变化等
- 防止pod失联
- 定义访问pod访问策略
- 通过label-selector相关联
- 通过Service实现Pod的负载均衡(TCP/UDP 4层)
- 底层实现由kube-proxy通过userspace、iptables、ipvs三种代理模式
kube-proxy三种代理模式
- kubernetes集群中有三层网络,一类是真实存在的,例如Node Network、Pod Network,提供真实IP地址;一类是虚拟的,例如Cluster Network或Service Network,提供虚拟IP地址,不会出现在接口上,仅会出现在Service当中
- kube-proxy始终watch(监控)kube-apiserver上关于Service相关的资源变动状态,一旦获取相关信息kube-proxy都要把相关信息转化为当前节点之上的,能够实现Service资源调度到特定Pod之上的规则,进而实现访问Service就能够获取Pod所提供的服务
- kube-proxy三种代理模式:UserSpace模式、iptables模式、ipvs模式
UserSpace模式
userspace 模式是 kube-proxy 使用的第一代模式,该模式在 kubernetes v1.0 版本开始支持使用。
userspace 模式的实现原理图示如下:
kube-proxy 会为每个 Service 随机监听一个端口(proxy port),并增加一条 iptables 规则。所以通过 ClusterIP:Port 访问 Service 的报文都 redirect 到 proxy port,kube-proxy 从它监听的 proxy port 收到报文以后,走 round robin(默认) 或是 session affinity(会话亲和力,即同一 client IP 都走同一链路给同一 pod 服务),分发给对应的 pod。
由于 userspace 模式会造成所有报文都走一遍用户态(也就是 Service 请求会先从用户空间进入内核 iptables,然后再回到用户空间,由 kube-proxy 完成后端 Endpoints 的选择和代理工作),需要在内核空间和用户空间转换,流量从用户空间进出内核会带来性能损耗,所以这种模式效率低、性能不高,不推荐使用。
iptables模式
iptables 模式是 kube-proxy 使用的第二代模式,该模式在 kubernetes v1.1 版本开始支持,从 v1.2 版本开始成为 kube-proxy 的默认模式。
iptables 模式的负载均衡模式是通过底层 netfilter/iptables 规则来实现的,通过 Informer 机制 Watch 接口实时跟踪 Service 和 Endpoint 的变更事件,并触发对 iptables 规则的同步更新。
iptables 模式的实现原理图示如下:
通过图示我们可以发现在 iptables 模式下,kube-proxy 只是作为 controller,而不是 server,真正服务的是内核的 netfilter,体现在用户态的是 iptables。所以整体的效率会比 userspace 模式高。
ipvs模式
ipvs 模式被 kube-proxy 采纳为第三代模式,模式在 kubernetes v1.8 版本开始引入,在 v1.9 版本中处于 beta 阶段,在 v1.11 版本中正式开始使用。
ipvs(IP Virtual Server) 实现了传输层负载均衡,也就是 4 层交换,作为 Linux 内核的一部分。ipvs
运行在主机上,在真实服务器前充当负载均衡器。ipvs 可以将基于 TCP 和 UDP 的服务请求转发到真实服务器上,并使真实服务器上的服务在单个 IP 地址上显示为虚拟服务。
ipvs 模式的实现原理图示如下:
ipvs 和 iptables 都是基于 netfilter 的,那么 ipvs 模式有哪些更好的性能呢?
- ipvs 为大型集群提供了更好的可拓展性和性能
- ipvs 支持比 iptables 更复杂的负载均衡算法(包括:最小负载、最少连接、加权等)
- ipvs 支持服务器健康检查和连接重试等功能
- 可以动态修改 ipset 的集合,即使 iptables 的规则正在使用这个集合
ipvs 依赖于 iptables。ipvs 会使用 iptables 进行包过滤、airpin-masquerade tricks(地址伪装)、SNAT 等功能,但是使用的是 iptables 的扩展 ipset,并不是直接调用 iptables 来生成规则链。通过 ipset 来存储需要 DROP 或 masquerade 的流量的源或目标地址,用于确保 iptables 规则的数量是恒定的,这样我们就不需要关心有多少 Service 或是 Pod 了。
使用 ipset 相较于 iptables 有什么优点呢?iptables 是线性的数据结构,而 ipset 引入了带索引的数据结构,当规则很多的时候,ipset 依然可以很高效的查找和匹配。我们可以将 ipset 简单理解为一个 IP(段) 的集合,这个集合的内容可以是 IP 地址、IP 网段、端口等,iptables 可以直接添加规则对这个“可变的集合进行操作”,这样就可以大大减少 iptables 规则的数量,从而减少性能损耗。
举一个例子,如果我们要禁止成千上万个 IP 访问我们的服务器,如果使用 iptables 就需要一条一条的添加规则,这样会在 iptables 中生成大量的规则;如果用 ipset 就只需要将相关的 IP 地址(网段)加入到 ipset 集合中,然后只需要设置少量的 iptables 规则就可以实现这个目标。
下面的表格是 ipvs 模式下维护的 ipset 表集合:
设置名称 | 成员 | 用法 |
---|---|---|
KUBE-CLUSTER-IP | 所有服务 IP + 端口 | 在 masquerade-all=true 或 clusterCIDR 指定的情况下对 Service Cluster IP 地址进行伪装,解决数据包欺骗问题 |
KUBE-LOOP-BACK | 所有服务 IP + 端口 + IP | 解决数据包欺骗问题 |
KUBE-EXTERNAL-IP | 服务外部 IP + 端口 | 将数据包伪装成 Service 的外部 IP 地址 |
KUBE-LOAD-BALANCER | 负载均衡器入口 IP + 端口 | 将数据包伪装成 Load Balancer 类型的 Service |
KUBE-LOAD-BALANCER-LOCAL | 负载均衡器入口 IP + 端口 以及externalTrafficPolicy=local | 接受数据包到 Load Balancer externalTrafficPolicy=local |
KUBE-LOAD-BALANCER-FW | 负载均衡器入口 IP + 端口 以及loadBalancerSourceRanges | 使用指定的 loadBalancerSourceRanges 丢弃 Load Balancer 类型 Service 的数据包 |
KUBE-LOAD-BALANCER-SOURCE-CIDR | 负载均衡器入口 IP + 端口 + 源 CIDR | 接受 Load Balancer 类型 Service 的数据包,并指定 loadBalancerSourceRanges |
KUBE-NODE-PORT-TCP | NodePort 类型服务 TCP 端口 | 将数据包伪装成 NodePort(TCP) |
KUBE-NODE-PORT-LOCAL-TCP | NodePort 类型服务 TCP 端口,带有externalTrafficPolicy=local | 接受数据包到 NodePort 服务,使用 externalTrafficPolicy=local |
KUBE-NODE-PORT-UDP | NodePort 类型服务 UDP 端口 | 将数据包伪装成 NodePort(UDP) |
KUBE-NODE-PORT-LOCAL-UDP | NodePort 类型服务 UDP 端口,使用externalTrafficPolicy=local | 接受数据包到 NodePort 服务,使用 externalTrafficPolicy=local |
iptables与ipvs对比
-
iptables
- 工作在内核空间
- 优点:灵活,功能强大(可以在数据包不同阶段对包进行操作)
- 缺点:表中规则过多时,响应变慢,即规则遍历匹配和更新,呈线性时延
-
ipvs
- 工作在内核空间
- 优点:转发效率高;调度算法丰富:rr,wrr,lc,wlc,ip hash...
- 缺点:内核支持不全,低版本内核不能使用,需要升级到4.0或5.0以上。
-
使用iptables与ipvs时机
- 1.10版本之前使用iptables(1.1版本之前使用UserSpace进行转发)
- 1.11版本之后同时支持iptables与ipvs,默认使用ipvs,如果ipvs模块没有加载时,会自动降级至iptables
service类型
Service类型决定了访问Service的方法
- ClusterIP
- 默认,分配一个集群内部可以访问的虚拟IP
- NodePort
- 在每个Node上分配一个端口作为外部访问入口
- nodePort端口范围为:30000-32767
- LoadBalancer
- 工作在特定的Cloud Provider上,例如Google Cloud,AWS,OpenStack
- ExternalName
- 表示把集群外部的服务引入到集群内部中来,即实现了集群内部pod和集群外部的服务进行通信
Service参数
- port 访问service使用的端口
- targetPort Pod中容器端口
- nodePort 通过Node实现外网用户访问k8s集群内service (30000-32767)
Service创建
Service的创建在工作中有两种方式,一是命令行创建,二是通过资源清单文件YAML文件创建。
ClusterIP类型
ClusterIP是集群内部Pod之间的访问方式,ClusterIP根据是否生成ClusterIP又可分为普通Service和Headless Service
普通Service:为Kubernetes的Service分配一个集群内部可访问的固定虚拟IP(Cluster IP),实现集群内的访问。
Headless Service:该服务不会分配Cluster IP,也不通过kube-proxy做反向代理和负载均衡。而是通过DNS提供稳定的网络ID来访问,DNS会将headless service的后端直接解析为pod IP列表。
普通ClusterIP Service创建
命令行创建Service
创建Deployment类型的应用
01_create_deployment_app_nginx.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-server1
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: c1
image: nginx:1.15-alpine
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
# 应用资源清单文件
kubectl apply -f 01_create_deployment_app_nginx.yaml
# 验证Deployment类型的创建情况
kubectl get deployment.apps
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-server1 2/2 2 2 6s
# 通过生成service映射一个Deployment下的所有pod中的某一个端口的容器,kubectl expose deployment Deployment名称 --port=Service端口号 --target-port=Pod内容器端口 --type=ClusterIP --name=service名称,--type默认为ClusterIP,--name默认为Deployment名称
# 创建ClusterIP类型service与Deployment类型应用关联
kubectl expose deployment.apps nginx-server1 --type=ClusterIP --target-port=80 --port=80 --name=nginx-server1
service/nginx-server1 exposed
# 验证,service可以简写程svc
kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 6d15h
nginx-server1 ClusterIP 10.99.200.119 <none> 80/TCP 51s
curl 10.99.200.119
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
....
# 在容器内部可以通过`Service名称.namespace名称.svc`作为域名访问
说明:expose 创建service;deployment.apps 控制器类型;nginx-server1 应用名称,也是service名称;--type=ClusterIP 指定service类型;--target-port=80 指定Pod中容器端口;--port=80 指定service端口
# 删除
kubectl delete -f 01_create_deployment_app_nginx.yaml
kubectl delete service nginx-server1
通过资源清单文件创建Service
02_create_deployment_app_nginx_with_service.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-server1
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx-smart
image: nginx:1.15-alpine
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: nginx-svc
spec:
type: ClusterIP
ports:
- protocol: TCP
port: 80
targetPort: 80
selector:
app: nginx
kubectl apply -f 02_create_deployment_app_nginx_with_service.yaml
# 验证
kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 6d15h
nginx-svc ClusterIP 10.100.156.214 <none> 80/TCP 8s
kubectl get endpoints
NAME ENDPOINTS AGE
kubernetes 192.168.91.220:6443 6d15h
nginx-svc 10.244.30.80:80,10.244.5.40:80 21s
kubectl get pods -l app=nginx
NAME READY STATUS RESTARTS AGE
nginx-server1-7d88ff7db9-hxr2j 1/1 Running 0 67s
nginx-server1-7d88ff7db9-w5kd6 1/1 Running 0 67s
# 访问
curl 10.100.156.214
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
...
# 两个pod里做成不同的主页方便测试负载均衡
kubectl exec -it nginx-server1-7d88ff7db9-hxr2j -- /bin/sh -c "echo web1 > /usr/share/nginx/html/index.html"
kubectl exec -it nginx-server1-7d88ff7db9-w5kd6 -- /bin/sh -c "echo web2 > /usr/share/nginx/html/index.html"
# 测试
curl 10.100.156.214
web1
curl 10.100.156.214
web2
# 删除
kubectl delete -f 02_create_deployment_app_nginx_with_service.yaml
Headless Service
- 普通的ClusterIP service是service name解析为cluster ip,然后cluster ip对应到后面的pod ip
- Headless service是指service name 直接解析为后面的pod ip
创建headless Service
Deployment控制器类型的资源清单文件
03_create_deployment_app_nginx.yml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-server1
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx-smart
image: nginx:1.15-alpine
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
headless Service资源清单文件
04_headless_service.yml
apiVersion: v1
kind: Service
metadata:
name: headless-service
namespace: default
spec:
type: ClusterIP # ClusterIP类型,也是默认类型
clusterIP: None # None就代表是无头service
ports: # 指定service 端口及容器端口
- port: 80 # service ip中的端口
protocol: TCP
targetPort: 80 # pod中的端口
selector: # 指定后端pod标签
app: nginx # 可通过kubectl get pod -l app=nginx查看哪些pod在使用此标签
kubectl apply -f 03_create_deployment_app_nginx.yml
kubectl apply -f 04_headless_service.yml
# 查看已创建的headless Service
# 可以看到headless-service没有CLUSTER-IP,用None表示
kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
headless-service ClusterIP None <none> 80/TCP 3m32s
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 6d17h
DNS
DNS服务监视Kubernetes API,为每一个Service创建DNS记录用于域名解析
headless service需要DNS来解决访问问题
DNS记录格式为: ..svc.cluster.local.
# 查看kube-dns服务的IP,coreDNS的服务地址是10.96.0.10
kubectl get svc -n kube-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP,9153/TCP 6d17h
# 在集群主机通过DNS服务地址查找无头服务的dns解析
yum install -y bind-utils
dig -t A headless-service.default.svc.cluster.local. @10.96.0.10
...
;; QUESTION SECTION:
;headless-service.default.svc.cluster.local. IN A # 被解析的域名
;; ANSWER SECTION: # 注意这里IP
headless-service.default.svc.cluster.local. 30 IN A 10.244.30.83
headless-service.default.svc.cluster.local. 30 IN A 10.244.5.43
;; Query time: 13 msec
;; SERVER: 10.96.0.10#53(10.96.0.10)
;; WHEN: Wed Nov 08 10:42:15 CST 2023
;; MSG SIZE rcvd: 187
# 发现pod对应的ip就是上面解析"headless-service.default.svc.cluster.local."域名,对应的ip
kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-server1-7d88ff7db9-7r7v4 1/1 Running 0 9m11s 10.244.5.43 worker01 <none> <none>
nginx-server1-7d88ff7db9-w28g4 1/1 Running 0 9m11s 10.244.30.83 worker02 <none> <none>
# 进入容器中进行验证
kubectl exec -it nginx-server1-7d88ff7db9-7r7v4 -c nginx-smart -- /bin/sh
nslookup headless-service.default.svc.cluster.local.
Name: headless-service.default.svc.cluster.local.
Address 1: 10.244.30.83 10-244-30-83.headless-service.default.svc.cluster.local
Address 2: 10.244.5.43 nginx-server1-7d88ff7db9-7r7v4
wget -qO- http://headless-service.default.svc.cluster.local.
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
...
# 退出容器
exit
# 删除
kubectl delete -f 04_headless_service.yml
kubectl delete -f 03_create_deployment_app_nginx.yml
NodePort类型
ClusterIP的方式只能在Pod内部实现访问,但是一般需要对外暴露网关,所以需要NodePort的方式Pod外暴露访问
05_create_nodeport_service_app.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-app
labels:
app: nginx-app
spec:
replicas: 2
selector:
matchLabels:
app: nginx-app
template:
metadata:
labels:
app: nginx-app
spec:
containers:
- name: c1
image: nginx:1.15-alpine
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: nginx-app
spec:
type: NodePort
selector:
app: nginx-app
ports:
- protocol: TCP
nodePort: 30001
port: 8060
targetPort: 80
kubectl apply -f 05_create_nodeport_service_app.yaml
kubectl get deployment.apps
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-app 2/2 2 2 7s
kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 6d20h
nginx-app NodePort 10.111.48.203 <none> 8060:30001/TCP 20s
kubectl get endpoints
NAME ENDPOINTS AGE
kubernetes 192.168.91.220:6443 6d20h
nginx-app 10.244.30.87:80,10.244.5.46:80 44s
kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-app-7c4cbbddd9-jspcd 1/1 Running 0 9m25s
nginx-app-7c4cbbddd9-mlmm4 1/1 Running 0 9m25s
kubectl exec -it nginx-app-7c4cbbddd9-jspcd -- /bin/sh -c "echo web1 > /usr/share/nginx/html/index.html"
kubectl exec -it nginx-app-7c4cbbddd9-mlmm4 -- /bin/sh -c "echo web2 > /usr/share/nginx/html/index.html"
# 在与kubernetes 节点同一网络主机中访问k8s集群内service
curl 192.168.91.220:30001
web2
curl 192.168.91.221:30001
web1
curl 192.168.91.222:30001
web1
# 删除
kubectl delete -f 05_create_nodeport_service_app.yaml
LoadBalancer
集群外访问过程
- 用户
- 域名
- 云服务提供商提供LB服务
- NodeIP:Port(service IP)
- Pod IP:端口
自建Kubernetes的LoadBalancer类型服务方案-MetalLB
MetalLB可以为kubernetes集群中的Service提供网络负载均衡功能。
MetalLB两大功能为:
- 地址分配,类似于DHCP
- 外部通告,一旦MetalLB为服务分配了外部IP地址,它就需要使群集之外的网络意识到该IP在群集中“存在”。MetalLB使用标准路由协议来实现此目的:ARP,NDP或BGP。
参考网址: metallb.universe.tf/installatio…
wget https://raw.githubusercontent.com/metallb/metallb/v0.13.12/config/manifests/metallb-native.yaml
kubectl apply -f metallb-native.yaml
准备metallb配置文件
metallb-conf.yaml
---
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
name: first-pool
namespace: metallb-system
spec:
addresses:
- 192.168.91.90-192.168.91.100 # 是集群节点服务器IP同一段
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
name: example
namespace: metallb-system
spec:
ipAddressPools:
- first-pool
kubectl apply -f metallb-conf.yaml
kubectl describe IPAddressPool first-pool -n metallb-system
...
Spec:
Addresses:
192.168.91.90-192.168.91.100
Auto Assign: true
Avoid Buggy I Ps: false
Events: <none>
发布Service类型为LoadBalancer的Deployment控制器类型应用
创建Deployment控制器类型应用nginx-metallb及service,service类型为LoadBalancer
02_nginx-metabllb.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-metallb
spec:
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx-metallb1
image: nginx:1.15-alpine
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: nginx-metallb
spec:
ports:
- port: 8090
protocol: TCP
targetPort: 80
selector:
app: nginx
type: LoadBalancer
kubectl apply -f 02_nginx-metabllb.yaml
# 验证
kubectl get ns
...
metallb-system Active 6m56s
...
kubectl get pods -n metallb-system
NAME READY STATUS RESTARTS AGE
controller-586bfc6b59-c8zfw 1/1 Running 1 (15m ago) 24m
speaker-dd8h7 1/1 Running 1 (15m ago) 24m
speaker-tjqbs 1/1 Running 1 (13m ago) 24m
speaker-xpwr8 1/1 Running 1 (15m ago) 24m
kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 6d21h
nginx-metallb LoadBalancer 10.102.99.105 192.168.91.90 8090:32699/TCP 23m
# 集群内任何节点都可访问
curl 192.168.91.90:8090
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
...
在集群外的浏览器中也能访问,这里是在宿主机的浏览器中可以访问
# 删除
kubectl delete -f 02_nginx-metabllb.yaml
kubectl delete -f metallb-conf.yaml
kubectl delete -f metallb-native.yaml
ExternalName
ExternalName作用
- 把集群外部的服务引入到集群内部中来,实现了集群内部pod和集群外部的服务进行通信
- ExternalName 类型的服务适用于外部服务使用域名的方式,缺点是不能指定端口
- 还有一点要注意: 集群内的Pod会继承Node上的DNS解析规则。所以只要Node可以访问的服务,Pod中也可以访问到, 这就实现了集群内服务访问集群外服务
将公网域名引入
externelname.yml
apiVersion: v1
kind: Service
metadata:
name: my-externalname
namespace: default
spec:
type: ExternalName
externalName: www.baidu.com # 对应的外部域名为www.baidu.com
kubectl apply -f externelname.yml
kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 6d23h
my-externalname ExternalName <none> www.baidu.com <none> 6s
kubectl get svc -n kube-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP,9153/TCP 6d23h
dig -t A my-externalname.default.svc.cluster.local. @10.96.0.10
...
;; ANSWER SECTION:
my-externalname.default.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 14.119.104.189 # 解析的是百度的IP
www.a.shifen.com. 30 IN A 14.119.104.254 # 解析的是百度的IP
...
# 创建一个pod,在容器中验证
kubectl run nginx --image=nginx:1.15-alpine
# 进入容器中操作
kubectl exec -it nginx -- /bin/sh
nslookup www.baidu.com
Name: www.baidu.com
Address 1: 14.119.104.189
Address 2: 14.119.104.254
Address 3: 240e:ff:e020:38:0:ff:b06d:569b
Address 4: 240e:ff:e020:37:0:ff:b08c:124f
# 解析`my-externalname.default.svc.cluster.local`域名和解析`www.baidu.com`是一样的结果
nslookup my-externalname.default.svc.cluster.local
Name: my-externalname.default.svc.cluster.local
Address 1: 14.119.104.254
Address 2: 14.119.104.189
Address 3: 240e:ff:e020:38:0:ff:b06d:569b
Address 4: 240e:ff:e020:37:0:ff:b08c:124f
# 退出容器
exit
# 删除
kubectl delete pod nginx
kubectl delete -f externelname.yml
不同命名空间访问
创建ns1命名空间和相关deploy,pod,service
ns1-nginx.yml
apiVersion: v1
kind: Namespace
metadata:
name: ns1 # 创建ns1命名空间
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: deploy-nginx
namespace: ns1 # 属于ns1命名空间
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.15-alpine
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: svc1 # 服务名
namespace: ns1 # 属于ns1命名空间
spec:
selector:
app: nginx
clusterIP: None # 无头service
ports:
- port: 80
targetPort: 80
---
kind: Service
apiVersion: v1
metadata:
name: external-svc1
namespace: ns1 # 属于ns1命名空间
spec:
type: ExternalName
externalName: svc2.ns2.svc.cluster.local # 将ns2空间的svc2服务引入到ns1命名空间
创建ns2命名空间和相关deploy,pod,service
ns2-nginx.yml
apiVersion: v1
kind: Namespace
metadata:
name: ns2 # 创建ns2命名空间
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: deploy-nginx
namespace: ns2 # 属于ns2命名空间
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.15-alpine
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: svc2 # 服务名
namespace: ns2 # 属于ns2命名空间
spec:
selector:
app: nginx
clusterIP: None # 无头service
ports:
- port: 80
targetPort: 80
---
kind: Service
apiVersion: v1
metadata:
name: external-svc1
namespace: ns2 # 属于ns2命名空间
spec:
type: ExternalName
externalName: svc1.ns1.svc.cluster.local # 将ns1空间的svc1服务引入到ns2命名空间
kubectl apply -f ns1-nginx.yml
kubectl apply -f ns2-nginx.yml
# 在ns1命名空间的pod里验证
kubectl get pods -n ns1 -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
deploy-nginx-79f57dcc-qxx7l 1/1 Running 0 3m25s 10.244.30.98 worker02 <none> <none>
kubectl get pods -n ns2 -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
deploy-nginx-79f57dcc-qdx6z 1/1 Running 0 3m56s 10.244.5.52 worker01 <none> <none>
# 进入容器内部进行操作
kubectl exec -it -n ns1 deploy-nginx-79f57dcc-qxx7l -- /bin/sh
# IP与ns1里的pod IP一致
nslookup svc1
Name: svc1
Address 1: 10.244.30.98 deploy-nginx-79f57dcc-qxx7l
# IP与ns2里的pod IP一致
nslookup svc2.ns2.svc.cluster.local
Name: svc2.ns2.svc.cluster.local
Address 1: 10.244.5.52 10-244-5-52.svc2.ns2.svc.cluster.local
# 退出容器
exit
# 反之,在ns2命名空间的pod里访问'svc1.ns1.svc.cluster.local',解析的IP是ns1命名空间里的pod的IP
验证ns2中的pod的IP变化, ns1中的pod仍然可以使用'svc2.ns2.svc.cluster.local'访问
# 因为有replicas控制器,所以删除pod会自动拉一个起来
kubectl delete pod deploy-nginx-79f57dcc-qdx6z -n ns2
kubectl get pod -o wide -n ns2
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
deploy-nginx-79f57dcc-cj8hd 1/1 Running 0 23s 10.244.30.100 worker02 <none> <none>
# 回到ns1中的pod验证
kubectl exec -it -n ns1 deploy-nginx-79f57dcc-qxx7l -- /bin/sh
# 解析的IP就是ns2中pod的新IP
ping svc2.ns2.svc.cluster.local -c 2
PING svc2.ns2.svc.cluster.local (10.244.30.100): 56 data bytes
64 bytes from 10.244.30.100: seq=0 ttl=63 time=0.048 ms
64 bytes from 10.244.30.100: seq=1 ttl=63 time=0.069 ms
...
# 退出容器
exit
# 删除
kubectl delete -f ns1-nginx.yml
kubectl delete -f ns2-nginx.yml
sessionAffinity
设置sessionAffinity(会话粘贴)为Clientip (类似nginx的ip_hash算法,lvs的sh算法)
02_create_deployment_app_nginx_with_service.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-server1
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: c1
image: nginx:1.15-alpine
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: nginx-svc
spec:
type: ClusterIP
ports:
- protocol: TCP
port: 80
targetPort: 80
selector:
app: nginx
kubectl apply -f 02_create_deployment_app_nginx_with_service.yaml
kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-server1-599b96558c-jtd2c 1/1 Running 0 39s
nginx-server1-599b96558c-kfqpw 1/1 Running 0 39s
kubectl exec -it nginx-server1-599b96558c-jtd2c -- /bin/sh -c "echo web1 > /usr/share/nginx/html/index.html"
kubectl exec -it nginx-server1-599b96558c-kfqpw -- /bin/sh -c "echo web2 > /usr/share/nginx/html/index.html"
kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 7d
nginx-svc ClusterIP 10.110.37.240 <none> 80/TCP 6m13s
# 多次访问分别返回 web2、web2、web1,会均衡到不同的pod中
curl 10.110.37.240
kubectl patch svc nginx-svc -p '{"spec":{"sessionAffinity":"ClientIP"}}'
# 多次访问会一直返回web1或web2,会话粘贴
curl 10.110.37.240
# 设置回sessionAffinity为None
kubectl patch svc nginx-svc -p '{"spec":{"sessionAffinity":"None"}}'
# 多次访问分别返回 web2、web2、web1,会均衡到不同的pod中
curl 10.110.37.240
# 删除
kubectl delete -f 02_create_deployment_app_nginx_with_service.yaml
修改为ipvs调度方式(拓展)
部署方式不同,修改方法不一样。本次主要介绍使用kubeadm部署集群方式,二进制部署较为简单。二进制部署修改:/etc/kubernetes/kube-proxy.yaml文件即可。
从kubernetes1.8版本开始,新增了kube-proxy对ipvs的支持,在kubernetes1.11版本中被纳入了GA
修改为IPVS调度方式前升级内核,现使用Centos7u6发布版本,默认内核版本为3.10.0,可升级内核版本至5.6.0或6.5.9,我这里已经升级过了,可参考"kubernetes部署"
# 查看kube-system的namespace中kube-proxy有关的pod
kubectl get pods -n kube-system | grep kube-proxy
kube-proxy-7xfrl 1/1 Running 9 (64m ago) 7d
kube-proxy-gmfdl 1/1 Running 9 (64m ago) 6d23h
kube-proxy-j9r4q 1/1 Running 9 (64m ago) 6d23h
# 验证kube-proxy-xxx的pod中的信息
kubectl logs kube-proxy-7xfrl -n kube-system
I1108 09:47:31.146234 1 node.go:163] Successfully retrieved node IP: 192.168.91.220
I1108 09:47:31.146448 1 server_others.go:109] "Detected node IP" address="192.168.91.220"
I1108 09:47:31.146472 1 server_others.go:538] "Using iptables proxy" # 使用iptables
I1108 09:47:31.176496 1 server_others.go:178] "Using iptables Proxier"
I1108 09:47:31.176612 1 server_others.go:185] "kube-proxy running in dual-stack mode" ipFamily=IPv4
I1108 09:47:31.176656 1 server_others.go:186] "Creating dualStackProxier for iptables"
...
# 修改kube-proxy的配置文件
kubectl edit configmap kube-proxy -n kube-system
...
ipvs:
excludeCIDRs: null
minSyncPeriod: 0s
scheduler: "" # 可以在这里修改ipvs的算法,默认为rr轮循算法
strictARP: false
syncPeriod: 0s
tcpFinTimeout: 0s
tcpTimeout: 0s
udpTimeout: 0s
kind: KubeProxyConfiguration
metricsBindAddress: ""
mode: "ipvs" # 默认""号里为空,加上ipvs
...
# 重新启动kube-proxy,删除kube-proxy-xxx的所有pod,让它重新拉取新的kube-proxy-xxx的pod
kubectl delete pod kube-proxy-7xfrl -n kube-system
kubectl delete pod kube-proxy-gmfdl -n kube-system
kubectl delete pod kube-proxy-j9r4q -n kube-system
kubectl get pods -n kube-system | grep kube-proxy
kube-proxy-sd98q 1/1 Running 0 22s
kube-proxy-tplcl 1/1 Running 0 24s
kube-proxy-vl45x 1/1 Running 0 24s
kubectl logs kube-proxy-sd98q -n kube-system
I1108 09:43:41.873150 1 node.go:163] Successfully retrieved node IP: 192.168.91.222
I1108 09:43:41.873216 1 server_others.go:109] "Detected node IP" address="192.168.91.222"
I1108 09:43:41.903857 1 server_others.go:250] "Using ipvs Proxier" # 使用ipvs
I1108 09:43:41.903878 1 server_others.go:252] "Creating dualStackProxier for ipvs"
...