【重识云原生】第六章容器基础6.4.11.1节——Ingress综述

1. Ingress概述

1.1 Ingress的简介

        service的作用体现在两个方面：

• 对集群内部，它不断跟踪pod的变化，更新endpoint中对应pod的对象，提供了ip不断变化的pod的服务发现机制；
• 对集群外部，他类似负载均衡器，可以在集群内外部对pod进行访问。

        在Kubernetes中，Pod的IP地址和service的ClusterIP仅可以在集群网络内部做用，对于集群外的应用是不可见的。为了使外部的应用能够访问集群内的服务，Kubernetes目前提供了以下几种方案：

• NodePort：将service暴露在节点网络上，NodePort背后就是Kube-Proxy，Kube-Proxy是沟通service网络、Pod网络和节点网络的桥梁。测试环境使用还行，当有几十上百的服务在集群中运行时，NodePort的瑞口管理就是个灾难。因为每个端口只能是一种服务，端口范围只能是 30000-32767。
• LoadBalancer：通过设置LoadBalancer映射到云服务商提供的LoadBalancer地址。这种用法仅用于在公有云服务提供商的云平台上设置Servic的场景。受限于云平台，且通常在云平台部署LoadBalancer还需要额外的费用。
• Ingress：只需一个或者少量的公网IP和LB，即可同时将多个HTTP服务暴露到外网，七层反向代理。 可以简单理解为service的service，它其实就是一组基于域名和URL路径，把用户的请求转发到一个或多个service的规则。

        Ingress解决的是新的服务加入后，域名和服务的对应问题，基本上是一个ingress的对象，通过yaml进行创建和更新进行加载。工作机制大致可以用下图表示：

        实际上，ingress相当于一个7层的负载均衡器，是k8s对反向代理的一个抽象。大概的工作原理也确实类似于Nginx，可以理解成在 Ingress 里建立一个个映射规则 , ingress Controller 通过监听 Ingress这个api对象里的配置规则并转化成 Nginx 的配置（kubernetes声明式API和控制循环） , 然后对外部提供服务。

1.2 Ingress的组成

        Ingress包含了两大组件Ingress Controller和Ingress。

1.2.1 Ingress组件

        ingress是一个API对象，通过yaml文件来配置，ingress对象的作用是定义请求如何转发到service的规则，可以理解为配置模板。 ingress通过http或https暴露集群内部service，给service提供外部URI、负载均衡、SSL/TLS能力以及基于域名的反向代理。ingress要依靠ingress-controiler来具体实现以上功能。

        简单来说，ingress-controller才是负责具体转发的组件，通过各种方式将它暴露在集群入口，外部对集群的请求流量会先到ingress-controller，而ingress对象是用来告诉ingress-controller该如何转发请求，比如哪些域名哪些path要转发到哪些服务等等。

Ingress 格式示例：

apiVersion: extensions/v1beta1 
kind: Ingress 
metadata: 
  name: test-ingress 
spec: 
  rules: 
    - http: 
      paths: 
        - path: /testpath 
          backend: 
            serviceName: test 
            servicePort: 80

        每个 Ingress 都需要配置 rules，目前 Kubernetes 仅支持 http 规则。上面的示例表示请求 /testpath 时转发到服务 test 的 80 端口。

1.2.2 ingress-controller组件

        ingress-controller是具体实现反向代理及负载均衡的程序，对ingress定义的规则进行解析，根据配置的规则来实现请求转发。 ingress-controller并不是k8s自带的组件，实际上ingess-controller只是一个统称，用户可以选择不同的ingress-controller实现，目前，由k8s维护的ingress-controller只有google云的GCE与ingress-nginx两个，其他还有很多第三方维护的ingress-controller，比如Contour, Haproxy, trafik, Istio，具体可以参考官方文档。 但是不管哪一种ingress-controller，实现的机制都大同小异，只是在具体配置上有差异，ingress controller核心是一个deployment，需要编写的yaml有：Deployment, Service, ConfigMap, ServiceAccount（Auth），其中service的类型可以是NodePort或者LoadBalancer。 一般来说，ingress-controller的形式都是一个pod，里面跑着demon程序和反向代理程序。daemon负责不断监控集群的变化，根据ingress对象生成配置并应用新配置到反向代理，比如ingress-nginx就是动态生成nginx配置，动态更新upstreanm，并在需要的时候reload程序应用新配置。为了方便，后面的例子都以k8s官方维护的ingress-nginx为例。 Ingress-Nginx github 地址： GitHub - kubernetes/ingress-nginx: Ingress-NGINX Controller for Kubernetes

Ingress-Nginx 官方网站： Welcome - NGINX Ingress Controller

1.3 Ingress的工作原理

        Ingress Controller是将Ingress这种变化生成一段Nginx的配置，然后将这个配置通过Kubernetes API写到Nginx的Pod中，然后reload.（注意：写入 nginx.conf 的不是service的地址，而是service backend 的 pod 的地址，避免在 service 在增加一层负载均衡转发）。

         从上图中可以很清晰的看到，实际上请求进来还是被负载均衡器拦截，比如 nginx，然后 Ingress Controller 通过跟 Ingress 交互得知某个域名对应哪个 service，再通过跟 kubernetes API 交互得知 service 地址等信息；综合以后生成配置文件，实时写入负载均衡器，然后负载均衡器 reload 该规则便可实现服务发现，即动态映射：

1. ingress-controller通过和 kubernetes APIServer交互，动态的去感知集群中ingress规则变化；
2. 然后读取它，按照自定义的规则，规则就是写明了哪个域名对应哪个service，生成一段nginx配置；
3. 再写到nginx-ingress-controller的pod里，这个ingres-controller的pod里运行着一个Nginx服务，控制器会把生成的nginx置写入/etc/nginx.conf文件中；
4. 最后reload一下使配置生效。以此达到域名区分配置和动态更新的作用。

         客户端一般会把请求发送到负载均衡器上由负载均衡器转发到ingress控制所在的node节点上目的减小Node节点的负载压力。ingress控制器会根据ingress资源对象的配置转发请求到对应的service；service会根据端点，把请求转发到关联的Pod。

         在使用普通的Service时，集群中每个节点的kube-proxy在监听到Service和Endpoints的变化时，会动态的修改相关的iptables的转发规则。 客户端在访问时通过iptables设置的规则进行路由转发达到访问服务的目的。

        而Ingress则跳过了kube-proxy这一层，通过Ingress Controller中的代理配置进行路由转发达到访问目标服务的目的。实际上可以把IngressController看做一个拥有默认处理后端的代理，根据Ingress资源的配置动态修改代理的配置文件，以实现按照规则转发请求的功能。

参考链接

Ingress · Kubernetes指南

Ingress | Kubernetes

K8S-ingress - 不会跳舞的胖子 - 博客园

k8s ingress原理及ingress-nginx部署测试_个人文章 - SegmentFault 思否

k8s之ingress使用

k8s——ingress - 落寞1111 - 博客园

K8S对外服务之Ingress_51CTO博客_k8s ingress

K8S中的ingress_84岁带头冲锋的博客-CSDN博客_k8s的ingress

k8s之ingress

k8s 对外服务之ingress_新是一切的根源的博客-CSDN博客_ingress k8s

一文讲透K8s的Service概念

   《重识云原生系列》专题索引：

1. 第一章——不谋全局不足以谋一域
2. 第二章计算第1节——计算虚拟化技术总述
3. 第二章计算第2节——主流虚拟化技术之VMare ESXi
4. 第二章计算第3节——主流虚拟化技术之Xen
5. 第二章计算第4节——主流虚拟化技术之KVM
6. 第二章计算第5节——商用云主机方案
7. 第二章计算第6节——裸金属方案
8. 第三章云存储第1节——分布式云存储总述
9. 第三章云存储第2节——SPDK方案综述
10. 第三章云存储第3节——Ceph统一存储方案
11. 第三章云存储第4节——OpenStack Swift 对象存储方案
12. 第三章云存储第5节——商用分布式云存储方案
13. 第四章云网络第一节——云网络技术发展简述
14. 第四章云网络4.2节——相关基础知识准备
15. 第四章云网络4.3节——重要网络协议
16. 第四章云网络4.3.1节——路由技术简述
17. 第四章云网络4.3.2节——VLAN技术
18. 第四章云网络4.3.3节——RIP协议
19. 第四章云网络4.3.4.1-2节——OSPF协议综述
20. 第四章云网络4.3.4.3节——OSPF协议工作原理
21. 第四章云网络4.3.4.4节——[转载]OSPF域内路由
22. 第四章云网络4.3.4.5节——[转载]OSPF外部路由
23. 第四章云网络4.3.4.6节——[转载]OSPF特殊区域之Stub和Totally Stub区域详解及配置
24. 第四章云网络4.3.4.7节——OSPF特殊区域之NSSA和Totally NSSA详解及配置
25. 第四章云网络4.3.5节——EIGRP协议
26. 第四章云网络4.3.6节——IS-IS协议
27. 第四章云网络4.3.7节——BGP协议
28. 第四章云网络4.3.7.2节——BGP协议概述
29. 第四章云网络4.3.7.3节——BGP协议实现原理
30. 第四章云网络4.3.7.4节——高级特性
31. 第四章云网络4.3.7.5节——实操
32. 第四章云网络4.3.7.6节——MP-BGP协议
33. 第四章云网络4.3.8节——策略路由
34. 第四章云网络4.3.9节——Graceful Restart(平滑重启)技术
35. 第四章云网络4.3.10节——VXLAN技术
36. 第四章云网络4.3.10.2节——VXLAN Overlay网络方案设计
37. 第四章云网络4.3.10.3节——VXLAN隧道机制
38. 第四章云网络4.3.10.4节——VXLAN报文转发过程
39. 第四章云网络4.3.10.5节——VXlan组网架构
40. 第四章云网络4.3.10.6节——VXLAN应用部署方案
41. 第四章云网络4.4节——Spine-Leaf网络架构
42. 第四章云网络4.5节——大二层网络
43. 第四章云网络4.6节——Underlay 和 Overlay概念
44. 第四章云网络4.7.1节——网络虚拟化与卸载加速技术的演进简述
45. 第四章云网络4.7.2节——virtio网络半虚拟化简介
46. 第四章云网络4.7.3节——Vhost-net方案
47. 第四章云网络4.7.4节vhost-user方案——virtio的DPDK卸载方案
48. 第四章云网络4.7.5节vDPA方案——virtio的半硬件虚拟化实现
49. 第四章云网络4.7.6节——virtio-blk存储虚拟化方案
50. 第四章云网络4.7.8节——SR-IOV方案
51. 第四章云网络4.7.9节——NFV
52. 第四章云网络4.8.1节——SDN总述
53. 第四章云网络4.8.2.1节——OpenFlow概述
54. 第四章云网络4.8.2.2节——OpenFlow协议详解
55. 第四章云网络4.8.2.3节——OpenFlow运行机制
56. 第四章云网络4.8.3.1节——Open vSwitch简介
57. 第四章云网络4.8.3.2节——Open vSwitch工作原理详解
58. 第四章云网络4.8.4节——OpenStack与SDN的集成
59. 第四章云网络4.8.5节——OpenDayLight
60. 第四章云网络4.8.6节——Dragonflow

61.  第四章云网络4.9.1节——网络卸载加速技术综述

62. 第四章云网络4.9.2节——传统网络卸载技术

63. 第四章云网络4.9.3.1节——DPDK技术综述

64. 第四章云网络4.9.3.2节——DPDK原理详解

65. 第四章云网络4.9.4.1节——智能网卡SmartNIC方案综述

66. 第四章云网络4.9.4.2节——智能网卡实现

67. 第六章容器6.1.1节——容器综述

68. 第六章容器6.1.2节——容器安装部署

69. 第六章容器6.1.3节——Docker常用命令

70. 第六章容器6.1.4节——Docker核心技术LXC

71. 第六章容器6.1.5节——Docker核心技术Namespace

72. 第六章容器6.1.6节—— Docker核心技术Chroot

73. 第六章容器6.1.7.1节——Docker核心技术cgroups综述

74. 第六章容器6.1.7.2节——cgroups原理剖析

75. 第六章容器6.1.7.3节——cgroups数据结构剖析

76. 第六章容器6.1.7.4节——cgroups使用

77. 第六章容器6.1.8节——Docker核心技术UnionFS

78. 第六章容器6.1.9节——Docker镜像技术剖析

79. 第六章容器6.1.10节——DockerFile解析

80. 第六章容器6.1.11节——docker-compose容器编排

81. 第六章容器6.1.12节——Docker网络模型设计

82. 第六章容器6.2.1节——Kubernetes概述

83. 第六章容器6.2.2节——K8S架构剖析

84. 第六章容器6.3.1节——K8S核心组件总述

85. 第六章容器6.3.2节——API Server组件

86. 第六章容器6.3.3节——Kube-Scheduler使用篇

87. 第六章容器6.3.4节——etcd组件

88. 第六章容器6.3.5节——Controller Manager概述

89. 第六章容器6.3.6节——kubelet组件

90. 第六章容器6.3.7节——命令行工具kubectl

91. 第六章容器6.3.8节——kube-proxy

92.  第六章容器6.4.1节——K8S资源对象总览

93. 第六章容器6.4.2.1节——pod详解

94. 第六章容器6.4.2.2节——Pod使用(上)

95. 第六章容器6.4.2.3节——Pod使用(下)

96. 第六章容器6.4.3节——ReplicationController

97. 第六章容器6.4.4节——ReplicaSet组件

98. 第六章容器基础6.4.5.1节——Deployment概述

99. 第六章容器基础6.4.5.2节——Deployment配置详细说明

100. 第六章容器基础6.4.5.3节——Deployment实现原理解析

101. 第六章容器基础6.4.6节——Daemonset

102. 第六章容器基础6.4.7节——Job

103. 第六章容器基础6.4.8节——CronJob

104. 第六章容器基础6.4.9.1节——Service综述

105. 第六章容器基础6.4.9.2节——使用 Service 连接到应用

106. 第六章容器基础6.4.9.3节——Service拓扑感知

107. 第六章容器基础6.4.10.1节——StatefulSet概述

108. 第六章容器基础6.4.10.2节——StatefulSet常规操作实操

109. 第六章容器基础6.4.10.3节——StatefulSet实操案例-部署WordPress 和 MySQL

110. 第六章容器基础6.4.10.4节——StatefulSet实操案例-使用 StatefulSet 部署Cassandra

111. 第六章容器基础6.4.10.5节——Statefulset原理剖析

112. 第六章容器基础6.4.11.1节——Ingress综述