kubernetes集群中使用ingress发布服务

当我们将kubernetes的应用部署完之后，就需要对外发布服务的访问地址。kubernetes 将服务发布到外部访问的方式主要有：
LoadBlancer Service
NodePort Service
Ingress

一、LoadBlancer Service
LoadBlancer Service 是 kubernetes 深度结合云平台的一个组件；当使用 LoadBlancer Service 暴露服务时，实际上是通过向底层云平台申请创建一个负载均衡器来向外暴露服务；目前 GCE、AWS、阿里云等公有云都有针对LoadBlancer Service完整的解决方案。

二、NodePort Service
因为K8s 的rc具有副本控制能力， Pod如果出现意外情况会自动销毁并重建；因此Pod 的ip地址也会跟着变化。我们可以在service中定义nodeport,在每个节点上开起一个端口，然后转发到内部 Pod IP 上。这就是所谓的NodePort Service,实质上就是在每个 node 上暴露一个端口，然后将这个端口映射到某个具体的 service 来实现的。虽然每个 node 的端口有很多(0~65535)，但是由于安全性和易用性，实际上可用的端口范围为：30000-32767。如果在service指定的nodeport超过了这个范围，则会报错如下：

The Service "nginx-test" is invalid: spec.ports[0].nodePort: Invalid value: 38888: provided port is not in the valid range. The range of valid ports is 30000-32767

采用这种方式存在着诸多不变：
1、首先端口数受限，使用此方式每一个node上都要开启相同的port
2、如果最终的应用访问要使用域名访问，还得在应用前端放一个nginx做转发。

又或者直接在k8s集群中部署一个nginx，将请求转发到集群内的其他服务器上，这是个好想法，但每次新增或者修改服务，都要去修改nginx配置文件，无法做到服务的自动发现，也不是最终的解决方案。

三、Ingress
Ingress 是在kubernetes 1.2版本才出现的，通过 Ingress 用户可以实现使用 nginx 等开源的反向代理负载均衡器实现对外暴露服务。使用 Ingress 时一般会有三个组件:

反向代理负载均衡器
反向代理负载均衡器通常使用nginx，部署方式可以选择 Replication Controller、Deployment、DaemonSet 等

Ingress Controller
Ingress Controller 通过连接api server，获取 service以及pod的信息，当得到这些变化信息后，Ingress Controller 再结合Ingress 生成配置，更新反向代理负载均衡器，达到服务发现的目的。

Ingress
Ingress 简单理解就是个规则定义；其本质是根据rules规则来将对应的host访问请求转发到k8s后端的services。从而实现整体的服务发现和负载均衡。
定义ingress前，必须先部署ingress controller ，以实现为所有后端的service 提供一个统一的入口。在ingress-controller的rc文件中定义了一个默认后端。所以在部署ingress controller前要先启动默认后端的pod，否则启动ingress-controller会不成功.

下面我们来介绍在k8s 1.5.2集群环境中，通过配置ingress，发布前面配置好的dashboard和nginx服务
1、默认后端的yaml文件

# cat default-backend.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: default-http-backend
  labels:
    k8s-app: default-http-backend
  namespace: default
spec:
  replicas: 1
  template:
    metadata:
      labels:
        k8s-app: default-http-backend
    spec:
      terminationGracePeriodSeconds: 60
      containers:
      - name: default-http-backend
        # Any image is permissable as long as:
        # 1. It serves a 404 page at /
        # 2. It serves 200 on a /healthz endpoint
        image: docker.io/cdchen/defaultbackend:1.0
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
            scheme: HTTP
          initialDelaySeconds: 30
          timeoutSeconds: 5
        ports:
        - containerPort: 8080
        resources:
          limits:
            cpu: 10m
            memory: 20Mi
          requests:
            cpu: 10m
            memory: 20Mi
---
apiVersion: v1
kind: Service
metadata:
  name: default-http-backend
  namespace: default
  labels:
    k8s-app: default-http-backend
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
k8s-app: default-http-backend

2、ingress ReplicationController的yaml文件

# cat nginx-ingress-controller.yaml
apiVersion: v1
kind: ReplicationController
metadata:
  name: nginx-ingress-lb
  labels:
    name: nginx-ingress-lb
  namespace: default
spec:
  replicas: 1
  template:
    metadata:
      labels:
        name: nginx-ingress-lb
      annotations:
        prometheus.io/port: ‘10254‘
        prometheus.io/scrape: ‘true‘
    spec:
      terminationGracePeriodSeconds: 60
      hostNetwork: true
      containers:
      - image: docker.io/cdchen/nginx-ingress-controller:0.9.0-beta.12
        name: nginx-ingress-lb
        readinessProbe:
          httpGet:
            path: /healthz
            port: 10254
            scheme: HTTP
        livenessProbe:
          httpGet:
            path: /healthz
            port: 10254
            scheme: HTTP
          initialDelaySeconds: 10
          timeoutSeconds: 1
        ports:
        - containerPort: 80
          hostPort: 80
        - containerPort: 443
          hostPort: 443
        env:
          - name: POD_NAME
            valueFrom:
              fieldRef:
                fieldPath: metadata.name
          - name: POD_NAMESPACE
            valueFrom:
              fieldRef:
                fieldPath: metadata.namespace
          - name: KUBERNETES_MASTER
            value: http://192.168.115.5:8080
        args:
        - /nginx-ingress-controller
        - --default-backend-service=$(POD_NAMESPACE)/default-http-backend
        - --apiserver-host=http://192.168.115.5:8080

3、Dashboard 和 nginx的ingress yaml文件

# cat k8s-dashboard.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: k8s-dashboard-ingress
  namespace: default
spec:
  rules:
  - host: k8s.webui
    http:
      paths:
      - path: /
        backend:
          serviceName: kubernetes-dashboard
          servicePort: 80
# cat k8s-nginx-test.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: k8s-nginx-test
  namespace: default
spec:
  rules:
  - host: test.fjhb.cn
    http:
      paths:
      - path: /
        backend:
          serviceName: nginx-test
          servicePort: 80

4、通过上述yaml文件创建对应的pod、rc及ingress

# kubectl get rc
# kubectl get pod
# cd ingress/
# kubectl create -f .

# kubectl get pod
# kubectl get ingress
# kubectl get rc


5、访问测试




也可以通过查看nginx-ingress-lb pod的日志来验证。

原文地址：http://blog.51cto.com/ylw6006/2072316

时间： 2024-10-08 22:35:06

kubernetes集群中使用ingress发布服务的相关文章

Kubernetes集群中Service的滚动更新

Kubernetes集群中Service的滚动更新 二月 9, 2017 0 条评论 在移动互联网时代,消费者的消费行为已经"全天候化",为此,商家的业务系统也要保持7×24小时不间断地提供服务以满足消费者的需求.很难想像如今还会有以"中断业务"为前提的服务系统更新升级.如果微信官方发布公告说:每周六晚23:00~次日凌晨2:00进行例行系统升级,不能提供服务,作为用户的你会怎么想.怎么做呢?因此,各个平台在最初设计时就要考虑到服务的更新升级问题,部署在Kubern

在kubernetes 集群内访问k8s API服务

所有的 kubernetes 集群中账户分为两类,Kubernetes 管理的 serviceaccount(服务账户) 和 useraccount(用户账户).基于角色的访问控制(“RBAC”)使用“rbac.authorization.k8s.io”API 组来实现授权控制,允许管理员通过Kubernetes API动态配置策略. API Server 内部通过用户认证后,然后进入授权流程.对合法用户进行授权并且随后在用户访问时进行鉴权,是权限管理的重要环节.在 kubernetes 集群中

在kubernetes集群中运行nginx

在完成前面kubernetes数据持久化的学习之后,本节我们开始尝试在k8s集群中部署nginx应用,对于nginx来说,需要持久化的数据主要有两块:1.nginx配置文件和日志文件2.网页文件 一.配置nginx网页文件持久化1.ReplicationController配置文件如下 # cat nginx-rc.yaml apiVersion: v1 kind: ReplicationController metadata: name: nginx-test labels: name: ng

运维之我的docker-swarm集群中删除节点和服务

删除swam节点 如果有的确实想要从swarm集群中删除,你应该先把这个节点容器排空,然后再把节点从集群中去掉. 排空节点(其实就是把这个节点上的容器先从其它节点启动,再停掉排空节点上的容器,保证你定义服务的预先状态不受影响) docker node update --availability drain g36lvv23ypjd8v7ovlst2n3yt 删除指定节点 docker node rm  node9 docker node rm --force node9 删除服务 删除服务以后容

在kubernetes集群中部署mysql主从

本文介绍在kubernetes环境中部署mysql主从集群,数据持久化采用nfs. 一.环境介绍Mysql版本:5.7 Mysql master节点: 主机名:vm1IP地址:192.168.115.5/24 Mysql slave节点: 主机名:vm2IP地址:192.168.115.6/24 NFS节点:主机名:vm2IP地址:192.168.115.6/24共享目录:/home/mysql_master./home/mysql_slave 二.准备mysql主从的镜像环境dockerfil

在kubernetes集群中部署php应用

本文将介绍在kubernetes环境中部署一套php应用系统.前端web采用nginx.中间件php以fastcgi的方式运行,后台数据库由mysql主从提供支撑.各服务组件之间的调用采用dns解析服务名的方式进行,数据和配置文件持久化采用pv和pvc(基于nfs). 一.通过dockerfile创建php镜像文件 # cat dockerfile FROM docker.io/openshift/base-centos7:latest MAINTAINER ylw "[email protec

kubernetes集群边界路由Ingress的管理

1.将请求转发到单个后端服务上#cat traefik-ingress.yaml apiVersion: extensions/v1beta1 kind: Ingress metadata: name: traefik-web-ui namespace: c7n-system spec: rules: - host: traefik.maimailoan.cn http: paths: - path: / backend: serviceName: traefik-ingress-service

在kubernetes集群中搭建LNMP并运行discuz

文档整理 https://coding.net/u/aminglinux/p/k8s_discuz/git/tree/master 1 下载MySQL.PHP以及Nginx镜像 docker pull mysql:5.7 docker pull richarvey/nginx-php-fpm 2 将下载到的镜像push到harbor docker tag mysql:5.7 harbor.yuankeedu.com/aminglinux/mysql:5.7 docker push harbor.

实操教程丨如何在K8S集群中部署Traefik Ingress Controller

注:本文使用的Traefik为1.x的版本 在生产环境中,我们常常需要控制来自互联网的外部进入集群中,而这恰巧是Ingress的职责. Ingress的主要目的是将HTTP和HTTPS从集群外部暴露给该集群中运行的服务.这与Ingress控制如何将外部流量路由到集群有异曲同工之妙.接下来,我们举一个实际的例子来更清楚的说明Ingress的概念. 首先,想象一下在你的Kubernetes集群中有若干个微服务(小型应用程序之间彼此通信).这些服务能够在集群内部被访问,但我们想让我们的用户从集群外部也