kubectl get all -A   查看全部名称空间的pod，找控制器下的pod

负载均衡是什么?

负载均衡是由多台服务器以对称的方式组成一个服务器集合，每台服务器都具有等价的地位，都可以 单独对外提供服务而无需其他服务器的辅助。通过某种负载分担技术，将外部发送来的请求按照某种策略 分配到服务器集合的某一台服务器上，而接收到请求的服务器独立地回应客户的请求。负载均衡解决了大 量并发访问服务问题，其目的就是用最少的投资获得接近于大型主机的性能。

四层负载均衡:lvs(软件层面)、f5(硬件层面)

缺点:对网络依赖较大，负载智能化方面没有 7 层负载好(比如不支持对 url 个性化负载)，F5 硬件 性能很高但成本也高，需要人民币几十万，对于小公司就望而却步了。

常见的七层负载均衡:nginx、apache

优点:对网络依赖少，负载智能方案多(比如可根据不同的 url 进行负载)

在 k8s 中为什么要做负载均衡?

Pod 漂移问题

Kubernetes 具有强大的副本控制能力，能保证在任意副本(Pod)挂掉时自动从其他机器启动一个新的，还可以动态扩容等。通俗地说，这个 Pod 可能在任何时刻出现在任何节点上，也可能在任何时刻 死在任何节点上;那么自然随着 Pod 的创建和销毁，Pod IP 肯定会动态变化;那么如何把这个动态的 Pod IP 暴露出去?这里借助于 Kubernetes 的 Service 机制，Service 可以以标签的形式选定一组带 有指定标签的 Pod，并监控和自动负载他们的 Pod IP，那么我们向外暴露只暴露 Service IP 就行了;这 就是 NodePort 模式:即在每个节点上开起一个端口，然后转发到内部 Pod IP 上。

使用 service 做四层负载均衡

在 kubernetes 中，Pod 是有生命周期的，如果 Pod 重启 IP 很有可能会发生变化。如果我们的服 务都是将 Pod 的 IP 地址写死，Pod 的挂掉或者重启，和刚才重启的 pod 相关联的其他服务将会找不到 它所关联的 Pod，为了解决这个问题，在 kubernetes 中定义了 service 资源对象，Service 定义了一 个服务访问的入口，客户端通过这个入口即可访问服务背后的应用集群实例，service 是一组 Pod 的逻 辑集合，这一组 Pod 能够被 Service 访问到，通常是通过 Label Selector 实现的。

通过 Service 访问 k8s 内部应用的时候数据包走向是什么样？

此时的数据包流向如下:

客户端请求-->node 节点的 ip:端口--->service 的 ip:端口--->pod 的 ip:端口 案例演示:

cat pod_test.yaml

apiVersion: apps/v1

kind:  Deployment

metadata:

  name: my-nginx

spec:

  selector:

    matchLabels:

      run: my-nginx

  replicas: 2

  template:

    metadata:

      labels:

        run: my-nginx

    spec:

      containers:

      - image: nginx

        name: my-nginx

        ports:

        - containerPort: 80  #pod容器中暴露的端口

vim service.yaml

apiVersion: v1

kind: Service

metadata:

  name: my-nginx

  labels:

    run: my-nginx

spec:

  ports:

  - port: 80

    protocol: TCP

  selector:

    run: my-nginx

在 k8s 为什么要引入七层负载均衡?

端口管理问题采用 service 的 NodePort 方式暴露服务面临的问题是，服务一旦多起来，NodePort 在每个节点 上开启的端口会及其庞大，而且难以维护。

四层负载均衡和七层负载均衡对比分析

1)四层的负载均衡就是基于 IP+端口的负载均衡:在三层负载均衡的基础上，通过发布三层的 IP 地 址(VIP)，然后加四层的端口号，来决定哪些流量需要做负载均衡，对需要处理的流量进行 NAT 处理， 转发至后台服务器，并记录下这个 TCP 或者 UDP 的流量是由哪台服务器处理的，后续这个连接的所有流 量都同样转发到同一台服务器处理。

2)七层的负载均衡就是基于虚拟的 URL 或主机 IP 的负载均衡:在四层负载均衡的基础上(没有四 层是绝对不可能有七层的)，再考虑应用层的特征，比如同一个 Web 服务器的负载均衡，除了根据 VIP 加 80 端口辨别是否需要处理的流量，还可根据七层的 URL、浏览器类别、语言来决定是否要进行负载均 衡。举个例子，如果你的 Web 服务器分成两组，一组是中文语言的，一组是英文语言的，那么七层负载 均衡就可以当用户来访问你的域名时，自动辨别用户语言，然后选择对应的语言服务器组进行负载均衡处 理。

 Ingress 和 Ingress Controller 解读

Ingress 官网定义:Ingress 可以把进入到集群内部的请求转发到集群中的一些服务上，从而可以把 服务映射到集群外部。Ingress 能把集群内 Service 配置成外网能够访问的 URL，流量负载均衡，提供 基于域名访问的虚拟主机等。

Ingress 简单的理解就是你原来需要改 Nginx 配置，然后配置各种域名对应哪个 Service，现在把 这个动作抽象出来，变成一个 Ingress 对象，你可以用 yaml 创建，每次不要去改 Nginx 了，直接改 yaml 然后创建/更新就行了;那么问题来了:”Nginx 该怎么处理?”

Ingress Controller 这东西就是解决 “Nginx 的处理方式” 的;Ingress Controller 通过与 Kubernetes API 交互，动态的去感知集群中 Ingress 规则变化，然后读取他，按照他自己模板生成一 段 Nginx 配置，再写到 Ingress Controller Nginx 里，最后 reload 一下，工作流程如下图:

实际上 Ingress 也是 Kubernetes API 的标准资源类型之一，它其实就是一组基于 DNS 名称 (host)或 URL 路径把请求转发到指定的 Service 资源的规则。用于将集群外部的请求流量转发到集群 内部完成的服务发布。我们需要明白的是，Ingress 资源自身不能进行“流量穿透”，仅仅是一组规则的集 合，这些集合规则还需要其他功能的辅助，比如监听某套接字，然后根据这些规则的匹配进行路由转发， 这些能够为 Ingress 资源监听套接字并将流量转发的组件就是 Ingress Controller。

注:Ingress 控制器不同于 Deployment 控制器的是，Ingress 控制器不直接运行为 kube- controller-manager 的一部分，它仅仅是 Kubernetes 集群的一个附件，类似于 CoreDNS，需要 在集群上单独部署。

Ingress Controller 介绍

Ingress Controller 是一个七层负载均衡调度器，客户端的请求先到达这个七层负载均衡调度器，

由七层负载均衡器在反向代理到后端 pod，常见的七层负载均衡器有 nginx、traefik，以我们熟悉的 nginx 为例，假如请求到达 nginx，会通过 upstream 反向代理到后端 pod 应用，但是后端 pod 的 ip 地址是一直在变化的，因此在后端 pod 前需要加一个 service，这个 service 只是起到分组的作用，那 么我们 upstream 只需要填写 service 地址即可

Ingress 和 Ingress Controller 总结

Ingress Controller

Ingress Controller 

可以理解为控制器，它通过不断的跟 Kubernetes API 交互，实时获取后端Service、Pod 的变化，比如新增、删除等，结合 Ingress 定义的规则生成配置，然后动态更新上边的 Nginx 或者 trafik 负载均衡器，并刷新使配置生效，来达到服务自动发现的作用。

Ingress 则是定义规则，通过它定义某个域名的请求过来之后转发到集群中指定的 Service。它可 以通过 Yaml 文件定义，可以给一个或多个 Service 定义一个或多个 Ingress 规则。

使用 Ingress Controller 代理 k8s 内部应用的流程

(1)部署 Ingress controller，我们 ingress controller 使用的是 nginx

(2)创建 Pod 应用，可以通过控制器创建 pod

(3)创建 Service，用来分组 pod

(4)创建 Ingress http，测试通过 http 访问应用

(5)创建 Ingress https，测试通过 https 访问应用

客户端通过七层调度器访问后端 pod 的方式

使用七层负载均衡调度器 

ingress controller 时，当客户端访问 kubernetes 集群内部的应用时， 数据包走向如下图流程所示:

安装 Nginx Ingress Controller

#把 defaultbackend.tar.gz 和 nginx-ingress-controller.tar.gz 镜像上传到工作节点

cat default-backend.yaml

apiVersion: apps/v1

kind: Deployment

metadata:

  name: default-http-backend

  labels:

    k8s-app: default-http-backend

  namespace: kube-system

spec:

  replicas: 1

  selector:

  matchLabels:

    k8s-app: default-http-backend

  template:

    metadata:

      labels:

        k8s-app: default-http-backend

    spec:

      terminationGracePeriodSeconds: 60

      containers:

      - name: default-http-backend

        # Any image is permissable as long as:

        # 1. It serves a 404 page at /

        # 2. It serves 200 on a /healthz endpoint

        image: registry.cn-hangzhou.aliyuncs.com/hachikou/defaultbackend:1.0

        livenessProbe:

          httpGet:

            path: /healthz  #这个URI是 nginx-ingress-controller中nginx里配置好的localtion

            port: 8080

            scheme: HTTP

          initialDelaySeconds: 30  #30s检测一次/healthz

          timeoutSeconds: 5

        ports:

        - containerPort: 8080

#        resources:

#          limits:

#            cpu: 10m

#            memory: 20Mi

#          requests:

#            cpu: 10m

#            memory: 20Mi

      nodeName: god62

---

apiVersion: v1

kind: Service    #为default backend 创建一个service

metadata:

  name: default-http-backend

  namespace: kube-system

  labels:

    k8s-app: default-http-backend

spec:

  ports:

  - port: 80

    targetPort: 8080

  selector:

    k8s-app: default-http-backend

cat nginx-ingress-controller.yaml

apiVersion: apps/v1

kind: Deployment

metadata:

  name: nginx-ingress-controller

  labels:

    k8s-app: nginx-ingress-controller

  namespace: kube-system

spec:

  replicas: 1

  selector:

    matchLabels:

      k8s-app: nginx-ingress-controller

  template:

    metadata:

      labels:

        k8s-app: nginx-ingress-controller

    spec:

      # hostNetwork makes it possible to use ipv6 and to preserve the source IP correctly regardless of docker configuration

      # however, it is not a hard dependency of the nginx-ingress-controller itself and it may cause issues if port 10254 already is taken on the host

      # that said, since hostPort is broken on CNI (https://github.com/kubernetes/kubernetes/issues/31307) we have to use hostNetwork where CNI is used

      # like with kubeadm

      # hostNetwork: true #注释表示不使用宿主机的80口，

      terminationGracePeriodSeconds: 60

      hostNetwork: true  #表示容器使用和宿主机一样的网络

      serviceAccountName: nginx-ingress-serviceaccount #引用前面创建的serviceacount

      containers: 

      - image: registry.cn-hangzhou.aliyuncs.com/peter1009/nginx-ingress-controller:0.20.0      #容器使用的镜像

        name: nginx-ingress-controller  #容器名

        readinessProbe:  #启动这个服务时要验证/healthz 端口10254会在运行的node上监听。

          httpGet:                  #就绪型探测

            path: /healthz

            port: 10254

            scheme: HTTP

        livenessProbe:       #存活性探测

          httpGet:

            path: /healthz

            port: 10254

            scheme: HTTP

          initialDelaySeconds: 10  #每隔10做健康检查

          timeoutSeconds: 1

        ports:

        - containerPort: 80 

          hostPort: 80    #80映射到80

#        - containerPort: 443

#          hostPort: 443

        env:

          - name: POD_NAME

            valueFrom:

              fieldRef:

                fieldPath: metadata.name

          - name: POD_NAMESPACE

            valueFrom:

              fieldRef:

                fieldPath: metadata.namespace

        args:

        - /nginx-ingress-controller

        - --default-backend-service=$(POD_NAMESPACE)/default-http-backend

#        - --default-ssl-certificate=$(POD_NAMESPACE)/ingress-secret    #这是启用Https时用的

#      nodeSelector:  #指明运行在哪，此IP要和default backend是同一个IP

#        kubernetes.io/hostname: 10.3.1.17  #上面映射到了hostport80，确保此IP80，443没有占用.

#

      nodeName: god62

cat   nginx-ingress-controller-rbac.yml

#apiVersion: v1

#kind: Namespace

#metadata:  #这里是创建一个namespace，因为此namespace早有了就不用再创建了

#  name: kube-system

---

apiVersion: v1

kind: ServiceAccount

metadata:

  name: nginx-ingress-serviceaccount #创建一个serveerAcount

  namespace: kube-system

---

apiVersion: rbac.authorization.k8s.io/v1beta1

kind: ClusterRole

metadata:

  name: nginx-ingress-clusterrole  #这个ServiceAcount所绑定的集群角色

rules:

  - apiGroups:

      - ""

    resources:    #此集群角色的权限，它能操作的API资源

      - configmaps

      - endpoints

      - nodes

      - pods

      - secrets

    verbs:

      - list

      - watch

  - apiGroups:

      - ""

    resources:

      - nodes

    verbs:

      - get

  - apiGroups:

      - ""

    resources:

      - services

    verbs:

      - get

      - list

      - watch

  - apiGroups:

      - "extensions"

    resources:

      - ingresses

    verbs:

      - get

      - list

      - watch

  - apiGroups:

      - ""

    resources:

        - events

    verbs:

        - create

#更新 yaml 文件，

kubectl apply -f nginx-ingress-controller-rbac.yml

kubectl apply -f default-backend.yaml

kubectl apply -f nginx-ingress-controller.yaml

安装 Ingress conrtroller 需要的 yaml 

所在的 github 地址: https://github.com/kubernetes/ingress-nginx/

https://github.com/kubernetes/ingress/tree/master/examples/deployment

#查看是否部署成功
kubectl get pods -n kube-system | grep ingress

nginx-ingress-controller-657d9c6d5f-2qwzw 1/1 Running 0 4m30s

default-backend.yaml 和 nginx-ingress-controller.yaml 文件指定了 nodeName: god62，表示 default 和 nginx-ingress-controller 部署在 god62 节点，大家的 node 节点 如果主机名不是 god62，需要自行修改成自己的主机名，这样才会调度成功，一定要让 default- http-backend 和 nginx-ingress-controller 这两个 pod 在一个节点上。

default-backend.yaml:这是官方要求必须要给的默认后端，提供 404 页面的。它还提供了一个 http 检测功能，检测 nginx-ingress-controll 健康状态的，通过每隔一定时间访问 nginx-ingress- controll 的/healthz 页面，如是没有响应就返回 404 之类的错误码。

测试 Ingress HTTP 代理 k8s 内部站点

docker load -i tomcat-8-5.tar.gz

cat ingress-demo.yaml

apiVersion: v1

kind: Service

metadata:

  name: tomcat

  namespace: default

spec:

  selector:

    app: tomcat

    release: canary

  ports:

  - name: http

    port: 8080

    targetPort: 8080

  - name: ajp

    targetPort: 8009

    port: 8009

---

apiVersion:  apps/v1

kind: Deployment

metadata:

  name: tomcat-deploy

  namespace: default

spec:

  replicas: 2

  selector:

    matchLabels:

      app: tomcat

      release: canary

  template:

    metadata:

      labels:

        app: tomcat

        release: canary

    spec:

      containers:

      - name: tomcat

        image: tomcat:8.5.34-jre8-alpine

        ports:

        - name: http

          containerPort: 8080

          name: ajp

          containerPort: 8009

#查看 pod 是否部署成功

kubectl get pods -l app=tomcat

kubectl get sac

#编写 ingress 的配置清单

vim ingress-myapp.yaml

apiVersion: networking.k8s.io/v1

kind: Ingress                  #清单类型

metadata:                      #元数据

  name: ingress-myapp        #ingress的名称

  namespace: ingress-myapp  #所属名称空间

  annotations:    #注解信息

    kubernetes.io/ingress.class: "nginx"

spec:        #规格

  rules:    #定义后端转发的规则

  - host: tomcat.lucky.com      #通过域名进行转发

    http:

      paths:

      - path:          #配置访问路径，如果通过url进行转发，需要修改，空默认认为访问的路径为"/"

        backend:        #配置后端服务

          serviceName: tomcat

          servicePort: 8080

kubectl apply -f ingress-myapp.yaml

#查看 ingress-myapp 的详细信息

kubectl describe ingress ingress-myappName: ingress-myapp

Namespace:        default

Address:         

Default backend:  default-http-backend:80 (10.244.187.70:8080)

Rules:

  Host              Path  Backends

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

  tomcat.lucky.com 

                      tomcat:8080 (10.244.209.130:8080,10.244.209.131:8080)

Annotations:        kubernetes.io/ingress.class: nginx

Events:            <none>

#修改电脑本地的 host 文件，增加如下一行，下面的 ip 是 god62 节点 ip 192.168.172.62 tomcat.lucky.com

浏览器访问 tomcat.lucky.com，出现tomcat首页

测试 Ingress HTTPS 代理 tomcat

1、构建 TLS 站点

1)准备证书，在 god63 节点操作

openssl genrsa -out tls.key 2048

openssl req -new -x509 -key tls.key -out tls.crt -subj /C=CN/ST=Beijing/L=Beijing/O=DevOps/CN=tomcat.lucky.com

(2)生成 secret，在 god63 节点操作

kubectl create secret tls tomcat-ingress-secret --cert=tls.crt -- key=tls.key

(3)查看 secret

kubectl get secret

NAME                    TYPE                                  DATA  AGE

default-token-gp8bp    kubernetes.io/service-account-token  3      33d

tomcat-ingress-secret  kubernetes.io/tls                    2      5s

(4)查看 tomcat-ingress-secret 详细信息

kubectl describe secret tomcat-ingress-secret

Name:        tomcat-ingress-secret

Namespace:    default

Labels:      <none>

Annotations:  <none>

Type:  kubernetes.io/tls

Data

====

tls.key:  1679 bytes

tls.crt:  1294 bytes

2、创建 Ingress

Ingress 规则可以参考官方:

https://kubernetes.io/zh/docs/concepts/services-networking/ingress/

kubectl explain ingress.spec.rules.http.paths.backend.service

cat ingress-tomcat-tls.yaml

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

  name: ingress-tomcat-tls

  namespace: default

  annotations:

    kubernetes.io/ingress.class: "nginx"

spec:

  tls:

  - hosts:

    - tomcat.lucky.com

    secretName: tomcat-ingress-secret

  rules:

  - host: tomcat.lucky.com

    http:

      paths:

      - path: /

        pathType: Prefix

        backend:

          service:

            name: tomcat

            port:

              number: 8080

kubectl apply -f ingress-tomcat-tls.yaml

浏览器访问 https://tomcat.lucky.com

通过 Ingress-nginx 实现灰度发布

Ingress-Nginx 支持配置 Ingress Annotations 来实现不同场景下的灰度发布和测试。 Nginx

Annotations 支持以下几种 Canary 规则:

假设我们现在部署了两个版本的服务，老版本和 canary 版本

nginx.ingress.kubernetes.io/canary-by-header:基于 Request Header 的流量切分，适用于 灰度发布以及 A/B 测试。当 Request Header 设置为 always 时，请求将会被一直发送到 Canary 版 本;当 Request Header 设置为 never 时，请求不会被发送到 Canary 入口。

nginx.ingress.kubernetes.io/canary-by-header-value:要匹配的 Request Header 的值， 用于通知 Ingress 将请求路由到 Canary Ingress 中指定的服务。当 Request Header 设置为此值 时，它将被路由到 Canary 入口。

nginx.ingress.kubernetes.io/canary-weight:基于服务权重的流量切分，适用于蓝绿部署，权 重范围 0 - 100 按百分比将请求路由到 Canary Ingress 中指定的服务。权重为 0 意味着该金丝雀规 则不会向 Canary 入口的服务发送任何请求。权重为 60 意味着 60%流量转到 canary。权重为 100 意 味着所有请求都将被发送到 Canary 入口。

nginx.ingress.kubernetes.io/canary-by-cookie:基于 Cookie 的流量切分，适用于灰度发布 与 A/B 测试。用于通知 Ingress 将请求路由到 Canary Ingress 中指定的服务的 cookie。当 cookie 值设置为 always 时，它将被路由到 Canary 入口;当 cookie 值设置为 never 时，请求不会 被发送到 Canary 入口。

部署服务:

我们服务的 deployment 就不展示了，service 配置如下:

# 测试版本

vim hello-service.yaml

apiVersion: v1

kind: Service

metadata:

  name: hello-service

  labels:

    app: hello-service

spec:

  ports:

  - port: 80

    protocol: TCP

  selector:

    app: hello-service

# canary 版本

vim canary-hello-service.yaml

apiVersion: v1

kind: Service

metadata:

  name: canary-hello-service

  labels:

    app: canary-hello-service

spec:

  ports:

  - port: 80

    protocol: TCP

  selector:

    app: canary-hello-service

根据权重转发:

ingress 配置如下:

vim ingress-weight.yaml

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

  name: canary

  annotations:

    kubernetes.io/ingress.class: nginx

    nginx.ingress.kubernetes.io/canary: "true"

    nginx.ingress.kubernetes.io/canary-weight: "30"

spec:

  rules:

  - host: canary-service.abc.com

      http:

      paths:

      - path: /

        pathType: Prefix

        backend:

          service:

            name: canary-hello-service

            port:

              number: 80

$ for i in $(seq 1 10); do curl http://canary-service.abc.com; echo '\n'; done

hello world-version1 hello world-version1 hello world-version2 hello world-version2 hello world-version1 hello world-version1 hello world-version1 hello world-version1 hello world-version1 hello world-version1

根据请求头转发:

annotation 配置如下(ingress 其余部分省略) annotations:

kubernetes.io/ingress.class: nginx nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-by-header: "test"

测试结果如下:

$ for i in $(seq 1 5); do curl -H 'test:always' http://canary-service.abc.com; echo '\n'; done

hello world-version1

hello world-version1

hello world-version1

hello world-version1

hello world-version1

$ for i in $(seq 1 5); do curl -H 'test:abc' http://canary-service.abc.com; echo '\n';

done

hello world-version2

hello world-version2 hello world-version2 hello world-version2 hello world-version2

根据 cookie 转发:

使用 cookie 来进行流量管理的场景比较适合用于 A/B test，比如用户的请求 cookie 中含有特殊的标签，那么我们可以把这部分用户的请求转发到特定的服务进行处理。

annotation。配置如下

kubernetes.io/ingress.class: nginx

nginx.ingress.kubernetes.io/canary: "true" 

nginx.ingress.kubernetes.io/canary-by-cookie: "like_music"

测试结果如下:

$ for i in $(seq 1 5); do curl -b 'like_music=1' http://canary-service.abc.com; echo '\n'; done

hello world-version1

hello world-version1

hello world-version1

hello world-version1

hello world-version1

$ for i in $(seq 1 5); do curl -b 'like_music=always' http://canary-service.abc.com;

echo '\n'; done

hello world-version2

hello world-version2 hello world-version2 hello world-version2 hello world-version2

三种 annotation 按如下顺序匹配

canary-by-header > canary-by-cookie > canary-weight