k8s-service-ingress

service

service存在的意义

1 防止pod失去联系(服务发现)

2 定义一组pod的访问策略(负载均衡)

通过label-selector相关联(标签关联)

通过service实现pod的负载均衡(tcp/UDP/只能支持4层)

service只支持4层负载均衡

4层: OSI中的传输层, TCP/UDP协议只负责数据包的转发

7层: OSI中的应用层 http fTP 可以拿到这些协议头部信息可以实现基于协议层面的处理

service的三种常用的类型

ClusterIP 集群内部使用

clusterIP 默认分配一个稳定的IP 即VIP 只能在集群内部访问 (同Namespace内的pod)

NOdePort 对外部暴露应用

NoPort访问流程

[ USER > 域名 > node ip+port > iptables/ipvs > pod]

LoadBalancer 对外暴露应用适合公有云

LoadBalancer访问流程

[user > 域名 > 公有云的slb (自动配置端口) > node:ip:port > pod]

userspace 自己用户实现的转发

iptables 阻止ip通信端口映射跟踪包状态数据包的修改

ipvs LVS 就是基于ipvs模块做的4层负载均衡器

kube-proxy

1:实现数据包的转发

2:将service相关的规则落地现实

iptables规则：

Nodeport -> KUBE-SVC-RRHDV4CFXHW7RWV3 -> KUBE-SEP-XE5XFBDN7LLHNVMO -> -j DNAT --to-destination 10.244.2.2:80

clusterip -> KUBE-SVC-RRHDV4CFXHW7RWV3 -> KUBE-SEP-XE5XFBDN7LLHNVMO -> -j DNAT --to-destination 10.244.2.2:80

-A KUBE-SVC-RRHDV4CFXHW7RWV3 -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-BGV4R4Y32WAZO4AD

-A KUBE-SVC-RRHDV4CFXHW7RWV3 -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-XE5XFBDN7LLHNVMO

-A KUBE-SVC-RRHDV4CFXHW7RWV3 -j KUBE-SEP-CYUFO3BNAYR2R5O3

上面是转发到3个pod规则。

轮训

ip_vs启动

lsmod|grep ip_vs 查看ip_vs是否启动

modprobe ip_v 启动ipvs

启动模块 ip_vs

modprobe ip_vs

modprobe ip_vs_rr

modprobe ip_vs_wrr

modprobe ip_vs_sh

modprobe nf_conntrack_ipv4

在每一个机器上面执行一遍把这些启动的模块加入到 [etc/rc.local]里面开机启动

通过 kubectl get cm -n kube-system 查看kube-porxy

通过 kubectl edit cm kube-porxy -n kube-system 修改启动ipvs mode"ipvs"

lvs 虚拟服务器真实服务器

TCP 10.96.0.1:443 rr

-> 192.168.195.110:6443 Masq 1 0 0

TCP 10.96.0.10:53 rr

-> 10.244.1.6:53 Masq 1 0 0

-> 10.244.1.7:53 Masq 1 0 0

TCP 10.96.0.10:9153 rr

-> 10.244.1.6:9153 Masq 1 0 0

-> 10.244.1.7:9153 Masq 1 0 0

UDP 10.96.0.10:53 rr

-> 10.244.1.6:53 Masq 1 0 0

-> 10.244.1.7:53 Masq 1 0

ipvs 通过虚拟的vip 流量首先会到ipvs的虚拟服务器在通过虚拟服务器转发给真实服务器

通过 yum install ipvsadm -y 安装ipvs的用户端看见当前状态和转发规则

iptables

灵活强大规则遍历匹配和更新慢呈线性时延

ipvs

工作在内核有更好的性能

调度算法丰富 rr wrr lc wlc ip hash

ipvs 在部署 pod多的时候客园切换因为调度快规则匹配少

有ipvs以后iptables的规则不要清空因为 ipvs还是需要通过iptables转发流量到ipvs

service DNS

程序比写死ip更好的方式

1. dns解析

2. 绑定hosts

coreDNS pod -> 获取server (apiserver 获取) -> 更新到本地

kubelet 运行pod > pod 默认走> coreDNS pod >

[1. 采用Nodeport 对外暴露应用前面加一个LB实现统一访问入口]

[2. 优秀使用IPVS 代理模式]

[3. 集群内部采用dns名称访问]、

web.default.svc.cluster.local 名称.命名空间.svc.默认域

ingress

[nodeporet存在的不足

一个端口只能一个服务去使用端口需要提前规划

只支持4层负载均衡]

pod与ingress的关系

[通过 service相联

通过ingress Controll现实pod的负载均衡

支持tcp/udp4层和http7层]

ingress访问流程

user > 域名 >

node: ip:80/443 > ingress controller > 域名分流 > pod

ingress

基于URL路由到多个服务类式nginx的反向代理

[apiVersion: networking.k8s.io/v1beta1

kind: Ingress

metadata:

annotations:

nginx.ingress.kubernetes.io/rewrite-target: /

spec:

rules:

- host: foobar.ctnrs.com

http:

paths:

- path: /foo

backend:

serviceName: service1

servicePort: 80

- host: foobar.ctnrs.com

http:

paths:

- path: /bar

backend:

serviceName: service2

servicePort: 80]

ingress 基于虚拟机主机

配置两个域名主机就可以了

[apiVersion: networking.k8s.io/v1beta1

kind: Ingress

metadata:

spec:

rules:

- host: foo.ctnrs.com

http:

paths:

- backend:

serviceName: service1

servicePort: 80

- host: bar.ctnrs.com

http:

paths:

- backend:

serviceName: service2

servicePort: 80]

Annotations对Ingress个性化配置

+超时时间

[apiVersion: networking.k8s.io/v1beta1

kind: Ingress

metadata:

annotations:

kubernetes.io/ingress.class: "nginx“

nginx.ingress.kubernetes.io/proxy-connect-timeout: "600"

nginx.ingress.kubernetes.io/proxy-send-timeout: "600"

nginx.ingress.kubernetes.io/proxy-read-timeout: "600"

nginx.ingress.kubernetes.io/proxy-body-size: "10m"

spec:

rules:

- host: example.ctnrs.com

http:

paths:

- path: /

backend:

serviceName: web

servicePort: 80]

ingress controller pod -> 获取service（apiserver）-> 应用到本地nginx

1、控制器获取service关联的pod应用到nginx

2、nginx 提供七层负载均衡

ingress controller 高可用方案

1. 使用 Daemonset+nodeselector

固定ingress到两个nodes上

访问逻辑

user > 域名解析到 > vip (keepalived) ha功能 > pod

固定ingress到N个nodes上因并发定

user > 域名 > LB (nginx lvs haproxy) > ingress controller > pod

360 调度流程

lvs(定制开发的lvs控制器对接lvs的api) > pod

应用程序管理配置

secret

加密数据并存放在ETCD中让pod容器以挂载volume的方式去访问

应用场景凭据

pod使用 secret的两种方式

变量注入

挂载

secret的应用场景

1. ingress https证书

2. secret 存放docker registry认证信息

3. 存放文件内容或者是字符串

configmap 主要是使用文件传入和secret的使用场景不一样

[参数

docker-registry 创建一个给 Docker registry 使用的 secret

generic 从本地 file, directory 或者 literal value 创建一个 secret

tls 创建一个 TLS secret

用法

kubectl create secret [flags] [options]]

---

用户名密码这些必须通过base64转过因为这样子比较安全

echo -n 'admin' | base64

---

创建一个secret

apiVersion: v1

kind: Secret

metadata:

type: Opaque

data:

username: YWRtaW4=

password: MWYyZDFlMmU2N2Rm

----

引入secret变量

[apiVersion: v1

kind: Pod

metadata:

spec:

containers:

- name: nginx

image: nginx

env:

- name: secret_user

valueFrom:

secretKeyRef:

key: username

- name: secret_passwd

valueFrom:

secretKeyRef:

key: password]

-------------------------------------

secret通过挂载的方式

apiVersion: v1

kind: Pod

metadata:

spec:

containers:

- name: nginx

image: nginx

volumeMounts:

- name: foo

mountPath: "/etc/foo"

readOnly: true

volumes:

- name: foo

secret:

secretName: mysecret

----------------------------

应用程序如何动态更新配置

1. 重新构建pod

2. 应用程序本身实现监听本地配置文件如果发生变化触发配置热更新

3. 使用 sidecal容器是否触发更新如果发生变化触发 socket http 通知应用程序热更新

采用配置中心的例如 nacos apollo

------------------------------