[系统集成] 用 Kubernetes Nginx Ingress 实现 HTTP 服务发布与负载均衡
时间： 12:53:23
&&&& 阅读：3508
&&&& 评论：
&&&& 收藏：0
标签：&&&&&&&&&&&&&&&&&&&&&&&&&&&用户在 Kubernetes 上部署的服务一般运行于私有网络，Pod和Service 提供了 hostPort，NodePort等参数用于暴露这些服务端口到K8S节点上，供使用者访问。这样的方法有明显缺点：
1）容易占用过多的主机端口；
2）服务端口暴露到多台主机会增加防火墙和安全配置的难度
3）默认的hostPort，NodePort方式没有负载均衡的作用
K8S的 Ingress 资源提供了另一种服务暴露的方法，它可以获取各个服务的状态，传递给nginx等工具进行配置修改、重新加载等工作，实现负载均衡、虚拟主机、SSL等功能。并且它只需要占用一台主机的80、443、8080三个端口就可以为所有HTTP服务实现上述功能。
关于nginx ingress的安装，K8S有相关说明，网上也有很多文档可参考：
/kubernetes/contrib/tree/master/ingress/controllers/nginx
在前期的安装中，按照官网的说明并没有成功，查阅了大量的文档，并结合自己的实践最终排除了问题、安装成功。下面分享一下我的安装过程。
1. 准备安装环境
2. 启用Kubernetes API 认证
http://kubernetes.io/docs/admin/authentication/
这一步不能忽略，否则nginx ingress无法启动；
还有几点要特别注意，否则nginx ingress启动时会出现TLS握手失败的错误：
1）必须生成serviceAccount证书
证书生成好后在/etc/kubernetes/的apiserver和controller-manager中启用
2）必须将clusterIP加入到server.crt
#Add Cluster IP of kubernetes to server.crtsubjectAltName=`kubectl get services --all-namespaces |grep ‘default‘|grep ‘kubernetes‘|grep ‘443‘|awk ‘{print $3}‘`echo subjectAltName=IP:${subjectAltName} & f
#According to the ca.key, ca.crt and server.csr generate the server.crt:openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -f -out server.crt -days 10000
3）更新证书后删除旧的 secret 和 serviceaccount
kubectl get secret --all-namespaces
kubectl get serviceaccount --all-namespaces
查看 default 开头的 secret 和 serviceaccount，将其删除，系统会自动重新生成
3. 安装 Nginx Ingress
注：为了显示 nginx_status，需要在80, 443 之外再暴露8080端口，同时部署一个configmap文件：
apiVersion: v1
kind: ConfigMap
name: nginx-load-balancer-conf
enable-vts-status: "true"
做完上述准备工作后，就可以按照官方文档进行安装了
下面使用 nginx ingress 对 kubernetes-dashboards 基于虚拟主机进行服务暴露，并增加HTTPS功能：
4.1 创建 dashboard secret
/kubernetes/contrib/blob/master/ingress/controllers/nginx/examples/tls/README.md
注意：创建密钥时，请填入虚拟主机名，比如：k8s-，如果名称与后面浏览器上实际访问的不一致，会被拒绝。
4.2 部署 dashboard
kind: Deployment
apiVersion: extensions/v1beta1
app: kubernetes-dashboard
version: v1.1.0
name: kubernetes-dashboard
namespace: kube-system
replicas: 1
matchLabels:
app: kubernetes-dashboard
app: kubernetes-dashboard
containers:
- name: kubernetes-dashboard
image: 172.31.17.36:5000/kubernetes-dashboard-amd64:v1.1.0
imagePullPolicy: IfNotPresent
- containerPort: 9090
protocol: TCP
# Uncomment the following line to manually specify Kubernetes API server Host
# If not specified, Dashboard will attempt to auto discover the API server and connect
# to it. Uncomment only if the default does not work.
- --apiserver-host=http://172.31.17.81:8080
livenessProbe:
port: 9090
initialDelaySeconds: 30
timeoutSeconds: 30
kind: Service
apiVersion: v1
app: kubernetes-dashboard
name: kubernetes-dashboard
namespace: kube-system
- port: 80
targetPort: 9090
app: kubernetes-dashboard
注：请将service 的port 设置为80
4.3 创建 dashboard Ingress 资源
apiVersion: extensions/v1beta1
kind: Ingress
name: k8s-dashboard
namespace: kube-system
secretName: k8s-dashboard-secret
- host: k8s-
- backend:
serviceName: kubernetes-dashboard
servicePort: 80
注：请设置 tls， 虚拟主机名，backend service等参数
4.4 设置 DNS 或 hosts文件
设置 k8s- 的IP
设置好后就可以通过 http://k8s- 或者 https://k8s- 来访问 dashboard 了。
nginx status：
&标签：&&&&&&&&&&&&&&&&&&&&&&&&&&&原文：/hahp/p/5694669.html
教程昨日排行
&&国之画&&&& &&&&&&
&& &&&&&&&&&&&&&&
鲁ICP备号-4
打开技术之扣，分享程序人生！应对新挑战！才云自研 Kubernetes 负载均衡器
应对新挑战！才云自研 Kubernetes 负载均衡器
猎奇小侦探
才云科技云开源软件工程师 章骏Kubernetes 在早期设计网络的时候就已经考虑了容器的服务发现和负载均衡。Kubernetes 为 pods 的逻辑集合抽象出了 Service资源，配合 Iptables 和 Cloud Provider 来为用户提供访问的入口，但是 Kubernetes 日益增长的用户规模和越来越复杂化的业务场景对负载均衡逐渐提出了新的挑战。才云科技在通过不断地实践探索及从社区获取的经验积累后，自主研发了 Kubernetes 的负载均衡器，来支持 Bare Metal 和 Public Cloud 环境。下面就让我们一起来看看才云的这次研究有什么新的发现与启迪。大纲介绍 Service介绍 Ingress介绍 Caicloud LoadbalancerKubernetes 如何对外暴露服务在云环境中，如 AWS、GCE, 可以使用Type=LoadBalancer 的 Service 使用 Type=NodePort 的 Service将 Pod 的 Port 映射到 Host 的 Port使用社区的 Service LoadBalancer 项目使用 Ingress何为 Service在 K8S 中，Service 是 Pods 的逻辑集合，它对外提供了访问这群 pod 的一种方式。目前 K8S 的 Sevice 都是通过 iptables来实现的。kube-proxy 将 service 的规则刷到 node 的 iptables 中，Client 通过 serviceIP+port 访问 service 时，经过 node 的 iptables 规则转发到真正的 endpoint pods。如下图:社区的 Service LoadBalancer这里简单提一下这个项目 （/kubernetes/contrib/tree/master/service-loadbalancer）。它旨在为 Bare Metal 环境提供类似于 Cloud Load Balancer 的功能, 而需要使用 Node Port 来在每个 Node 上都暴露一个端口来进行转发.这个 Controller 会在每个 Role=Loadbalancer Label 的 Node 上自动创建一个 Service-Loadbalancer Pod, 每个Service-Loadbalancer 包含以下功能:启动一个 Controller: Watch K8s Services and Endpoints启动一个 Load Balancer Manifest: 它会启动一个Load Balancer，这个 LB 是可插拔的, 很容易 从HAproxy 的实 现切换到类似于 F5 或者 Pound 的负载均衡器上一个配置模板, 因为不同的 Load Balancer Manifest 有不同的配置格式IngressIngress Ingress 介绍一般来说，Service 和 Pod 的 IP 地址只能在集群的网络中被路由，所有到达 Edge Router 的流量都会被丢弃或者转发到其他地方, 看起来像下面这样:Ingress 是一个规则的集合，它允许集群外的流量通过一定的规则到达集群内的 Service 。看起来像这样:Ingress ControllerIngress 只是一些规则，要达到上面的需求，还需要在集群内部部署一个 Ingress Controller 而 Ingress Controller 本质上是一个 Nginx/Haproxy 。要使用 Ingress 需要经过下面几步:在集群中部署 Ingress Controller， 假设 Ingress Controller 的 IP 是 178.91.123.132添加 Ingress 规则，如将
这个域名下的流量导到 serviceA:8080 ，将
的流量导到 serviceB:8080在请求方需要有域名解析服务将
解析到178.91.123.132Ingress 存在的问题Ingress 和 Ingress Controller 是 K8S 提供的非常棒的功能，但是使用下来有以下的问题:如何提供 Ingress Controller 本身的高可用。多个 Ingress Controller 如何同时对外提供服务。IngressController自动化运维,扩容缩容监控等。Caicloud LoadBalancerLoadBalancer Controller针对 Ingress 的问题，才云科技设计了自己的 LoadBalancer。在整个架构中，我们通过一个 LoadBalancer Admin 对外提供 RESTful api 来方便操作 LoadBalancer Third Party Resource (简称 LoadBalancer TPR)。由 LoadBalancer Controller list/watch LoadBalancer TPR, 然后根据 TPR 的 specification 去创建 Provider 和 Proxy(Ingress Controller)并对 Node 进行相应的操作。在这里引入了一个新的组件，LoadBalancer Provider，它是用来保证 Ingress Controller 入又的高可用。如在 Bare Metal 环境下，我们会在每个运行 Ingress Controller 的节点上， 使用 LVS/DR Provider 来将流量分发 到同一组的 Ingress Controller，同时这个 Provider 还需要保证 VIP 的高可用 而在云环境中，则可以使用云产商各自的 L4 负载来将流量分发到同一组 Ingress Controller，用 Provider 做一次 适配就 OK 了。LoadBalancer Controller 中包含了三种 Kubernetes Controller，分别为 Provider，Proxy，Node Controller，分别 管理各自关心的资源，互不影响。架构图如下:Bare Metal LoadBalancer在 Bare Metal 的环境下，我们选择了 LVS/DR 模式做 Provider，所有的流量通过 VIP, 经过 LVS 到达 Ingress Controller，由 Ingress Controller 来控制这些流量代理到对应的 Endpoint。在这个模式下有下面这些要点:Ingress Controller 运行在 Host 网络模式下DR 模式需要修改机器的 arp_ignore=1, arp_announce=2在 Node 上的 回路设备（lo）上添加VIP，将 Ingress Controller 作为 LVS 的 Real Server，DR 模式下需要 Real Server 机器持有 VIP在这种方案下，LVS 的 Director（Ipvs Provider）话则会导致流量死循环的问题。所以我们采用 Fwmark 来区分流量，对于从 Peer 节点转发来的 流量不应该再经过 Ipvs 规则。当然这个是我们使用了 Keepalived 引起的问题。公有云在公有云下就比较简单了，由 Provider 去适配公有云的 L4 层负载，由公有云的负载来负责将流量导流到 Ingress Controller。总结目前才云的 LoadBalancer 还处于 alpha 阶段，但是已经在我们内部的集群里面替换了原来的 Keepalived+HAproxy, 来为集群的多 Master 提供 HA 的支持，替换的过程中遇到了很多坑，但总算让它正确运行起来。后续 LoadBalancer 还需要添加更多的 Provider 来适配公有云，添加监控信息，增加弹性伸缩等功能。欢迎大家继续关注才云科技的这个项目。
本文仅代表作者观点，不代表百度立场。系作者授权百家号发表，未经许可不得转载。
猎奇小侦探
百家号 最近更新：
简介: 大千世界，探索未知事物，我们一起读懂未来
作者最新文章Kubernetes关于服务的暴露主要是通过NodePort方式，通过绑定minion主机的某个端口,然后进行pod的请求转发和负载均衡，但这种方式下缺陷是
Service可能有很多个，如果每个都绑定一个node主机端口的话，主机需要开放外围一堆的端口进行服务调用，管理混乱
无法应用很多公司要求的防火墙规则
理想的方式是通过一个外部的负载均衡器，绑定固定的端口，比如80,然后根据域名或者服务名向后面的Service ip转发,Nginx很好的解决了这个需求，但问题是如果有新的服务加入，如何去修改Nginx的配置，并且加载这些配置？ Kubernetes给出的方案就是Ingress,Ingress包含了两大主件Ingress Controller和Ingress.
Ingress解决的是新的服务加入后，域名和服务的对应问题，基本上是一个ingress的对象，通过yaml进行创建和更新进行加载。
Ingress Controller是将Ingress这种变化生成一段Nginx的配置，然后将这个配置通过Kubernetes API写到Nginx的Pod中，然后reload.
具体实现如下:
1.生成一个默认的后端，如果遇到解析不到的URL就转发到默认后端页面
[root@k8s-master ingress]# cat default-backend.yaml
apiVersion: extensions/v1beta1
kind: Deployment
name: default-http-backend
k8s-app: default-http-backend
namespace: kube-system
replicas: <span style="color: #
k8s-app: default-http-backend
terminationGracePeriodSeconds: <span style="color: #
containers:
- name: default-http-backend
# Any image is permissable as long as:
# <span style="color: #. It serves a <span style="color: #4 page at /
# <span style="color: #. It serves <span style="color: #0 on a /healthz endpoint
image: gcr.io/google_containers/defaultbackend:<span style="color: #.0
livenessProbe:
path: /healthz
port: <span style="color: #80
scheme: HTTP
initialDelaySeconds: <span style="color: #
timeoutSeconds: <span style="color: #
- containerPort: <span style="color: #80
resources:
memory: 20Mi
memory: 20Mi
apiVersion: v1
kind: Service
name: default-http-backend
namespace: kube-system
k8s-app: default-http-backend
- port: <span style="color: #
targetPort: <span style="color: #80
k8s-app: default-http-backend
2.部署Ingress Controller
具体文件可以参考官方的
/kubernetes/ingress/blob/master/examples/daemonset/nginx/nginx-ingress-daemonset.yaml
这里贴一个我的
[root@k8s-master ingress]# cat nginx-ingress-controller.yaml
apiVersion: v1
kind: ReplicationController
name: nginx-ingress-lb
name: nginx-ingress-lb
namespace: kube-system
replicas: <span style="color: #
name: nginx-ingress-lb
annotations:
prometheus.io/port: '<span style="color: #254'
prometheus.io/scrape: 'true'
terminationGracePeriodSeconds: <span style="color: #
hostNetwork: true
containers:
- image: gcr.io/google_containers/nginx-ingress-controller:<span style="color: #.9.<span style="color: #-beta.<span style="color: #
name: nginx-ingress-lb
readinessProbe:
path: /healthz
port: <span style="color: #254
scheme: HTTP
livenessProbe:
path: /healthz
port: <span style="color: #254
scheme: HTTP
initialDelaySeconds: <span style="color: #
timeoutSeconds: <span style="color: #
- containerPort: <span style="color: #
hostPort: <span style="color: #
- containerPort: <span style="color: #3
hostPort: <span style="color: #3
- name: POD_NAME
valueFrom:
fieldPath: metadata.name
- name: POD_NAMESPACE
valueFrom:
fieldPath: metadata.namespace
- name: KUBERNETES_MASTER
value: http://<span style="color: #2.168.0.105:8080
- /nginx-ingress-controller
- --default-backend-service=$(POD_NAMESPACE)/default-http-backend
- --apiserver-host=http://<span style="color: #2.168.0.105:8080
曾经出现的问题是，启动后pod总是在CrashLoopBack的状态，通过logs一看发现nginx-ingress-controller的启动总是去连接apiserver内部集群ip的443端口，导致因为安全问题不让启动，后来在args里面加入
- --apiserver-host=http://192.168.0.105:8080
后成功启动.
3.配置ingress
[root@k8s-master ingress]# cat dashboard-weblogic.yaml
apiVersion: extensions/v1beta1
kind: Ingress
name: dashboard-weblogic-ingress
namespace: kube-system
- host: helloworld.eric
- path: /console
serviceName: helloworldsvc
servicePort: <span style="color: #01
serviceName: kubernetes-dashboard
servicePort: <span style="color: #
host指虚拟出来的域名，具体地址(我理解应该是Ingress-controller那台Pod所在的主机的地址)应该加入/etc/hosts中,这样所有去helloworld.eric的请求都会发到nginx
path:/console匹配后面的应用路径
servicePort主要是定义服务的时候的端口，不是NodePort.
path:/ 匹配后面dashboard应用的路径,以前通过访问master节点8080/ui进入dashboard的，但dashboard其实是部署在minion节点中，实际是通过某个路由语句转发过去而已，dashboard真实路径如下:
而yaml文件是
[root@k8s-master ~]# cat kubernetes-dashboard.yaml
apiVersion: extensions/v1beta1
kind: Deployment
# Keep the name in sync with image version and
# gce/coreos/kube-manifests/addons/dashboard counterparts
name: kubernetes-dashboard-latest
namespace: kube-system
replicas: <span style="color: #
k8s-app: kubernetes-dashboard
version: latest
kubernetes.io/cluster-service: "true"
containers:
- name: kubernetes-dashboard
image: gcr.io/google_containers/kubernetes-dashboard-amd64:v1.<span style="color: #.1
resources:
# keep request = limit to keep this container in guaranteed class
memory: 50Mi
memory: 50Mi
- containerPort: <span style="color: #90
--apiserver-host=http://<span style="color: #2.168.0.105:8080
livenessProbe:
port: <span style="color: #90
initialDelaySeconds: <span style="color: #
timeoutSeconds: <span style="color: #
kind: Service
name: kubernetes-dashboard
namespace: kube-system
k8s-app: kubernetes-dashboard
kubernetes.io/cluster-service: "true"
k8s-app: kubernetes-dashboard
- port: <span style="color: #
targetPort: <span style="color: #90
所以访问192.168.51.5:9090端口就会出现dashboard
Ok,一切就绪，装逼开始
访问http://helloworld.eric/console&
访问http://helloword.eric/ & &出现dashboard
5.配置TLS SSL访问
TLS的配置相当于WebLogic中证书的配置，配置过程如下
# 生成 CA 自签证书
mkdir cert && cd cert
openssl genrsa -out ca-key.pem <span style="color: #48
openssl req -x509 -new -nodes -key ca-key.pem -days <span style="color: #000 -out ca.pem -subj "/CN=kube-ca"
# 编辑 openssl 配置
cp /etc/pki/tls/f .
# 主要修改如下
req_extensions = v3_req # 这行默认注释关着的 把注释删掉
# 下面配置是新增的
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.<span style="color: # = helloworld.eric
#DNS.<span style="color: # = kibana.mritd.me
# 生成证书
openssl genrsa -out ingress-key.pem <span style="color: #48
openssl req -new -key ingress-key.pem -out ingress.csr -subj "/CN=helloworld.eric" -f
openssl x509 -req -in ingress.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out ingress.pem -days <span style="color: #5 -extensions v3_req -f
需要注意的是DNS需要修改成自己的host名,然后在配置csr证书请求的时候需要将域名或者访问名带入subj,比如
-subj "/CN=helloworld.eric"
创建secret
kubectl create secret tls ingress-secret --namespace=kube-system --key cert/ingress-key.pem --cert cert/ingress.pem
修改Ingress文件启用证书
[root@k8s-master ingress]# cat tls-weblogic.yaml
apiVersion: extensions/v1beta1
kind: Ingress
name: dashboard-weblogic-ingress
namespace: kube-system
- helloworld.eric
secretName: ingress-secret
- host: helloworld.eric
- path: /console
serviceName: helloworldsvc
servicePort: <span style="color: #01
serviceName: kubernetes-dashboard
servicePort: <span style="color: #
&然后访问helloworld.eric/console,会自动转到https页面，同时查看证书并加入授信列表，可见
访问helloworld.eric
阅读(...) 评论()}