文章目录

  • 1. 前言
  • 2. 为什么要有 Ingress?
    • 2.1 Service 的缺点
    • 2.2 (Ingress)怎么解决Service 的缺点？
  • 3. 为什么要有 Ingress Controller 和 IngressClass?
    • 3.1 为什么要有 Ingress Controller？
      • 3.1.1 Ingress Controller
      • 3.1.1 Ingress Controller 常见公司
      • 3.1.2 Ingress Controller 在 Kubernetes 集群里的地位
    • 3.2 为什么要有 IngressClass？
      • 3.2.1 IngressClass的作用是什么？
  • 4. 如何使用 YAML 描述 Ingress/Ingress Class ?
    • 4.1 为什么 kubectl api-resources 找不到Ingress Controller？
    • 4.2 Ingress/Ingress Class 用法
      • 4.2.1 Ingress 用法
        • 4.2.1.1 Ingress 的 YAML 的 rules 字段
      • 4.2.1 Ingress Class 用法
    • 4.3 ngress 和 Service、Ingress Class 关系图
  • 5. 如何在 Kubernetes 里使用 Ingress/Ingress Class？
    • 5.1 创建ns、ConfigMap、 Secret、ClusterRole对象
    • 5.2 API 对象的关联图
    • 5.3 创建 Ingress 对象
    • 5.4 查看创建的对象及pod
      • 5.4.1 遇到的报错
    • 5.5 使用Service 对外暴露端口
  • 6 小结
  • 7 思考
    • 7.1 四层负载均衡（Service）与七层负载均衡（Ingress）有哪些异同点？
    • 7.2 你认为 Ingress Controller 作为集群的流量入口还应该做哪些事情？

1. 前言

  我们学习了 Service 对象，它是 Kubernetes 内置的负载均衡机制，使用静态 IP 地址代理动态变化的 Pod，支持域名访问和服务发现，是微服务架构必需的基础设施。

  Service 很有用，但也只能说是“基础设施”，它对网络流量的管理方案还是太简单，离复杂的现代应用架构需求还有很大的差距，所以 Kubernetes 就在 Service 之上又提出了一个新的概念：Ingress。比起 Service，Ingress 更接近实际业务，对它的开发、应用和讨论也是社区里最火爆的，今天我们就来看看 Ingress，还有与它关联的 Ingress Controller、Ingress Class 等对象。

2. 为什么要有 Ingress?

  通过上次课程的讲解，我们知道了 Service 的功能和运行机制，它本质上就是一个由 kube-proxy 控制的四层负载均衡，在 TCP/IP 协议栈上转发流量（Service 工作原理示意图）：
  但在四层上的负载均衡功能还是太有限了，只能够依据 IP 地址和端口号做一些简单的判断和组合，而我们现在的绝大多数应用都是跑在七层的 HTTP/HTTPS 协议上的，有更多的高级路由条件，比如主机名、URI、请求头、证书等等，而这些在 TCP/IP 网络栈里是根本看不见的。

2.1 Service 的缺点

  Service比较适合代理集群内部的服务。如果想要把服务暴露到集群外部，就只能使用 NodePort 或者 LoadBalancer 这两种方式，而它们都缺乏足够的灵活性，难以管控，这就导致了一种很无奈的局面：我们的服务空有一身本领，却没有合适的机会走出去大展拳脚。

2.2 (Ingress)怎么解决Service 的缺点？

  Kubernetes 还是沿用了 Service 的思路，既然 Service 是四层的负载均衡，那么我再引入一个新的 API 对象，在七层上做负载均衡是不是就可以了呢？

  不**过除了七层负载均衡，这个对象还应该承担更多的职责，也就是作为流量的总入口，统管集群的进出口数据**，“扇入”“扇出”流量（也就是我们常说的“南北向”），让外部用户能够安全、顺畅、便捷地访问内部服务

  所以，这个 API 对象就顺理成章地被命名为 Ingress，意思就是集群内外边界上的入口

3. 为什么要有 Ingress Controller 和 IngressClass?

3.1 为什么要有 Ingress Controller？

  再对比一下 Service 我们就能更透彻地理解 Ingress。

  Ingress 可以说是在七层上另一种形式的 Service，它同样会代理一些后端的 Pod，也有一些路由规则来定义流量应该如何分配、转发，只不过这些规则都使用的是 HTTP/HTTPS 协议。你应该知道，Service 本身是没有服务能力的，它只是一些 iptables 规则，真正配置、应用这些规则的实际上是节点里的 kube-proxy 组件。如果没有 kube-proxy，Service 定义得再完善也没有用。

  同样的，Ingress 也只是一些 HTTP 路由规则的集合，相当于一份静态的描述文件，真正要把这些规则在集群里实施运行，还需要有另外一个东西，这就是 Ingress Controller，它的作用就相当于 Service 的 kube-proxy，能够读取、应用 Ingress 规则，处理、调度流量。按理来说，Kubernetes 应该把 Ingress Controller 内置实现，作为基础设施的一部分，就像 kube-proxy 一样。

3.1.1 Ingress Controller

  不过 Ingress Controller 要做的事情太多，与上层业务联系太密切，所以 Kubernetes 把 Ingress Controller 的实现交给了社区，任何人都可以开发 Ingress Controller，只要遵守 Ingress 规则就好。

  这就造成了 Ingress Controller“百花齐放”的盛况。由于 Ingress Controller 把守了集群流量的关键入口，掌握了它就拥有了控制集群应用的“话语权”，所以众多公司纷纷入场，精心打造自己的 Ingress Controller，意图在 Kubernetes 流量进出管理这个领域占有一席之地。

  这些实现中最著名的，就是老牌的反向代理和负载均衡软件 Nginx 了。从 Ingress Controller 的描述上我们也可以看到，HTTP 层面的流量管理、安全控制等功能其实就是经典的反向代理，而 Nginx 则是其中稳定性最好、性能最高的产品，所以它也理所当然成为了 Kubernetes 里应用得最广泛的 Ingress Controller。

3.1.1 Ingress Controller 常见公司

  不过，因为 Nginx 是开源的，谁都可以基于源码做二次开发，所以它又有很多的变种，比如社区的 Kubernetes Ingress Controller（https://github.com/kubernetes/ingress-nginx）、Nginx 公司自己的 Nginx Ingress Controller（https://github.com/nginxinc/kubernetes-ingress）、还有基于 OpenResty 的 Kong Ingress Controller（https://github.com/Kong/kubernetes-ingress-controller）等等。

3.1.2 Ingress Controller 在 Kubernetes 集群里的地位

  根据 Docker Hub 上的统计，Nginx 公司的开发实现是下载量最多的 Ingress Controller，所以我将以它为例，讲解 Ingress 和 Ingress Controller 的用法。

  下面的这张图就来自 Nginx 官网，比较清楚地展示了 Ingress Controller 在 Kubernetes 集群里的地位：

3.2 为什么要有 IngressClass？

  那么到现在，有了 Ingress 和 Ingress Controller，我们是不是就可以完美地管理集群的进出流量了呢？

  最初 Kubernetes 也是这么想的，一个集群里有一个 Ingress Controller，再给它配上许多不同的 Ingress 规则，应该就可以解决请求的路由和分发问题了。

  但随着 Ingress 在实践中的大量应用，很多用户发现这种用法会带来一些问题，比如：

  • 由于某些原因，项目组需要引入不同的 Ingress Controller，但 Kubernetes 不允许这样做；
  • Ingress 规则太多，都交给一个 Ingress Controller 处理会让它不堪重负；
  • 多个 Ingress 对象没有很好的逻辑分组方式，管理和维护成本很高；
  • 集群里有不同的租户，他们对 Ingress 的需求差异很大甚至有冲突，无法部署在同一个 Ingress Controller 上。

3.2.1 IngressClass的作用是什么？

  所以，Kubernetes 就又提出了一个 Ingress Class 的概念，让它插在 Ingress 和 Ingress Controller 中间，作为流量规则和控制器的协调人，解除了 Ingress 和 Ingress Controller 的强绑定关系。

  现在，Kubernetes 用户可以转向管理 Ingress Class，用它来定义不同的业务逻辑分组，简化 Ingress 规则的复杂度。比如说，我们可以用 Class A 处理博客流量、Class B 处理短视频流量、Class C 处理购物流量。
  这些 Ingress 和 Ingress Controller 彼此独立，不会发生冲突，所以上面的那些问题也就随着 Ingress Class 的引入迎刃而解了。

4. 如何使用 YAML 描述 Ingress/Ingress Class ?

  我们花了比较多的篇幅学习 Ingress、 Ingress Controller、Ingress Class 这三个对象，全是理论，你可能觉得学得有点累。但这也是没办法的事情，毕竟现实的业务就是这么复杂，而且这个设计架构也是社区经过长期讨论后达成的一致结论，是我们目前能获得的最佳解决方案。

  好，了解了这三个概念之后，我们就可以来看看如何为它们编写 YAML 描述文件了。

  和之前学习 Deployment、Service 对象一样，首先应当用命令 kubectl api-resources 查看它们的基本信息，输出列在这里了：

kubectl api-resources
NAME          SHORTNAMES   APIVERSION           NAMESPACED   KIND
ingresses       ing          networking.k8s.io/v1   true         Ingress
ingressclasses               networking.k8s.io/v1   false        IngressClass

4.1 为什么 kubectl api-resources 找不到Ingress Controller？

  你可以看到，Ingress 和 Ingress Class 的 apiVersion 都是“networking.k8s.io/v1”，而且 Ingress 有一个简写“ing”，但 Ingress Controller 怎么找不到呢？

这是因为 Ingress Controller 和其他两个对象不太一样，它不只是描述文件，是一个要实际干活、处理流量的应用程序，而应用程序在 Kubernetes 里早就有对象来管理了，那就是 Deployment 和 DaemonSet，所以我们只需要再学习 Ingress 和 Ingress Class 的的用法就可以了。

4.2 Ingress/Ingress Class 用法

4.2.1 Ingress 用法

先看 Ingress。
Ingress 也是可以使用 kubectl create 来创建样板文件的，和 Service 类似，它也需要用两个附加参数：

  • –class，指定 Ingress 从属的 Ingress Class 对象。
  • –rule，指定路由规则，基本形式是“URI=Service”，也就是说是访问 HTTP 路径就转发到对应的 Service 对象，再由 Service 对象转发给后端的 Pod。

好，现在我们就执行命令，看看 Ingress 到底长什么样：


export out="--dry-run=client -o yaml"
kubectl create ing ngx-ing --rule="ngx.test/=ngx-svc:80" --class=ngx-ink $out

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:name: ngx-ingspec:ingressClassName: ngx-inkrules:- host: ngx.testhttp:paths:- path: /pathType: Exactbackend:service:name: ngx-svcport:number: 80

4.2.1.1 Ingress 的 YAML 的 rules 字段

  在这份 Ingress 的 YAML 里，有两个关键字段：“ingressClassName”和“rules”，分别对应了命令行参数，含义还是比较好理解的。

  只是“rules”的格式比较复杂，嵌套层次很深。不过仔细点看就会发现它是把路由规则拆散了，有 host 和 http path，在 path 里又指定了路径的匹配方式，可以是精确匹配（Exact）或者是前缀匹配（Prefix），再用 backend 来指定转发的目标 Service 对象。

  不过我个人觉得，Ingress YAML 里的描述还不如 kubectl create 命令行里的 --rule 参数来得直观易懂，而且 YAML 里的字段太多也很容易弄错，建议你还是让 kubectl 来自动生成规则，然后再略作修改比较好。

4.2.1 Ingress Class 用法

  有了 Ingress 对象，那么与它关联的 Ingress Class 是什么样的呢？

  其实 Ingress Class 本身并没有什么实际的功能，只是起到联系 Ingress 和 Ingress Controller 的作用，所以它的定义非常简单，在“spec”里只有一个必需的字段“controller”，表示要使用哪个 Ingress Controller，具体的名字就要看实现文档了。

  比如，如果我要用 Nginx 开发的 Ingress Controller，那么就要用名字“nginx.org/ingress-controller”

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:name: ngx-inkspec:controller: nginx.org/ingress-controller

4.3 ngress 和 Service、Ingress Class 关系图

Ingress 和 Service、Ingress Class 的关系我也画成了一张图，方便你参考：

5. 如何在 Kubernetes 里使用 Ingress/Ingress Class？

  准备好了 Ingress 和 Ingress Class，接下来我们就需要部署真正处理路由规则的 Ingress Controller。

5.1 创建ns、ConfigMap、 Secret、ClusterRole对象

  你可以在 GitHub 上找到 Nginx Ingress Controller 的项目（https://github.com/nginxinc/kubernetes-ingress），因为它以 Pod 的形式运行在 Kubernetes 里，所以同时支持 Deployment 和 DaemonSet 两种部署方式。这里我选择的是 Deployment，相关的 YAML 也都在我们课程的项目（
）里复制了一份。Nginx Ingress Controller 的安装略微麻烦一些，有很多个 YAML 需要执行，但如果只是做简单的试验，就只需要用到 4 个 YAML：

kubectl apply -f ns-and-sa.yaml
kubectl apply -f rbac.yaml
kubectl apply -f nginx-config.yaml
kubectl apply -f default-server-secret.yaml

cd /k8s/ingress
cat  > ns-and-sa.yaml << EOF
apiVersion: v1
kind: Namespace
metadata:name: nginx-ingress
---
apiVersion: v1
kind: ServiceAccount
metadata:name: nginx-ingress namespace: nginx-ingress
EOFcat > rbac.yaml << EOF
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:name: nginx-ingress
rules:
- apiGroups:- ""resources:- services- endpointsverbs:- get- list- watch
- apiGroups:- ""resources:- secretsverbs:- get- list- watch
- apiGroups:- ""resources:- configmapsverbs:- get- list- watch- update- create
- apiGroups:- ""resources:- podsverbs:- list- watch
- apiGroups:- ""resources:- eventsverbs:- create- patch- list
- apiGroups:- networking.k8s.ioresources:- ingressesverbs:- list- watch- get
- apiGroups:- networking.k8s.ioresources:- ingresses/statusverbs:- update
- apiGroups:- k8s.nginx.orgresources:- virtualservers- virtualserverroutes- globalconfigurations- transportservers- policiesverbs:- list- watch- get
- apiGroups:- k8s.nginx.orgresources:- virtualservers/status- virtualserverroutes/status- policies/status- transportservers/statusverbs:- update
- apiGroups:- networking.k8s.ioresources:- ingressclassesverbs:- get
- apiGroups:- cis.f5.comresources:- ingresslinksverbs:- list- watch- get
- apiGroups:- cert-manager.ioresources:- certificatesverbs:- list- watch- get- update- create- delete
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:name: nginx-ingress
subjects:
- kind: ServiceAccountname: nginx-ingressnamespace: nginx-ingress
roleRef:kind: ClusterRolename: nginx-ingressapiGroup: rbac.authorization.k8s.io
EOF cat >  nginx-config.yaml << EOF
kind: ConfigMap
apiVersion: v1
metadata:name: nginx-confignamespace: nginx-ingress
data:
EOFcat > default-server-secret.yaml << EOF
apiVersion: v1
kind: Secret
metadata:name: default-server-secretnamespace: nginx-ingress
type: kubernetes.io/tls
data:tls.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUN2akNDQWFZQ0NRREFPRjl0THNhWFhEQU5CZ2txaGtpRzl3MEJBUXNGQURBaE1SOHdIUVlEVlFRRERCWk8KUjBsT1dFbHVaM0psYzNORGIyNTBjbTlzYkdWeU1CNFhEVEU0TURreE1qRTRNRE16TlZvWERUSXpNRGt4TVRFNApNRE16TlZvd0lURWZNQjBHQTFVRUF3d1dUa2RKVGxoSmJtZHlaWE56UTI5dWRISnZiR3hsY2pDQ0FTSXdEUVlKCktvWklodmNOQVFFQkJRQURnZ0VQQURDQ0FRb0NnZ0VCQUwvN2hIUEtFWGRMdjNyaUM3QlBrMTNpWkt5eTlyQ08KR2xZUXYyK2EzUDF0azIrS3YwVGF5aGRCbDRrcnNUcTZzZm8vWUk1Y2Vhbkw4WGM3U1pyQkVRYm9EN2REbWs1Qgo4eDZLS2xHWU5IWlg0Rm5UZ0VPaStlM2ptTFFxRlBSY1kzVnNPazFFeUZBL0JnWlJVbkNHZUtGeERSN0tQdGhyCmtqSXVuektURXUyaDU4Tlp0S21ScUJHdDEwcTNRYzhZT3ExM2FnbmovUWRjc0ZYYTJnMjB1K1lYZDdoZ3krZksKWk4vVUkxQUQ0YzZyM1lma1ZWUmVHd1lxQVp1WXN2V0RKbW1GNWRwdEMzN011cDBPRUxVTExSakZJOTZXNXIwSAo1TmdPc25NWFJNV1hYVlpiNWRxT3R0SmRtS3FhZ25TZ1JQQVpQN2MwQjFQU2FqYzZjNGZRVXpNQ0F3RUFBVEFOCkJna3Foa2lHOXcwQkFRc0ZBQU9DQVFFQWpLb2tRdGRPcEsrTzhibWVPc3lySmdJSXJycVFVY2ZOUitjb0hZVUoKdGhrYnhITFMzR3VBTWI5dm15VExPY2xxeC9aYzJPblEwMEJCLzlTb0swcitFZ1U2UlVrRWtWcitTTFA3NTdUWgozZWI4dmdPdEduMS9ienM3bzNBaS9kclkrcUI5Q2k1S3lPc3FHTG1US2xFaUtOYkcyR1ZyTWxjS0ZYQU80YTY3Cklnc1hzYktNbTQwV1U3cG9mcGltU1ZmaXFSdkV5YmN3N0NYODF6cFErUyt1eHRYK2VBZ3V0NHh3VlI5d2IyVXYKelhuZk9HbWhWNThDd1dIQnNKa0kxNXhaa2VUWXdSN0diaEFMSkZUUkk3dkhvQXprTWIzbjAxQjQyWjNrN3RXNQpJUDFmTlpIOFUvOWxiUHNoT21FRFZkdjF5ZytVRVJxbStGSis2R0oxeFJGcGZnPT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=tls.key: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFcEFJQkFBS0NBUUVBdi91RWM4b1JkMHUvZXVJTHNFK1RYZUprckxMMnNJNGFWaEMvYjVyYy9XMlRiNHEvClJOcktGMEdYaVN1eE9ycXgrajlnamx4NXFjdnhkenRKbXNFUkJ1Z1B0ME9hVGtIekhvb3FVWmcwZGxmZ1dkT0EKUTZMNTdlT1l0Q29VOUZ4amRXdzZUVVRJVUQ4R0JsRlNjSVo0b1hFTkhzbysyR3VTTWk2Zk1wTVM3YUhudzFtMApxWkdvRWEzWFNyZEJ6eGc2clhkcUNlUDlCMXl3VmRyYURiUzc1aGQzdUdETDU4cGszOVFqVUFQaHpxdmRoK1JWClZGNGJCaW9CbTVpeTlZTW1hWVhsMm0wTGZzeTZuUTRRdFFzdEdNVWozcGJtdlFmazJBNnljeGRFeFpkZFZsdmwKMm82MjBsMllxcHFDZEtCRThCay90elFIVTlKcU56cHpoOUJUTXdJREFRQUJBb0lCQVFDZklHbXowOHhRVmorNwpLZnZJUXQwQ0YzR2MxNld6eDhVNml4MHg4Mm15d1kxUUNlL3BzWE9LZlRxT1h1SENyUlp5TnUvZ2IvUUQ4bUFOCmxOMjRZTWl0TWRJODg5TEZoTkp3QU5OODJDeTczckM5bzVvUDlkazAvYzRIbjAzSkVYNzZ5QjgzQm9rR1FvYksKMjhMNk0rdHUzUmFqNjd6Vmc2d2szaEhrU0pXSzBwV1YrSjdrUkRWYmhDYUZhNk5nMUZNRWxhTlozVDhhUUtyQgpDUDNDeEFTdjYxWTk5TEI4KzNXWVFIK3NYaTVGM01pYVNBZ1BkQUk3WEh1dXFET1lvMU5PL0JoSGt1aVg2QnRtCnorNTZud2pZMy8yUytSRmNBc3JMTnIwMDJZZi9oY0IraVlDNzVWYmcydVd6WTY3TWdOTGQ5VW9RU3BDRkYrVm4KM0cyUnhybnhBb0dCQU40U3M0ZVlPU2huMVpQQjdhTUZsY0k2RHR2S2ErTGZTTXFyY2pOZjJlSEpZNnhubmxKdgpGenpGL2RiVWVTbWxSekR0WkdlcXZXaHFISy9iTjIyeWJhOU1WMDlRQ0JFTk5jNmtWajJTVHpUWkJVbEx4QzYrCk93Z0wyZHhKendWelU0VC84ajdHalRUN05BZVpFS2FvRHFyRG5BYWkyaW5oZU1JVWZHRXFGKzJyQW9HQkFOMVAKK0tZL0lsS3RWRzRKSklQNzBjUis3RmpyeXJpY05iWCtQVzUvOXFHaWxnY2grZ3l4b25BWlBpd2NpeDN3QVpGdwpaZC96ZFB2aTBkWEppc1BSZjRMazg5b2pCUmpiRmRmc2l5UmJYbyt3TFU4NUhRU2NGMnN5aUFPaTVBRHdVU0FkCm45YWFweUNweEFkREtERHdObit3ZFhtaTZ0OHRpSFRkK3RoVDhkaVpBb0dCQUt6Wis1bG9OOTBtYlF4VVh5YUwKMjFSUm9tMGJjcndsTmVCaWNFSmlzaEhYa2xpSVVxZ3hSZklNM2hhUVRUcklKZENFaHFsV01aV0xPb2I2NTNyZgo3aFlMSXM1ZUtka3o0aFRVdnpldm9TMHVXcm9CV2xOVHlGanIrSWhKZnZUc0hpOGdsU3FkbXgySkJhZUFVWUNXCndNdlQ4NmNLclNyNkQrZG8wS05FZzFsL0FvR0FlMkFVdHVFbFNqLzBmRzgrV3hHc1RFV1JqclRNUzRSUjhRWXQKeXdjdFA4aDZxTGxKUTRCWGxQU05rMXZLTmtOUkxIb2pZT2pCQTViYjhibXNVU1BlV09NNENoaFJ4QnlHbmR2eAphYkJDRkFwY0IvbEg4d1R0alVZYlN5T294ZGt5OEp0ek90ajJhS0FiZHd6NlArWDZDODhjZmxYVFo5MWpYL3RMCjF3TmRKS2tDZ1lCbyt0UzB5TzJ2SWFmK2UwSkN5TGhzVDQ5cTN3Zis2QWVqWGx2WDJ1VnRYejN5QTZnbXo5aCsKcDNlK2JMRUxwb3B0WFhNdUFRR0xhUkcrYlNNcjR5dERYbE5ZSndUeThXczNKY3dlSTdqZVp2b0ZpbmNvVlVIMwphdmxoTUVCRGYxSjltSDB5cDBwWUNaS2ROdHNvZEZtQktzVEtQMjJhTmtsVVhCS3gyZzR6cFE9PQotLS0tLUVORCBSU0EgUFJJVkFURSBLRVktLS0tLQo=
EOF

  前两条命令为 Ingress Controller 创建了一个独立的名字空间“nginx-ingress”，还有相应的账号和权限，这是为了访问 apiserver 获取 Service、Endpoint 信息用的；后两条则是创建了一个 ConfigMap 和 Secret，用来配置 HTTP/HTTPS 服务。

  部署 Ingress Controller 不需要我们自己从头编写 Deployment，Nginx 已经为我们提供了示例 YAML，但创建之前为了适配我们自己的应用还必须要做几处小改动：

  • metadata 里的 name 要改成自己的名字，比如 ngx-kic-dep。
  • spec.selector 和 template.metadata.labels 也要修改成自己的名字，比如还是用 ngx-kic-dep。
  • containers.image 可以改用 apline 版本，加快下载速度，比如 nginx/nginx-ingress:2.2-alpine。
  • 最下面的 args 要加上 -ingress-class=ngx-ink，也就是前面创建的 Ingress Class 的名字，这是让 Ingress Controller 管理 Ingress 的关键。

yaml文件链接，参照修改：https://github.com/nginxinc/kubernetes-ingress/blob/main/deployments/deployment/nginx-ingress.yaml

apiVersion: apps/v1
kind: Deployment
metadata:name: ngx-kic-depnamespace: nginx-ingressspec:replicas: 1selector:matchLabels:app: ngx-kic-deptemplate:metadata:labels:app: ngx-kic-dep...spec:containers:- image: nginx/nginx-ingress:2.2-alpine...args:- -ingress-class=ngx-ink

5.2 API 对象的关联图

有了 Ingress Controller，这些 API 对象的关联就更复杂了，你可以用下面的这张图来看出它们是如何使用对象名字联系起来的：

5.3 创建 Ingress 对象

确认 Ingress Controller 的 YAML 修改完毕之后，就可以用 kubectl apply 创建对象：

kubectl apply -f kic.yml

5.4 查看创建的对象及pod

注意 Ingress Controller 位于名字空间“nginx-ingress”，所以查看状态需要用“-n”参数显式指定，否则我们只能看到“default”名字空间里的 Pod：

kubectl get deploy -n nginx-ingress
kubectl get pod -n nginx-ingress

现在 Ingress Controller 就算是运行起来了

5.4.1 遇到的报错

# 1 ImagePullBackOff
worker 节点没有镜像# 2 CrashLoopBackOff
待解决，考虑可能是这5个yaml文件的问题

5.5 使用Service 对外暴露端口

  不过还有最后一道工序，因为 Ingress Controller 本身也是一个 Pod，想要向外提供服务还是要依赖于 Service 对象。所以你至少还要再为它定义一个 Service，使用 NodePort 或者 LoadBalancer 暴露端口，才能真正把集群的内外流量打通。
  这里，我就用之前提到的命令kubectl port-forward，它可以直接把本地的端口映射到 Kubernetes 集群的某个 Pod 里，在测试验证的时候非常方便。下面这条命令就把本地的 8080 端口映射到了 Ingress Controller Pod 的 80 端口：

kubectl port-forward -n nginx-ingress ngx-kic-dep-8859b7b86-cplgp 8080:80 &


  我们在 curl 发测试请求的时候需要注意，因为 Ingress 的路由规则是 HTTP 协议，所以就不能用 IP 地址的方式访问，必须要用域名、URI。你可以修改 /etc/hosts 来手工添加域名解析，也可以使用 --resolve 参数，指定域名的解析规则，比如在这里我就把“ngx.test”强制解析到“127.0.0.1”，也就是被 kubectl port-forward 转发的本地地址：

curl --resolve ngx.test:8080:127.0.0.1 http://ngx.test:8080


  把这个访问结果和之前的 Service 对比一下，你会发现最终效果是一样的，都是把请求转发到了集群内部的 Pod，但 Ingress 的路由规则不再是 IP 地址，而是 HTTP 协议里的域名、URI 等要素。

6 小结

  1. Service 是四层负载均衡，能力有限，所以就出现了 Ingress，它基于 HTTP/HTTPS 协议定义路由规则。
  2. Ingress 只是规则的集合，自身不具备流量管理能力，需要 Ingress Controller 应用 Ingress 规则才能真正发挥作用。
  3. Ingress Class 解耦了 Ingress 和 Ingress Controller，我们应当使用 Ingress Class 来管理 Ingress 资源。
  4. 最流行的 Ingress Controller 是 Nginx Ingress Controller，它基于经典反向代理软件 Nginx。
  5. 目前的 Kubernetes 流量管理功能主要集中在 Ingress Controller 上，已经远不止于管理“入口流量”了，它还能管理“出口流量”，也就是 egress，甚至还可以管理集群内部服务之间的“东西向流量”。
  6. Ingress Controller 通常还有很多的其他功能，比如 TLS 终止、网络应用防火墙、限流限速、流量拆分、身份认证、访问控制等等，完全可以认为它是一个全功能的反向代理或者网关。

7 思考

7.1 四层负载均衡（Service）与七层负载均衡（Ingress）有哪些异同点？

四层负载结构简单，无需解析消息内容，在网络吞吐量及处理性能高于七层
七层负载优势在于功能多，控制灵活强大

7.2 你认为 Ingress Controller 作为集群的流量入口还应该做哪些事情？

13 Igress,集群进出流量的总管相关推荐

  1. 【Kubernetes】K8s笔记（十一）：Ingress 集群进出流量总管

  2. 使用二进制包在生产环境部署 Kubernetes v1.13.2 集群

    文章目录 使用二进制包在生产环境部署 Kubernetes v1.13.2 集群 一 背景 二 环境及架构图 2.1 软件环境 2.2 服务器规划 2.3 节点或组件功能简介 2.4 Kubernet ...

  3. Hadoop学习笔记—13.分布式集群中节点的动态添加与下架

    Hadoop学习笔记-13.分布式集群中节点的动态添加与下架 开篇:在本笔记系列的第一篇中,我们介绍了如何搭建伪分布与分布模式的Hadoop集群.现在,我们来了解一下在一个Hadoop分布式集群中,如 ...

  4. Greenplum【集群搭建 01】局域网 CentOS 7.9.2009 环境 GreenPlum 6.13.0 集群规划+配置+安装+内核参数调整（应用实例分享）

    1.部署环境 局域网已配置ip.ntp时间同步.yum源,服务器版本为CentOS Linux release 7.9.2009 (Core),安装文件为greenplum-db-6.13.0-rhe ...

  5. 一份详尽的利用 Kubeadm部署 Kubernetes 1.13.1 集群指北

    2019独角兽企业重金招聘Python工程师标准>>> 概 述 Kubernetes集群的搭建方法其实有多种,比如我在之前的文章<利用K8S技术栈打造个人私有云(连载之:K8S ...

  6. Kubenetes1.13.1集群部署 --01基于Kubeadm搭建Kubernetes

    软件包下载 链接:https://pan.baidu.com/s/1lbGbHPphlawMMm9UnFv0dQ  提取码:933z 介绍 配置K8S集群的步骤,内容从集群搭建到Kubernetes- ...

  7. 利用 Kubeadm部署 Kubernetes 1.13.1 集群实践录

    概 述 Kubernetes集群的搭建方法其实有多种,比如我在之前的文章<利用K8S技术栈打造个人私有云(连载之:K8S集群搭建)>中使用的就是二进制的安装方法.虽然这种方法有利于我们理解 ...

  8. kubeadm安装kubernetes 1.13.1集群完整部署记录

    k8s是什么 Kubernetes简称为k8s,它是 Google 开源的容器集群管理系统.在 Docker 技术的基础上,为容器化的应用提供部署运行.资源调度.服务发现和动态伸缩等一系列完整功能,提 ...

  9. Kubernetes1.13集群安装dashboard 1.10.1

    文章目录 Kubernetes1.13集群安装dashboard 1.10.1 安装dashboard 下载镜像 创建pod 授予Dashboard账户集群管理权限 APIServer方式 查看集群信 ...

最新文章

  1. this. $ refs: undefined 的解决办法
  2. Linux文件压缩与归档
  3. 自动识别文字的编码以及读取所有文本——VB2005
  4. MySQL创建触发器（CREATE TRIGGER）
  5. 【企业管理】商业伦理逻辑思考模型
  6. python处理字符_常用python字符串处理
  7. lambada表达式
  8. django crm 03
  9. 关于计算机类课程实验教学的思考
  10. 记一次线上coredump事故
  11. 清华大学计算机红皮书,哈佛的红皮书_82702698.pdf
  12. 当SDN 遇到物联网
  13. 【软件】如何批量手机号码归属地查询并且快速分类？批量号码归属地告诉查询分类系统怎么使用？全部教会你
  14. 硬盘的老化测试软件,扩容卡检测、扩容U盘检测工具(MyDiskTest)
  15. 技术党求生骚操作！手把手教你做一只口红色号识别器！
  16. peewee-async使用描述
  17. 基于C#+SQL Server实现（Web）学生选课管理系统【100010309】
  18. 数据库PostrageSQL-证书认证
  19. 西方哲学史 -- 赫拉克利特
  20. 云数据库CynosDB有哪些常见问题？

热门文章

  1. excel自动筛选_在Excel自动筛选器中隐藏箭头
  2. windows下TCP/IP常用网络故障诊断命令
  3. 青海大学计算机考研调剂,青海大学2021年硕士研究生招生调剂公告
  4. [zt]D语言编译器下载安装和编译参数
  5. php welive,WeLive免费开源PHP在线客服系统下载
  6. 具有自适应搜索策略的灰狼优化算法-附代码
  7. 一篇文章学会写作，自媒体人的必经之路
  8. 2019智能家居博览会-今日优选展会
  9. 关于mdm9206 threadx_os的I2c操作相关的API，
  10. 精选9个值得学习的 HTML5 效果【附源码】