k8s Ingress 服务部署方式

本文涉及的产品
应用型负载均衡 ALB,每月750个小时 15LCU
网络型负载均衡 NLB,每月750个小时 15LCU
.cn 域名,1个 12个月
简介: k8s Ingress 服务部署方式service和pod仅可在集群内部网络中通过IP地址访问。所有到达边界路由器的流量或被丢弃或被转发到其他地方

k8s Ingress 服务部署方式


通常情况下,service和pod仅可在集群内部网络中通过IP地址访问。所有到达边界路由器的流量或被丢弃或被转发到其他地方


官网对 Ingress 的定义为管理对外服务到集群内服务之间规则的集合,通俗点讲就是它定义规则来允许进入集群的请求被转发到集群中对应服务上,从来实现服务暴漏。Ingress 能把集群内 Service 配置成外网能够访问的 URL,流量负载均衡,终止SSL,提供基于域名访问的虚拟主机等等。


Ingress


Ingress 使用开源的反向代理负载均衡器来实现对外暴漏服务,比如 Nginx、Apache、Haproxy等。Nginx Ingress 一般有三个组件组成:


Nginx 反向代理负载均衡器


Ingress Controller


Ingress Controller 可以理解为控制器,它通过不断的跟 Kubernetes API 交互,实时获取后端 Service、Pod 等的变化,比如新增、删除等,然后结合 Ingress 定义的规则生成配置,然后动态更新上边的 Nginx 负载均衡器,并刷新使配置生效,来达到服务自动发现的作用。


Ingress


Ingress 则是定义规则,通过它定义某个域名的请求过来之后转发到集群中指定的 Service。它可以通过 Yaml 文件定义,可以给一个或多个 Service 定义一个或多个 Ingress 规则。


以上三者有机的协调配合起来,就可以完成 Kubernetes 集群服务的暴漏


Kubernetes 使用 Nginx Ingress 暴漏tomcat服务,前提我们需要有一个正常运行的集群服务,根据之前创建的的kubernetes集群,进行测试



使用到的镜像


gcr.io/google_containers/defaultbackend:1.4


quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.18.0


ingress-nginx组件有几个部分组成:


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


nginx-ingress-controller.yaml:有应用rbac的nginx-ingress-controller组件

YAML配置文件


namespace.yaml

apiVersion: v1

kind: Namespace

metadata:

 name: ingress-nginx

default-backend.yaml

apiVersion: extensions/v1beta1

kind: Deployment

metadata:

 name: default-http-backend

 labels:

   app.kubernetes.io/name: default-http-backend

   app.kubernetes.io/part-of: ingress-nginx

 namespace: ingress-nginx

spec:

 replicas: 1

 selector:

   matchLabels:

     app.kubernetes.io/name: default-http-backend

     app.kubernetes.io/part-of: ingress-nginx

 template:

   metadata:

     labels:

       app.kubernetes.io/name: default-http-backend

       app.kubernetes.io/part-of: ingress-nginx

   spec:

     terminationGracePeriodSeconds: 60

     containers:

       - name: default-http-backend

         image: googlecontainer/defaultbackend-amd64:1.4

         #image:

         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: ingress-nginx

 labels:

   app.kubernetes.io/name: default-http-backend

   app.kubernetes.io/part-of: ingress-nginx

spec:

 ports:

   - port: 80

     targetPort: 8080

 selector:

   app.kubernetes.io/name: default-http-backend

   app.kubernetes.io/part-of: ingress-nginx

---

configmap.yaml

kind: ConfigMap

apiVersion: v1

metadata:

 name: nginx-configuration

 namespace: ingress-nginx

 labels:

   app: ingress-nginx

tcp-services-configmap.yaml

kind: ConfigMap

apiVersion: v1

metadata:

 name: tcp-services

 namespace: ingress-nginx

udp-services-configmap.yaml

kind: ConfigMap

apiVersion: v1

metadata:

 name: udp-services

 namespace: ingress-nginx

rbac.yaml

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:

     - "extensions"

   resources:

     - ingresses

   verbs:

     - get

     - list

     - watch

 - apiGroups:

     - ""

   resources:

     - events

   verbs:

     - create

     - patch

 - apiGroups:

     - "extensions"

   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

---

nginx-ingress-controller.yaml

apiVersion: extensions/v1beta1

kind: DaemonSet

metadata:

 name: nginx-ingress-controller

 namespace: ingress-nginx

spec:

 selector:

   matchLabels:

     app: ingress-nginx

 template:

   metadata:

     labels:

       app: ingress-nginx

     annotations:

       prometheus.io/port: '10254'

       prometheus.io/scrape: 'true'

   spec:

     serviceAccountName: nginx-ingress-serviceaccount

     hostNetwork: true

     containers:

       - name: nginx-ingress-controller

         image: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.18.0

         args:

           - /nginx-ingress-controller

           - --default-backend-service=$(POD_NAMESPACE)/default-http-backend

           - --configmap=$(POD_NAMESPACE)/nginx-configuration

           - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services

           - --udp-services-configmap=$(POD_NAMESPACE)/udp-services

           - --annotations-prefix=nginx.ingress.kubernetes.io

         env:

           - name: POD_NAME

             valueFrom:

               fieldRef:

                 fieldPath: metadata.name

           - name: POD_NAMESPACE

             valueFrom:

               fieldRef:

                 fieldPath: metadata.namespace

         ports:

         - name: http

           containerPort: 80

         - name: https

           containerPort: 443

         livenessProbe:

           failureThreshold: 3

           httpGet:

             path: /healthz

             port: 10254

             scheme: HTTP

           initialDelaySeconds: 10

           periodSeconds: 10

           successThreshold: 1

           timeoutSeconds: 1

         readinessProbe:

           failureThreshold: 3

           httpGet:

             path: /healthz

             port: 10254

             scheme: HTTP

           periodSeconds: 10

           successThreshold: 1

           timeoutSeconds: 1


     #nodeSelector:


       #custom/ingress-controller-ready: "true"


说明:


kind: DaemonSet:官方文档给的是deployment,replicate 为 1,这样将会在某一台节点上启动对应的nginx-ingress-controller pod。外部流量访问至该节点,由该节点负载分担至内部的service。测试环境考虑防止单点故障,改为DaemonSet,配合亲和性部署在制定节点上启动nginx-ingress-controller pod,确保有多个节点启动nginx-ingress-controller pod,后续将这些节点加入到外部硬件负载均衡组实现高可用性。


hostNetwork: true:添加该字段,暴露nginx-ingress-controller pod的服务端口(80)

nodeSelector: 加入亲和性部署,有custom/ingress-controller-ready label的才会部署该DaemonSet(未使用)


加载yaml文件


kubectl create -f .


查看pod创建情况


#kubectl get pod,svc,deployment -n ingress-nginx -o wide


image.png

在上面已经部署了 ingress-nginx,下面我们部署一个tomcat作为对外暴露的服务


使用ingress部署一个对外暴露的服务包含一个pod和一个service


创建tomcat service yaml


vi tomcat-deploy.yaml


复制下面的内容:


apiVersion: v1


kind: Service


metadata:


 name: tomcat


 namespace: default


spec:


 selector:


   app: tomcat


   release: canary


 ports:


 - name: http


   targetPort: 8080


   port: 8080


 - name: ajp


   targetPort: 8009


   port: 8009


---

apiVersion: apps/v1


kind: Deployment


metadata:


 name: tomcat-deploy


 namespace: default


spec:


 replicas: 1


 selector:


   matchLabels:


     app: tomcat


     release: canary


 template:


   metadata:


     labels:


       app: tomcat


       release: canary


   spec:


     containers:


     - name: tomcat


       image: tomcat


       ports:


       - name: http


         containerPort: 8080


创建tomcat pod yaml文件


vi ingress-tomcat.yaml


复制下面内容:


apiVersion: extensions/v1beta1


kind: Ingress


metadata:


 name: ingress-tomcat

 namespace: default

 annotations:

   kubernetes.io/ingress.class: "nginx"

spec:

 rules:


 - host: k8s.master ##这个地方使用主机名或者域名,不能使用IP地址

   http:

     paths:

     - path:

       backend:

         serviceName: tomcat

         servicePort: 8080


然后执行:


kubectl apply -f tomcat-deploy.yaml


kubectl apply -f ingress-tomcat.yaml


服务启动以后就可以通过上面配置的主机名或者域名进行访问tomcat 了




image.png



相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
2月前
|
Prometheus Kubernetes 监控
k8s部署针对外部服务器的prometheus服务
通过上述步骤,您不仅成功地在Kubernetes集群内部署了Prometheus,还实现了对集群外服务器的有效监控。理解并实施网络配置是关键,确保监控数据的准确无误传输。随着监控需求的增长,您还可以进一步探索Prometheus生态中的其他组件,如Alertmanager、Grafana等,以构建完整的监控与报警体系。
132 60
|
2月前
|
Prometheus Kubernetes 监控
k8s部署针对外部服务器的prometheus服务
通过上述步骤,您不仅成功地在Kubernetes集群内部署了Prometheus,还实现了对集群外服务器的有效监控。理解并实施网络配置是关键,确保监控数据的准确无误传输。随着监控需求的增长,您还可以进一步探索Prometheus生态中的其他组件,如Alertmanager、Grafana等,以构建完整的监控与报警体系。
262 62
|
15天前
|
Kubernetes Cloud Native 微服务
云原生入门与实践:Kubernetes的简易部署
云原生技术正改变着现代应用的开发和部署方式。本文将引导你了解云原生的基础概念,并重点介绍如何使用Kubernetes进行容器编排。我们将通过一个简易的示例来展示如何快速启动一个Kubernetes集群,并在其上运行一个简单的应用。无论你是云原生新手还是希望扩展现有知识,本文都将为你提供实用的信息和启发性的见解。
|
25天前
|
存储 Kubernetes 网络协议
k8s的无头服务
Headless Service 是一种特殊的 Kubernetes 服务,其 `spec:clusterIP` 设置为 `None`,不会分配 ClusterIP,通过 DNS 解析提供服务发现。与普通服务不同,Headless Service 不提供负载均衡功能,每个 Pod 都有唯一的 DNS 记录,直接映射到其 IP 地址,适用于有状态应用的场景,如与 StatefulSet 一起部署数据库。示例中通过创建 Nginx 的 StatefulSet 和 Headless Service,展示了如何直接访问单个 Pod 并进行内容修改。
33 3
|
21天前
|
存储 Kubernetes Devops
Kubernetes集群管理和服务部署实战
Kubernetes集群管理和服务部署实战
41 0
|
2月前
|
Kubernetes Cloud Native 流计算
Flink-12 Flink Java 3分钟上手 Kubernetes云原生下的Flink集群 Rancher Stateful Set yaml详细 扩容缩容部署 Docker容器编排
Flink-12 Flink Java 3分钟上手 Kubernetes云原生下的Flink集群 Rancher Stateful Set yaml详细 扩容缩容部署 Docker容器编排
80 3
|
2月前
|
NoSQL 关系型数据库 Redis
高可用和性能:基于ACK部署Dify的最佳实践
本文介绍了基于阿里云容器服务ACK,部署高可用、可伸缩且具备高SLA的生产可用的Dify服务的详细解决方案。
|
Kubernetes 开发者 微服务
简化Kubernetes应用部署工具-Helm之Hook
本文讲的是简化Kubernetes应用部署工具-Helm之Hook【编者的话】微服务和容器化给复杂应用部署与管理带来了极大的挑战。Helm是目前Kubernetes服务编排领域的唯一开源子项目,做为Kubernetes应用的一个包管理工具,可理解为Kubernetes的apt-get / yum,由Deis 公司发起,该公司已经被微软收购。
2561 0
|
1天前
|
存储 Kubernetes 关系型数据库
阿里云ACK备份中心,K8s集群业务应用数据的一站式灾备方案
本文源自2024云栖大会苏雅诗的演讲,探讨了K8s集群业务为何需要灾备及其重要性。文中强调了集群与业务高可用配置对稳定性的重要性,并指出人为误操作等风险,建议实施周期性和特定情况下的灾备措施。针对容器化业务,提出了灾备的新特性与需求,包括工作负载为核心、云资源信息的备份,以及有状态应用的数据保护。介绍了ACK推出的备份中心解决方案,支持命名空间、标签、资源类型等维度的备份,并具备存储卷数据保护功能,能够满足GitOps流程企业的特定需求。此外,还详细描述了备份中心的使用流程、控制台展示、灾备难点及解决方案等内容,展示了备份中心如何有效应对K8s集群资源和存储卷数据的灾备挑战。
|
22天前
|
Kubernetes 监控 Cloud Native
Kubernetes集群的高可用性与伸缩性实践
Kubernetes集群的高可用性与伸缩性实践
56 1