k8s---对外服务 ingress

目录

ingress与service

ingress的组成

ingress-controller：

ingress暴露服务的方式

2.方式二：DaemonSet+hostnetwork+nodeSelector

DaemonSet+hostnetwork+nodeSelector如何实现

3.deployment+NodePort：

虚拟主机的方式实现http代理

总结

deploymentit+loadbalancer：

daemonset+hostnetwork+nodeselector：

deployment+nodeport：

ingress与service

service作用体现在两个方面：

1.集群内部：不断跟踪pod的变化，更新endpoint中的pod对象，基于pod的IP地址不断变化的一种服务发现机制。

2.集群外部：类似负载均衡，把流量IP+端口，不涉及转发url（http https），把请求转发到pod当中。

service：

nodeport：容器端口---service端口---nodeport，每个节点都会有一个端口被打开（30000-32767）

IP+端口：节点IP+30000-32767实现负载均衡

loadbalancer：云平台上的一种service服务。云平台提高负载均衡的IP地址。

externalname：域名映射。

通过ingress基于域名映射，把url（http,https）请求转发到service，再由service把请求转发到每一个pod。

ingress只要一个或者是少量的公网IP或者LB，可以把多个http请求暴露到外网，七层反向代理。

ingress是service的service，是一组基于域名和URL路径，把一个或者多个请求（基于域名和URL的请求）转发到service的一种规则。

先是七层代理（ingress）----四层代理（service）---pod（nginx）

ingress的组成

ingress是一个api对象，通过yaml文件来进行配置。

ingress的作用-->定义请求如何转发到service的规则。

ingress通过http和https暴露集群内部的service，给service提供一个外部的url，负载均衡，ssl/tls（https）的能力，实现一个基于域名的负载均衡。

ingress-controller：

具体的实现反向代理和负载均衡的程序。对ingress定义的规则进行解析，根据ingress的配置规则进行请求的转发。

ingress-controller不是K8s自带的组件功能，ingress-controller一个统称。

nginx ingress controller traefik都是ingress-controller，开源。

ingress暴露服务的方式

1.deployment+LoadBalancer模式，ingress部署在公有云。会ingress配置文件里面会有一个type，type：loadbalancer。

公有云平台会为这个loadbalancer的service创建一个负载均衡器。绑定一个公网地址。

通过域名指向这个公网地址就可以实现集群对外暴露。

2.方式二：DaemonSet+hostnetwork+nodeSelector

DaemonSet：在每个节点都会创建一个pod。

hostnetwork：pod共享节点主机的网络命名空间。容器内直接使用节点主机的IP+端口。pod中的容器可以直接访问主机上的网络资源。

nodeSelector：根据标签来选择部署的节点。nginx-ingress-controller部署的节点。

缺点：直接利用节点主机的网络和端口，一个node只能部署一个controller的pod。比较适合大并发的生产环境。性能是最好的。

解析出来的域名到ingress-controller，再到Ingress的配置，根据标签service匹配来对容器进行发现和监控。controller实现请求转发和负载均衡。

ingress-controller的安装

wget https://gitee.com/mirrors/ingress-nginx/raw/nginx-0.30.0/deploy/static/mandatory.yaml

DaemonSet+hostnetwork+nodeSelector如何实现

查看端口，只有node02有

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc
spec:
  accessModes:
    - ReadWriteMany:
  storageClassName: nfs-client-storageclass
  resources:
    request:
      storage: 2Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-app
  labels:
    app: nginx1
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx1
  template:
    metadata:
      labels:
        app: nginx1
    spec:
      containers:
        - name: nginx
          image: nginx:1.22
          volumeMounts:
          - name: nfs-pvc
            mountPath: /usr/share/nginx/html
      volumes:
      - name: nfs-pvc
        persistentVolumeClaim:
          claimName: nfs-pvc
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-app-svc
spec:
  ports:
  - protocol: Tcp
    port: 80
    targetPort: 80
  selector:
    app: nginx1
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-app-ingress
spec:
  rules:
  - host: www.test1.com
    http:
      path: /
      pathType: Prefix
#根据前缀进行匹配。以/为开头都能匹配

3.deployment+NodePort：

host--->ingress的配置找到Pod--->controller--->请求发到pod

nodeport---controller---ingress---service---pod

nodeport暴露端口的方式是最简单的方法，nodeport 多了一层nat（地址转换），并发量大的对性能会有一定影响。内部都会用nodeport

apiVersion: v1
kind: Service
metadata:
  name: ingress-nginx
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
spec:
  type: NodePort
  ports:
    - name: http
      port: 80
      targetPort: 80
      protocol: TCP
    - name: https
      port: 443
      targetPort: 443
      protocol: TCP
  selector:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---
现在执行这个yaml文件，会生成一个service，在ingress-nginx这个命名空间生成一个service，所有的controller的请求都会从这个定义的service的nodeport的端口，把请求转发到自定义的service的Pod

ingress--nodeport的端口---service---pod

入口：nodeport不再是创建pod的deployment传附件的，是ingress的service创建的

数据流向图

虚拟主机的方式实现http代理

通过ingress的方式实现：一个ingress可以访问不同的主机

vim pod1.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment1
  labels:
    test: nginx1
spec:
  replicas: 1
  selector:
    matchLabels:
      test: nginx1
  template:
    metadata:
      labels:
        test: nginx1
    spec:
      containers:
        - name: nginx1
          image: nginx:1.22
---
apiVersion: v1
kind: Service
metadata:
  name: svc-1
spec: 
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
  selector:
    test: nginx1

kubectl apply -f pod1.yaml




vim pod2.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment2
  labels:
    test: nginx2
spec:
  replicas: 1
  selector:
    matchLabels:
      test: nginx2
  template:
    metadata:
      labels:
        test: nginx2
    spec:
      containers:
        - name: nginx1
          image: nginx:1.22
---
apiVersion: v1
kind: Service
metadata:
  name: svc-2
spec: 
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
  selector:
    test: nginx2
wq

kubectl apply -f pod2.yaml








vim pod-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress1
spec:
  rules:
    - host: www.test.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: svc-1
            port:
              number:80
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress2
spec:
  rules:
    - host: www.test2.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: svc-2
            port:
              number:80
              
              
wq
kubectl apply -f pod-ingress.yaml

vim /etc/hosts

curl www.


wq