k8s05- Ingress Controller 的安装部署

• 1、Ingress Controller 的实现方案
• 2、安装
• 3、部署
  • 3.1 Deployment+Service(NodePort)
  • 3.2、DaemonSet+HostNetwork+nodeSelector
  • 3.3 Nodeport 和 HostNetwork 方案的比较
• 参考

Ingress controller的安装部署是分为两步
第一步：安装，在 k8s 集群里安装这个组件；
第二步：部署，如何把这个集群里的组件暴露到外部以供调用
经过第一步和第二步，就在k8s集群的内外交界处搭起了一座沟通的桥梁。

1、Ingress Controller 的实现方案

Ingress Controller 只是一个抽象的统称，其实现的方案有如下：

• Ingress NGINX：Kubernetes 官方维护的方案，也是本次安装使用的 Controller。
• F5 BIG-IP Controller：F5 所开发的 Controller，它能够管理员通过 CLI 或 API 让 Kubernetes 与 OpenShift 管理 F5 BIG-IP 设备。
• Ingress Kong： 著名的开源 API Gateway 方案所维护的 Kubernetes Ingress Controller。
• Traefik: 是一套开源的 HTTP 反向代理与负载均衡器，而它也支援了 Ingress。
• Voyager: 一套以 HAProxy 为底的 Ingress Controller。
  
  

NOTE：Ingress NGINX 是本文中安装部署的对象，以下所有的Ingress Controller均指Ingress NGINX方案

2、安装

ingress-controller 官方文档：https://kubernetes.github.io/ingress-nginx/deploy/
部署非常简单

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.5.1/deploy/static/provider/cloud/deploy.yaml

这里做了一些的修改

• 集群内有2个worker所以这里增加副本数为2
• 使用 hostNetwork 方式
  

最好提前拉取镜像，如果网络不能直接访问镜像，建议修改到私有仓库

知识点：

默认的镜像拉取策略是 IfNotPresent：
在镜像已经存在的情况下， kubelet 将不再去拉取镜像。 如果希望强制总是拉取镜像，你可以执行以下操作之一：
设置容器的 imagePullPolicy 为 Always。
省略 imagePullPolicy，并使用 :latest 作为要使用的镜像的标签。
省略 imagePullPolicy 和要使用的镜像标签。
启用 AlwaysPullImages 准入控制器（Admission Controller）。
如果 imagePullPolicy 未被定义为特定的值，也会被设置为 Always

3、部署

部署ingress controller有很多方式，以下举例了三种常见的方式：

Deployment+Service(NodePort)
DaemonSet+HostNetwork+nodeSelector
Deployment+Service(LoadBalancer)

3.1 Deployment+Service(NodePort)

nodePort的部署思路:

• 首先在所有的节点之上提供一个nodeport service，
• 然后在每个节点上开辟nodePort的端口（该端口为宿主机的端口），
• 通过nodeport service将流量引入进来到任意一个节点上，如果该节点没有部署ingress controller容器，那么就通过iptables将流量转发到ingress-controller容器中(图中的nginx容器)，
• 而后由nginx根据ingress的规则进行判断，将其转发到对应的应用web容器中。

需要注意的是，ingress controller容器可以部署在其中一个node节点或者master节点上（不建议），也可以部署到所有的node节点和master节点上。后者的好处是，可以减少一次NAT的网络流量转发，提高效率；缺点也显而易见，在资源有限的情况下无法在每个节点都部署一个ingress controller容器。

该部署方式的 svc yaml 文件 ingress-controller-nodeport-svc.yaml。
在node节点上开一个30080端口作为nodeport，暴露给集群外部。

外部访问方式： http://nodeport_ip:30080/url

3.2、DaemonSet+HostNetwork+nodeSelector

HostNetwork的部署思路：

• 在每个节点创建一个ingress controller容器
• 将这些容器的网络模式设为hostNetwork（这会导致每个节点的80和443端口都会被ingress controller容器占用）
• 当外部流量通过节点的80/443端口进来后，都会进入到ingress controller容器里，而后nginx根据ingress规则再将流量转发到对应的web应用容器中。相比较与nodePort模式，hostNetwork模式不需要创建一个svc来统一收口流量，而是让各个节点自行转发流量。
  

该方案部署，需要修改ingress-controller-hostport-svc.yaml

删除 kind.Deployment.spec.replicas: 1
修改 kind.Deployment 为 kind.DeamonSet
添加 kind.DeamonSet.spec.template.spec.hostNetwork: true

外部访问方式：http://nodeport_ip/url

知识点：什么是DeamonSet部署？

DaemonSet 确保全部（或者某些）节点上运行一个 Pod 的副本。 当有节点加入集群时， 也会为他们新增一个 Pod 。 当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。

https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/daemonset/


知识点：为什么要用DeamonSet部署？

结合 DaemonSet 的定义和 hostNetwork 的部署思路，我们可以看到，利用 DaemonSet 可以很方便的实现：
在所有的节点上都部署一个i ngress controller 容器的副本。
当然，也可以利用 K8S 的标签选择器，在指定的一个或多个节点上部署 ingress controller 容器的副本。操作如下：

• 首先给需要部署ingress controller容器的节点(如node-1)打上标签
  $ kubectl label node node-1 isIngressController="true"

• 修改 yaml:
  kind.DeamonSet.spec.template.spec.NodeSelector: kubernetes.io/os: linux
  为
  kind.DeamonSet.spec.template.spec.NodeSelector: isIngressController="true"

3.3 Nodeport 和 HostNetwork 方案的比较

参考

https://kubernetes.github.io/ingress-nginx/deploy/baremetal/