十一【Kubernetes】K8s笔记：Ingress 集群进出流量总管( 三 ) _生活百科

部署 Ingress Controller 不需要我们自己从头编写 Deployment，Nginx 已经为我们提供了示例 YAML （位置是：kubernetes-ingress/deployments/deployment/nginx-ingress.yaml），现在我们对其进行一些小小的改动：

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

apiVersion: apps/v1kind: Deploymentmetadata:name: ngx-ing-depnamespace: nginx-ingressspec:replicas: 1selector:matchLabels:app: ngx-ing-deptemplate:metadata:labels:app: ngx-ing-depspec:serviceAccountName: nginx-ingressautomountServiceAccountToken: truecontainers:- image: nginx/nginx-ingress:2.2-alpineimagePullPolicy: IfNotPresentname: nginx-ingressports:- name: httpcontainerPort: 80- name: httpscontainerPort: 443- name: readiness-portcontainerPort: 8081- name: prometheuscontainerPort: 9113readinessProbe:httpGet:path: /nginx-readyport: readiness-portperiodSeconds: 1resources:requests:cpu: "100m"memory: "128Mi"securityContext:allowPrivilegeEscalation: truerunAsUser: 101 #nginxrunAsNonRoot: truecapabilities:drop:- ALLadd:- NET_BIND_SERVICEenv:- name: POD_NAMESPACEvalueFrom:fieldRef:fieldPath: metadata.namespace- name: POD_NAMEvalueFrom:fieldRef:fieldPath: metadata.nameargs:- -nginx-configmaps=$(POD_NAMESPACE)/nginx-config- -default-server-tls-secret=$(POD_NAMESPACE)/default-server-secret- -ingress-class=ngx-ink

有了 Ingress Controller，这些 API 对象的关联就更复杂了。然后我们创建对象：
$ kubectl apply -f ngx-ing-dep.yamldeployment.apps/ngx-ing-dep created注意 Ingress Controller 位于名字空间 nginx-ingress ，所以查看状态需要用 -n 参数显式指定，否则我们只能看到 default 名字空间里的 Pod：

$ kubectl get deploy -n nginx-ingressNAMEREADYUP-TO-DATEAVAILABLEAGEngx-ing-dep1/11110m$ kubectl get pod -n nginx-ingressNAMEREADYSTATUSRESTARTSAGEngx-ing-dep-7c48c74865-vzmnf1/1Running011m

现在 Ingress Controller 就算是运行起来了。还有最后一道工序，因为 Ingress Controller 本身也是一个 Pod，想要向外提供服务还是要依赖于 Service 对象。所以至少还要再为它定义一个 Service，使用 NodePort 或者 LoadBalancer 暴露端口，才能真正把集群的内外流量打通。
这里还有个取巧的办法，使用 kubectl port-forward 直接把本地的端口映射到 Kubernetes 集群的某个 Pod 里，在测试验证的时候非常方便。
$ kubectl port-forward -n nginx-ingress ngx-ing-dep-7c48c74865-vzmnf 8080:80 &可以修改 /etc/hosts 来手工添加域名解析，也可以使用 --resolve 参数，指定域名的解析规则，比如在这里把 ngx.test 强制解析到 127.0.0.1，也就是被 kubectl port-forward 转发的本地地址。
和 Service 一样， Ingress 把请求转发到了集群内部的 Pod，但 Ingress 的路由规则不再是 IP 地址，而是 HTTP 协议里的域名、URI 等要素。
再补充一点，目前的 Kubernetes 流量管理功能主要集中在 Ingress Controller 上，已经远不止于管理“入口流量”了，它还能管理“出口流量”，也就是 egress ，甚至还可以管理集群内部服务之间的“东西向流量” 。此外，Ingress Controller 通常还有很多的其他功能，比如 TLS 终止、网络应用防火墙、限流限速、流量拆分、身份认证、访问控制等等，完全可以认为它是一个全功能的反向代理或者网关。
【十一【Kubernetes】K8s笔记：Ingress 集群进出流量总管】