【概念说明】
Service 的功能和运行机制，主要由 kube-proxy 控制的四层负载均衡，即根据IP、PORT来做负载均衡。而很多应用都是在7层做均衡更为合理，比如根据主机名、URI、请求头、证书，做更高级准确的路由。另外，Service 还有一个缺点，它比较适合代理集群内部的服务。如果想要把服务暴露到集群外部，就只能使用 NodePort 或者 LoadBalancer 这两种方式，而它们都缺乏足够的灵活性，难以管控。既然 Service 是四层的负载均衡，那么再来一个七层负载均衡的PI对象的想法，就应运而生了，这就是Ingress。这个对象还应该承担更多的职责，也就是作为流量的总入口，统管集群的进出口数据，“扇入”“扇出”流量（也就是我们常说的“南北向”），让外部用户能够安全、顺畅、便捷地访问内部服务。
【Ingress Controller】
Ingress 可以说是在七层上另一种形式的 Service，它同样会代理一些后端的 Pod，也有一些路由规则来定义流量应该如何分配、转发，只不过这些规则都使用的是 HTTP/HTTPS 协议。Service 本身是没有服务能力的，它只是一些 iptables 规则，真正配置、应用这些规则的实际上是节点里的 kube-proxy 组件。同样的，Ingress 也只是一些 HTTP 路由规则的集合，相当于一份静态的描述文件，真正要把这些规则在集群里实施运行，还需要有Ingress Controller，它的作用就相当于 Service 的 kube-proxy，能够读取、应用 Ingress 规则，处理、调度流量。
由于 Ingress Controller 要做的事情太多，与上层业务联系太密切，所以 Kubernetes 把 Ingress Controller 的实现交给了社区，任何人都可以开发 Ingress Controller，只要遵守 Ingress 规则就好。从 Ingress Controller 的描述上我们也可以看到，HTTP 层面的流量管理、安全控制等功能其实就是经典的反向代理，而 Nginx 则是其中稳定性最好、性能最高的产品，所以它也理所当然成为了 Kubernetes 里应用得最广泛的 Ingress Controller。下面的这张图就来自 Nginx 官网，比较清楚地展示了 Ingress Controller 在 Kubernetes 集群里的地位：
【IngressClass】
随着 Ingress 在实践中的大量应用，很多用户发现这种用法会带来一些问题，比如：由于某些原因，项目组需要引入不同的 Ingress Controller，但 Kubernetes 不允许这样做；Ingress 规则太多，都交给一个 Ingress Controller 处理会让它不堪重负；多个 Ingress 对象没有很好的逻辑分组方式，管理和维护成本很高；集群里有不同的租户，他们对 Ingress 的需求差异很大甚至有冲突，无法部署在同一个 Ingress Controller 上。
所以，Kubernetes 就又提出了一个 Ingress Class 的概念，让它插在 Ingress 和 Ingress Controller 中间，作为流量规则和控制器的协调人，解除了 Ingress 和 Ingress Controller 的强绑定关系。Kubernetes 用户可以转向管理 Ingress Class，用它来定义不同的业务逻辑分组，简化 Ingress 规则的复杂度。比如说，我们可以用 Class A 处理博客流量、Class B 处理短视频流量、Class C 处理购物流量。
【用YAML描述Ingress/Ingress Class】
1、使用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
可以看到，Ingress 和 Ingress Class 的 apiVersion 都是“networking.k8s.io/v1”，而且 Ingress 有一个简写“ing”，但 Ingress Controller 怎么找不到呢？ 这是因为 Ingress Controller 和其他两个对象不太一样，它不只是描述文件，是一个要实际干活、处理流量的应用程序，而应用程序在 Kubernetes 里早就有对象来管理了，那就是 Deployment 和 DaemonSet，所以我们只需要再学习 Ingress 和 Ingress Class 的的用法就可以了。
1、Ingress：
1）--class，指定 Ingress 从属的 Ingress Class 对象；
2）--rule，指定路由规则，基本形式是“URI=Service”，也就是说是访问 HTTP 路径就转发到对应的 Service 对象，再由 Service 对象转发给后端的 Pod。
生成yaml样板间如下。
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-ing
spec:
ingressClassName: ngx-ink
rules:
- host: ngx.test
http:
paths:
- path: /
pathType: Exact
backend:
service:
name: ngx-svc
port:
number: 80
2、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-ink spec: controller: nginx.org/ingress-controller
3）Ingress、IngressClass、IngressController的关系示意图：
【K8S使用Ingress/Ingress Class】
因为 Ingress Class 很小，所以可以把它与 Ingress 合成了一个 YAML 文件。以下是用 kubectl apply 创建这两个对象：
1、copy上面的ingress.yml，然后kubectl apply -f ingress.yml；
2、查看ing对象状态：
3、describe信息如下。Ingress 对象的路由规则 Host/Path 就是在 YAML 里设置的域名“ngx.test/”，而且已经关联了前一节课里面的 Service 对象，还有 Service 后面的两个 Pod。那么访问这个域名，就会转发到对应的service，再由service转发给后端的pod。其中，“Default backend”的作用是，在找不到路由的时候，它被设计用来提供一个默认的后端服务，但不设置也不会有什么问题，所以大多数时候可以忽略它。
【K8S使用Ingress Controller】
准备好了 做规则说明的Ingress 和 Ingress Class，接下来我们就需要部署真正处理路由规则的 Ingress Controller。它以 Pod 的形式运行在 Kubernetes 里，所以同时支持 Deployment 和 DaemonSet 两种部署方式。
Nginx Ingress Controller 的安装有很多个 YAML 需要执行，但如果只是做简单的试验，就只需要用到 4 个 YAML。可以在GitHub 上找到 Nginx Ingress Controller 的项目（https://github.com/nginxinc/kubernetes-ingress），有deploy和ds两种部署方式，实验中选择deploy，然后相关YAML可以在这里找到：（https://github.com/chronolaw/k8s_study/tree/master/ingress）
kubectl apply -f common/ns-and-sa.yaml kubectl apply -f rbac/rbac.yaml kubectl apply -f common/nginx-config.yaml kubectl apply -f common/default-server-secret.yaml
（由于时间较晚，并且写了也背不下来，我后面的就先贴在这里，不整理为笔记了。）
部署 Ingress Controller 不需要我们自己从头编写 Deployment，Nginx 已经为我们提供了示例 YAML，但创建之前为了适配我们自己的应用还必须要做几处小改动：
1）metadata 里的 name 要改成自己的名字，比如 ngx-kic-dep；
2）spec.selector 和 template.metadata.labels 也要修改成自己的名字，比如还是用 ngx-kic-dep；
3）containers.image 可以改用 apline 版本，加快下载速度，比如 nginx/nginx-ingress:2.2-alpine；
4）最下面的 args 要加上 -ingress-class=ngx-ink，也就是前面创建的 Ingress Class 的名字，这是让 Ingress Controller 管理 Ingress 的关键。
修改完之后，Ingress Controller 的 YAML 大概是这个样子：
apiVersion: apps/v1
kind: Deployment
metadata:
name: ngx-kic-dep
namespace: nginx-ingress
spec:
replicas: 1
selector:
matchLabels:
app: ngx-kic-dep
template:
metadata:
labels:
app: ngx-kic-dep
...
spec:
containers:
- image: nginx/nginx-ingress:2.2-alpine
...
args:
- -ingress-class=ngx-ink
关联图如下：
修改完毕，运行：
kubectl apply -f kic.yml
kubectl get deploy -n nginx-ingress kubectl get pod -n nginx-ingress
此时Ingress Controller已经运行。不过还有最后一道工序，因为 Ingress Controller 本身也是一个 Pod，想要向外提供服务还是要依赖于 Service 对象。所以还要再为它定义一个 Service，使用 NodePort 或者 LoadBalancer 暴露端口，才能真正把集群的内外流量打通。
标签：Ingress,Service,kubernetes,chrono,ingress,Controller,ngx,Class From： https://www.cnblogs.com/1234roro/p/17102116.html