kubernetes之Service介绍
Service
Pod IP仅仅是集群内可见的虚拟IP，外部无法访问。
Pod IP会随着Pod的销毁而消失，当ReplicaSet对Pod进行动态伸缩时，Pod IP可能随时随地都会变化，这样对于我们访问这个服务带来了难度。
因此，Kubernetes中的Service对象就是解决以上问题的实现服务发现核心关键。
Service的类型
在Serivce定义时，我们需要指定spec.type字段，这个字段拥有四个选项：
● ClusterIP:默认值。给这个Service分配一个Cluster IP，它是Kubernetes系统自动分配的虚拟IP，因此只能在集群内部访问。
● NodePort:将Service通过指定的Node上的端口暴露给外部。通过此方法，访问任意一个NodeIP:nodePort都将路由到ClusterIP，从而成功获得该服务。
● LoadBalancer:在 NodePort 的基础上，借助 cloud provider 创建一个外部的负载均衡器，并将请求转发到 :NodePort。此模式只能在云服务器（AWS等）上使用。
● ExternalName:将服务通过 DNS CNAME 记录方式转发到指定的域名（通过 spec.externlName 设定）。需要 kube-dns 版本在 1.7 以上。
Service的代理
● userspace 代理模式
● iptables 代理模式
● ipvs 代理模式：
这种模式，kube-proxy 会监视 Kubernetes Service 对象和 Endpoints ，调用 netlink 接口以相应地创建 ipvs 规则并定期与 Kubernetes Service 对象和Endpoints 对象同步 ipvs 规则，以确保 ipvs 状态与期望一 致。访问服务时，流量将被重定向到其中一个后端 Pod 。与 iptables 类似，ipvs 于 netfilter 的 hook 功能，但使用哈希表作为底层数据结构并在内核空间中工作。这意 味着 ipvs 可以更快地重定向流量，并且在同步代理规则时具有更好的性能。此外，ipvs 为负载均衡算法提供了更多选项，例如：
rr ：轮询调度
lc ：最小连接数
dh ：目标哈希
sh ：源哈希
sed ：最短期望延迟
nq ： 不排队调度
ClusterIp
NodePort
Ingress
组成
ingress controller
将新加入的Ingress转化成Nginx的配置文件并使之生效
ingress服务
将Nginx的配置抽象成一个Ingress对象，每添加一个新的服务只需写一个新的Ingress的yaml文件即可
工作原理
1.ingress controller通过和kubernetes api交互，动态的去感知集群中ingress规则变化，
2.然后读取它，按照自定义的规则，规则就是写明了哪个域名对应哪个service，生成一段nginx配置，
3.再写到nginx-ingress-control的pod里，这个Ingress controller的pod里运行着一个Nginx服务，控制器会把生成的nginx配置写入/etc/nginx.conf文件中，
4.然后reload一下使配置生效。以此达到域名分配置和动态更新的问题。
测试部署
官网:https://kubernetes.github.io/ingress-nginx/deploy/#quick-start
github:https://github.com/kubernetes/ingress-nginx/tree/nginx-0.30.0/deploy
$ wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/mandatory.yaml
$ wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/provider/baremetal/service-nodeport.yaml
$ ll
总用量 12
-rw-r--r-- 1 root root 6637 9月 16 23:46 mandatory.yaml
-rw-r--r-- 1 root root 471 9月 16 23:36 service-nodeport.yaml
#修改mandatory.yaml修改kind为daemonset,ingress-controller镜像地址修改为阿里云地址,添加imagePullPolicy策略，并指定hostPort,将宿主机的80、443映射到容器的80与443
........
apiVersion: apps/v1
kind: DaemonSet
.............
spec:
#replicas: 1
........
- name: nginx-ingress-controller
image: registry.aliyuncs.com/google_containers/nginx-ingress-controller:0.30.0
imagePullPolicy: IfNotPresent
........
ports:
- name: http
containerPort: 80
protocol: TCP
hostPort: 80
- name: https
containerPort: 443
protocol: TCP
hostPort: 443
............
$ cat nginx-deployment.yaml
apiVersion: v1
kind: Service
metadata:
name: nginx-service
labels:
app: nginx-service
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app: nginx
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx-deployment
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: registry.sudytech.com:35000/library/nginx:1.15.9
ports:
- containerPort: 80
#创建ingress服务
$ cat ingress.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: ingress
spec:
rules:
- host: www.aaa.com
http:
paths:
- backend:
serviceName: nginx-service
servicePort: 80
path: /
#serviceName对应nginx-deployment.yaml文件中Service的标签
#做本地测试即可
https部署测试
#自签发证书，可以使用下面的语句，也可以阅读自制https的博客
$ openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/O=aaa/CN=*.aaa.com"
$ ll
总用量 8
-rw-r--r-- 1 root root 1131 9月 19 16:30 tls.crt
-rw-r--r-- 1 root root 1704 9月 19 16:30 tls.key
#导入证书文件到k8s secret（注意这边的nginx-test要和下面ingress.yaml文件中tls相对应）
$ kubectl create secret tls nginx-test --cert=tls.crt --key=tls.key
$ kubectl get secret
NAME TYPE DATA AGE
nginx-test kubernetes.io/tls 2 53m
#创建https的ingrss.yaml文件
$ cat ingress.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: ingress
annotations:
nginx.ingress.kubernetes.io/ssl-redirect: "false" #是否开启强制跳转,true/false,默认开启
spec:
tls:
- hosts:
- www.aaa.com
secretName: nginx-test
#- hosts: 多域名配置
# - www.bbb.com
# secretName: nginx-bbb
rules:
- host: www.aaa.com
http:
paths:
- backend:
serviceName: nginx-service
servicePort: 80
path: /
# - host: www.bbb.com
# http:
# paths:
# - backend:
# serviceName: nginx-service
# servicePort: 80
# path: /
访问原理
Ingress-nginx与Service之间通过匹配serviceName绑定
Service相当于给外界提供访问pod的端口，如果不采用ingress-nginx，那么是由kube-proxy实现4层代理，只能通过ip访问，所以由NodePort的类型将端口暴露。如果采用ingress-nginx相当于在Service前面加了一层代理，访问会先经过ingress-nginx,这样Service的类型就不需要变更为NodePort,
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 | 定义控制器在/上下文中必须重定向的应用程序根 |
串 |
| nginx.ingress.kubernetes.io/use-regex | 指示在 Ingress 上定义的路径是否使用正则表达式 | 布尔 |
 |
Pod与Service关联
两者之间通过标签关联,spec.template.metadata.labels为pod打上名为mediaplus-main的标签，Service的spec.selector需要与spec.template.metadata.labels值一致
apiVersion: v1
kind: Service
metadata:
name: mediaplus-main
labels:
app: mediaplus-main
spec:
..............
selector:
app: mediaplus-main
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: mediaplus-main
spec:
replicas: 1
selector:
matchLabels:
app: mediaplus-main
template:
metadata:
labels:
app: mediaplus-main
spec:
containers:
- name: mediaplus-main
Service与Ingress关联
Service只能实现四层代理 传输层，基于IP和端口
Ingress可以实现七层代理 应用层，基于应用协议转发，例如http协议
Ingress与Service之间通过匹配serviceName绑定，metadata.labels为Service打上mediaplus-main的标签，spec.rules.backend.serviceName的值需要与mediaplus-main保持一致
apiVersion: v1
kind: Service
metadata:
name: mediaplus-main
labels:
app: mediaplus-main
spec:
..............
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: name-virtual-host-ingress
spec:
tls:
- secretName: sign-secret
rules:
.........
- backend:
serviceName: mediaplus-main
servicePort: 3000
path: /