kubernetes部署Ingress访问代理与负载均衡器
Kubernetes中的pod都有独立的内部IP(外部不可访问),通过Service可以对多个pod进行负载均衡和故障转移,Service可以具有ClusterIP、NodeIP或LoadBanlancer模式。目前,ClusterIP只能内部访问,需通过kubectl proxy代理出来,NodeIP是跟Node绑定的、迁移性差,LoadBanlancer的每个服务都有独立的IP地址,管理、使用不便。有没有一个固定的独立IP、自动节点漂 移的解决方案呢?以前这样的功能基本上都用Nginx来实现,现在Kubernetes有一个做好了的服务,也是基于Nginx的,就是Ingress。
==============================================================================
如何访问K8S中的服务:
1、Ingress介绍
Kubernetes 暴露服务的方式目前只有三种:LoadBlancer Service、NodePort Service、Ingress;前两种估计都应该很熟悉,下面详细的了解下这个 Ingress
Ingress由两部分组成:Ingress Controller 和 Ingress 服务。
Ingress Contronler 通过与 Kubernetes API 交互,动态的去感知集群中 Ingress 规则变化,然后读取它,按照自定义的规则,规则就是写明了哪个域名对应哪个service,生成一段 Nginx 配置,再写到 Nginx-ingress-control的 Pod 里,这个 Ingress Contronler 的pod里面运行着一个nginx服务,控制器会把生成的nginx配置写入/etc/nginx.conf文件中,然后 reload 一下 使用配置生效。以此来达到域名分配置及动态更新的问题。
看个简单的图方便理解:
ingress控制器有两种:nginx和haproxy 这里是以nginx为讲解。
2、部署一个Nginx Ingress
ingress的部署文件在github Ingress 仓库找到. 针对官方配置我们单独添加了 nodeselector 指定,绑定LB地址 以方便DNS 做解析。
主要用到的文件:
1 2 3 4 5 6 7 8 |
|
第一个是要部署RBAC文件:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 |
|
创建:
1 2 3 4 5 6 |
|
RBAC创建完后,就创建default backend服务:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 |
|
创建:
1 2 3 |
|
创建之后查看:
1 2 3 4 5 6 7 8 9 10 11 |
|
创建好default backend后就要创建nginx-ingress-controller了:
$ cat nginx-ingress-controller.yaml apiVersion: extensions/v1beta1 kind: Deployment metadata: name: nginx-ingress-controller labels: k8s-app: nginx-ingress-controller namespace: kube-system spec: replicas: 1 template: metadata: labels: k8s-app: nginx-ingress-controller spec: # hostNetwork makes it possible to use ipv6 and to preserve the source IP correctly regardless of docker configuration # however, it is not a hard dependency of the nginx-ingress-controller itself and it may cause issues if port 10254 already is taken on the host # that said, since hostPort is broken on CNI (https://github.com/kubernetes/kubernetes/issues/31307) we have to use hostNetwork where CNI is used # like with kubeadm # hostNetwork: true #注释表示不使用宿主机的80口, terminationGracePeriodSeconds: 60 hostNetwork: true #表示容器使用和宿主机一样的网络 serviceAccountName: nginx-ingress-serviceaccount #引用前面创建的serviceacount containers: - image: gcr.io/google_containers/nginx-ingress-controller:0.9.0-beta.1 #容器使用的镜像 name: nginx-ingress-controller #容器名 readinessProbe: #启动这个服务时要验证/healthz 端口10254会在运行的node上监听。 httpGet: path: /healthz port: 10254 scheme: HTTP livenessProbe: httpGet: path: /healthz port: 10254 scheme: HTTP initialDelaySeconds: 10 #每隔10做健康检查 timeoutSeconds: 1 ports: - containerPort: 80 hostPort: 80 #80映射到80 - containerPort: 443 hostPort: 443 env: - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace args: - /nginx-ingress-controller - --default-backend-service=$(POD_NAMESPACE)/default-http-backend # - --default-ssl-certificate=$(POD_NAMESPACE)/ingress-secret #这是启用Https时用的 nodeSelector: #指明运行在哪,此IP要和default backend是同一个IP kubernetes.io/hostname: 10.3.1.17 #上面映射到了hostport80,确保此IP80,443没有占用.
这个控制器就是一个deployment ,里面运行一个容器gcr.io/google_containers/nginx-ingress-controller:0.9.0-beta.1 ,有点像nginx容器,现在创建:
1 2 |
|
1 2 3 4 5 6 7 8 9 10 11 |
|
现在ingress controller 控制器已部署好了,那么如何使用了,那就要写一个ingress规则了,此处就以已存在的jenkins服务为例,配置如何使用域名访问这个service:
|
现在写个jenkins service的Ingress 规则:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
创建它:
$ kubectl create -f jenkins-ingress.yml ingress "jenkins-ingress" created $ kubectl get ingress NAME HOSTS ADDRESS PORTS AGE jenkins-ingress ingress.jenkins.com 80 10s
到这里就已经部署完成了,配置好域名后,就可以用此域名来访问了:
部署完成了,现在看下nginx-ingress-controller 里nginx配置文件发生了哪些变化:
upstream default-jenkinsservice-8080 { least_conn; server 172.30.10.15:8080 max_fails=0 fail_timeout=0; server 172.30.11.7:8080 max_fails=0 fail_timeout=0; } upstream upstream-default-backend { least_conn; server 172.30.11.6:8080 max_fails=0 fail_timeout=0; } server { server_name ingress.jenkins.com; listen [::]:80; location / { ... proxy_pass http://default-jenkinsservice-8080; ... } }
这些配置都是ingress-controller 自已写入的,动态更新就是它能通过K8S API感知到service的endpoint 发生了变化,然后修改nginx配置并执行reload.
至此,部署完成。
Ingress还有很多部署方式,比如配置https访问的, 以后再写。
本文转自开源中国-kubernetes部署Ingress访问代理与负载均衡器

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Kubernetes Nginx Ingress 安装与使用
目录 (Table of Contents) [TOCM] 概述 下载搭建环境所需要的镜像 配置default-http-bankend 配置inrgess-controller 配置需要测试的service 配置ingress 问题集 概述 用过kubernetes的人都知道,kubernetes的service的网络类型有三种:cluertip,nodeport,loadbanlance,各种类型的作用就不在这里描述了。如果一个service想向外部暴露服务,有nodeport和loadbanlance类型,但是nodeport类型,你的知道service对应的pod所在的node的ip,而loadbanlance通常需要第三方云服务商提供支持。如果没有第三方服务商服务的就没办法做了。除此之外还有很多其他的替代方式,以下我主要讲解的是通过ingress的方式来实现service的对外服务的暴露。 下载搭建环境所需要的镜像 gcr.io/google_containers/nginx-ingress-controller:0.8.3 (ingress controller 的镜像) ...
- 下一篇
kubernetes中port、target port、node port的对比分析,以及kube-proxy代理
容器网络实例 服务中的3个端口设置 这几个port的概念很容易混淆,比如创建如下service: [plain] view plain copy apiVersion: v1 kind: Service metadata: labels: name: app1 name: app1 namespace: default spec: type: NodePort ports: - <strong>port: 8080 targetPort: 8080 nodePort: 30062</strong> selector: name: app1 port The port that the service is exposed on the service’s cluster ip (virsual ip). Port is the service port which is accessed by others with cluster ip. 即,这里的port表示:service暴露在cluster ip上的端口,<cluster ip>:port ...
相关文章
文章评论
共有0条评论来说两句吧...