本篇是基于k8s-v1.15.0版本，在现有集群上部署ingress。
K8s集群对外暴露服务的方式目前只有三种：Loadblancer；Nodeport；ingress
前两种熟悉起来比较快，而且使用起来也比较方便，在此就不进行介绍了。
下面详细讲解下ingress这个服务，ingress由两部分组成：
ingress controller：将新加入的Ingress转化成Nginx的
配置文件并使之生效
ingress服务：将Nginx的
配置抽象成一个Ingress对象，每添加一个新的服务只需写一个新的Ingress的yaml
文件即可
其中ingress controller目前主要有两种：基于nginx服务的ingress controller和基于traefik的ingress controller。
而其中traefik的ingress controller，目前支持http和https协议。由于对nginx比较熟悉，而且需要使用TCP负载，所以在此我们选择的是基于nginx服务的ingress controller。
但是基于nginx服务的ingress controller根据不同的开发公司，又分为k8s社区的ingres-nginx和nginx公司的nginx-ingress。
在此根据github上的活跃度和关注人数，我们选择的是k8s社区的ingres-nginx。
k8s社区提供的ingress，github地址如下：https://github.com/kubernetes/ingress-nginx
nginx社区提供的ingress，github地址如下：https://github.com/nginxinc/kubernetes-ingress
2、ingress的工作原理
ingress具体的工作原理如下:
step1：ingress contronler通过与k8s的api进行交互，动态的去感知k8s集群中ingress服务规则的变化，然后读取它，并按照定义的ingress规则，转发到k8s集群中对应的service。
step2：而这个ingress规则写明了哪个域名对应k8s集群中的哪个service，然后再根据ingress-controller中的nginx配置模板，生成一段对应的nginx配置。
step3：然后再把该配置动态的写到ingress-controller的pod里，该ingress-controller的pod里面运行着一个nginx服务，控制器会把生成的nginx配置写入到nginx的配置文件中，然后reload一下，使其配置生效,以此来达到域名分配置及动态更新的效果。
3、ingress可以解决的问题
1）动态配置服务
如果按照传统方式, 当新增加一个服务时, 我们可能需要在流量入口加一个反向代理指向我们新的k8s服务. 而如果用了Ingress, 只需要配置好这个服务, 当服务启动时, 会自动注册到Ingress的中, 不需要而外的操作。
2）减少不必要的端口暴露
配置过k8s的都清楚, 第一步是要关闭防火墙的, 主要原因是k8s的很多服务会以NodePort方式映射出去, 这样就相当于给宿主机打了很多孔, 既不安全也不优雅. 而Ingress可以避免这个问题, 除了Ingress自身服务可能需要映射出去, 其他服务都不要用NodePort方式。
4、部署ingress（deployment的方式）
1）配置文件准备（粘贴下面网址的yanl文件）
github连接地址：
https://github.com/kubernetes/ingress-nginx/blob/master/deploy/static/mandatory.yaml
或者
https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/mandatory.yaml
2）配置文件介绍和设置ingress的网络模式
1> namespace.yaml
创建一个独立的命名空间 ingress-nginx。
2> configmap.yaml
ConfigMap是存储通用的配置变量的，类似于配置文件，使用户可以将分布式系统中用于不同模块的环境变量统一到一个对象中管理；而它与配置文件的区别在于它是存在集群的“环境”中的，并且支持K8S集群中所有通用的操作调用方式。
从数据角度来看，ConfigMap的类型只是键值组，用于存储被Pod或者其他资源对象（如RC）访问的信息。这与secret的设计理念有异曲同工之妙，主要区别在于ConfigMap通常不用于存储敏感信息，而只存储简单的文本信息。
ConfigMap可以保存环境变量的属性，也可以保存配置文件。
创建pod时，对configmap进行绑定，pod内的应用可以直接引用ConfigMap的配置。相当于configmap为应用/运行环境封装配置。
pod使用ConfigMap，通常用于：
设置环境变量的值、设置命令行参数、创建配置文件。
3> default-backend.yaml
如果外界访问的域名不存在的话，则默认转发到default-http-backend这个Service，其会直接返回404。
4> rbac.yaml
负责Ingress的RBAC授权的控制，其创建了Ingress用到的ServiceAccount、ClusterRole、Role、RoleBinding、ClusterRoleBinding。
5> with-rbac.yaml
是Ingress的核心，用于创建ingress-controller。前面提到过，ingress-controller的作用是将新加入的Ingress进行转化为Nginx的配置。
6> 各文件的作用：
configmap.yaml:提供configmap可以在线更新nginx的配置
default-backend.yaml:提供一个缺省的后台错误页面 404
namespace.yaml:创建一个独立的命名空间 ingress-nginx
rbac.yaml:创建对应的role rolebinding 用于rbac
tcp-services-configmap.yaml:修改L4负载均衡配置的configmap
udp-services-configmap.yaml:修改L4负载均衡配置的configmap
with-rbac.yaml:有应用rbac的nginx-ingress-controller组件
3）修改配置文件
设置 hostNetwork: true
由于ingress 使用到物理机的80/443 端口，所以需要设置为hostNetwork模式
4）拉取镜像（通过查看ingress的yaml文件可以看出）和创建svc文件
拉取镜像
docker pull quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.30.0
或者
docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/nginx-ingress-controller:0.30.0
kubectl apply -f mandatory.yaml
创建svc：https://github.com/kubernetes/ingress-nginx/blob/master/deploy/baremetal/service-nodeport.yaml
5）指定运行节点（需要打标签）
nginx-ingress-controller会随意选择一个node节点运行pod，为此需要我们把nginx-ingress-controller运行到指定的node节点上
首先需要给需要运行nginx-ingress-controller的node节点打标签，在此我们把nginx-ingress-controller运行在指定的node节点上
kubectl get nodes –show-labels #先查看各个node上的lables信息
kubectl label nodes node3 nginx=nginx #给node3打标签
kubectl get nodes –show-labels #查看node3上的lables
修改ingress的yaml文件中的标签
5、部署ingress（DaemonSet的方式）
官方原始文件使用的是deployment，replicate 为 1，这样将会在某一台节点上启动对应的nginx-ingress-controller pod。外部流量访问至该节点，由该节点负载分担至内部的service。测试环境考虑防止单点故障，改为DaemonSet然后删掉replicate ，配合亲和性部署在制定节点上启动nginx-ingress-controller pod，确保有多个节点启动nginx-ingress-controller pod，后续将这些节点加入到外部硬件负载均衡组实现高可用性。
1）添加hostNetwork
true：添加该字段，暴露nginx-ingress-controller pod的服务端口（80）
2）添加亲和性属性
增加亲和性部署，有custom/ingress-controller-ready 标签的节点才会部署该DaemonSet
3）设置节点的label
kubectl label nodes node2 custem/ingress-controller-ready=true
kubectl label nodes node3 custem/ingress-controller-ready=true
kubectl label nodes node4 custem/ingress-controller-ready=true
4）修改yaml文件（和deployment部署ingress的文件一样，只需要修改此处即可）
4）执行并部署ingress
完整版文件如下
cat mandatory-deamon.yaml
apiVersion: v1
kind: Namespace
metadata:
name: ingress-nginx
labels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
—
kind: ConfigMap
apiVersion: v1
metadata:
name: nginx-configuration
namespace: ingress-nginx
labels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
—
kind: ConfigMap
apiVersion: v1
metadata:
name: tcp-services
namespace: ingress-nginx
labels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
—
kind: ConfigMap
apiVersion: v1
metadata:
name: udp-services
namespace: ingress-nginx
labels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
—
apiVersion: v1
kind: ServiceAccount
metadata:
name: nginx-ingress-serviceaccount
namespace: ingress-nginx
labels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
—
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
name: nginx-ingress-clusterrole
labels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
rules:
– apiGroups:
– “”
resources:
– configmaps
– endpoints
– nodes
– pods
– secrets
verbs:
– list
– watch
– apiGroups:
– “”
resources:
– nodes
verbs:
– get
– apiGroups:
– “”
resources:
– services
verbs:
– get
– list
– watch
– apiGroups:
– “”
resources:
– events
verbs:
– create
– patch
– apiGroups:
– “extensions”
– “networking.k8s.io”
resources:
– ingresses
verbs:
– get
– list
– watch
– apiGroups:
– “extensions”
– “networking.k8s.io”
resources:
– ingresses/status
verbs:
– update
—
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
name: nginx-ingress-role
namespace: ingress-nginx
labels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
rules:
– apiGroups:
– “”
resources:
– configmaps
– pods
– secrets
– namespaces
verbs:
– get
– apiGroups:
– “”
resources:
– configmaps
resourceNames:
# Defaults to “<election-id>-<ingress-class>”
# Here: “<ingress-controller-leader>-<nginx>”
# This has to be adapted if you change either parameter
# when launching the nginx-ingress-controller.
– “ingress-controller-leader-nginx”
verbs:
– get
– update
– apiGroups:
– “”
resources:
– configmaps
verbs:
– create
– apiGroups:
– “”
resources:
– endpoints
verbs:
– get
—
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
name: nginx-ingress-role-nisa-binding
namespace: ingress-nginx
labels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: nginx-ingress-role
subjects:
– kind: ServiceAccount
name: nginx-ingress-serviceaccount
namespace: ingress-nginx
—
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: nginx-ingress-clusterrole-nisa-binding
labels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: nginx-ingress-clusterrole
subjects:
– kind: ServiceAccount
name: nginx-ingress-serviceaccount
namespace: ingress-nginx
—
apiVersion: apps/v1
#kind: Deployment
kind: DaemonSet
metadata:
name: nginx-ingress-controller
namespace: ingress-nginx
labels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
spec:
# replicas: 2
selector:
matchLabels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
template:
metadata:
labels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
annotations:
prometheus.io/port: “10254”
prometheus.io/scrape: “true”
spec:
hostNetwork: true
# wait up to five minutes for the drain of connections
terminationGracePeriodSeconds: 300
serviceAccountName: nginx-ingress-serviceaccount
nodeSelector:
kubernetes.io/os: linux
custem/ingress-controller-ready: “true”
tolerations:
– key: “kubernetes.io/os”
operator: “Equal”
value: “linux”
effect: “NoSchedule”
containers:
– name: nginx-ingress-controller
image: www.my.com/k8s/nginx-ingress-controller:0.30.0
args:
– /nginx-ingress-controller
– –configmap=$(POD_NAMESPACE)/nginx-configuration
– –tcp-services-configmap=$(POD_NAMESPACE)/tcp-services
– –udp-services-configmap=$(POD_NAMESPACE)/udp-services
– –publish-service=$(POD_NAMESPACE)/ingress-nginx
– –annotations-prefix=nginx.ingress.kubernetes.io
securityContext:
allowPrivilegeEscalation: true
capabilities:
drop:
– ALL
add:
– NET_BIND_SERVICE
# www-data -> 101
runAsUser: 101
env:
– name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
– name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
ports:
– name: http
containerPort: 80
protocol: TCP
– name: https
containerPort: 443
protocol: TCP
livenessProbe:
failureThreshold: 3
httpGet:
path: /healthz
port: 10254
scheme: HTTP
initialDelaySeconds: 10
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 10
readinessProbe:
failureThreshold: 3
httpGet:
path: /healthz
port: 10254
scheme: HTTP
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 10
lifecycle:
preStop:
exec:
command:
– /wait-shutdown
—
apiVersion: v1
kind: LimitRange
metadata:
name: ingress-nginx
namespace: ingress-nginx
labels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
spec:
limits:
– min:
memory: 90Mi
cpu: 100m
type: Container
kubectl apply -f mandatory-deamon.yaml
kubectl get ds -n ingress-nginx
kubectl get pod -n ingress-nginx -o wide
注意：大家可能会想node2上也打了标签，为什么node2上没有；原因很简单，我的node2是master，已经有了污点的标签，从亲和性上就已经不再容忍任何pod运行到master上，所以只能看到node3和node4上有nginx-ingress的pod。
6、案例测试
1）创建deployment模板并修改
kubectl create deployment httpd –image=www.my.com/web/httpd:latest –dry-run -o yaml > http-dep.yaml
2）创建svc模板并修改
kubectl expose deployment httpd –port=8000 –target-port=80 –type=ClusterIP –dry-run -o yaml > http-svc.yaml
3）测试访问
curl 10.1.95.78:8000
4）创建ingress
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: httpd
namespace: default
spec:
rules:
– host: www.http123.com
http:
paths:
– path: /
backend:
serviceName: httpd
servicePort: 8000
5）绑定hosts，浏览器测试
也可以使用dns服务器，通过自建的dns服务器完成域名解析，从而避免频繁的修改hosts文件
详见轻量级域名解析服务器之dnsmasq
C:WindowsSystem32driversetchosts添加10.10.0.111 www.http123.com
总结
到此这篇关于k8s之ingress-nginx详解和部署方案的文章就介绍到这了,更多相关ingress-nginx部署方案内容请搜索服务器之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持服务器之家！
原文地址：https://blog.csdn.net/weixin_44729138/article/details/105978555
声明： 猿站网有关资源均来自网络搜集与网友提供，任何涉及商业盈利目的的均不得使用，否则产生的一切后果将由您自己承担！ 本平台资源仅供个人学习交流、测试使用 所有内容请在下载后24小时内删除，制止非法恶意传播，不对任何下载或转载者造成的危害负任何法律责任！也请大家支持、购置正版！ 。本站一律禁止以任何方式发布或转载任何违法的相关信息访客发现请向站长举报，会员发帖仅代表会员个人观点，并不代表本站赞同其观点和对其真实性负责。本网站的资源部分来源于网络，如有侵权烦请发送邮件至：2697268773@qq.com进行处理。
