专栏首页TKE学习分享从无到有基于腾讯云TKE部署Kubernetes全流程-Ingress(五)
原创

从无到有基于腾讯云TKE部署Kubernetes全流程-Ingress(五)

由于大规模使用Kuberntes后,容器中的Service变得较多,怎样让这么多Service被集群外部的服务所访问也是一个急需解决的问题,NodePort这样一种方案显然不太适合。

那么这里,我们就介绍一个 Ingress 的方式,且搭配TKE所自带提供的Ingress完成服务的外部暴露。

现有环境如下

访问 nginx-deploy-svc 服务

访问 nginx-test-deploy 服务

1、部署 Ingress

由于云服务商所提供的 Ingress 更倾向于LoadBlance 的形式,对一些集群内部的Service支持并不好,所以我们采用自建 Ingress。

GitHub官方项目地址:https://github.com/kubernetes/ingress-nginx ,官方文档地址:https://kubernetes.github.io/ingress-nginx/deploy/

目前文档中一般采用Deployment的方式部署,但是个人比较喜欢通过DaemonSet的形式,并通过Label固定到某台主机上。所以需要对该Deployment文件进行改写。

部署共包含两个文件: mandatory.yaml 以及 service-nodeport.yaml

1.下载所需文件
(可通过GitGub中ingress-nginx项目下deploy,选定需要的版本)
    <1>.mandatory.yaml
    <2>.service-nodeport.yaml
​
​
注意事项:
  mandatory.yaml 该文件需要注意的一点是,目前项目组下部署均为Deployment方式,无法做到DaemonSet与Node主机网络相同,\
访问需http://域名:端口(该端口不为80);
如需需网络相同的方式,可以通过修改该文件中Deployment修改为DaemonSet.
实现访问http://域名:端口(端口可省略因默认为80)
​
详细操作:
    1. 修改mandatory.yaml 中 Deployment为DaemonSet;
    2. 删除replicas,因为DaemonSet中不包含replicas;
    3. 在Spec下添加字段,使pod共享宿主机网络,暴露所监听的端口;
        hostNetwork: true
    4. 通过指定标签Node部署;
        nodeSelector:
          custom/ingress-controller-ready: "true"
    5. 为需要运行该ingress的节点node添加标签;
        kubectl label nodes node01 custom/ingress-controller-ready=true
        (如操作错误,label也可通过edit node node01 选择删除)
    6. 运用该两个文件;
        kubectl apply -f mandatory.yaml
        kubectl apply -f service-nodeport.yaml
    7. 查看状态;
        kubectl get all -n ingress-nginx

修改过的 mandatory.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: DaemonSet
metadata:
  name: nginx-ingress-controller
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
spec:
  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:
      nodeSelector:
        custom/ingress-controller-ready: "true"
      hostNetwork: true
      # wait up to five minutes for the drain of connections
      terminationGracePeriodSeconds: 300
      serviceAccountName: nginx-ingress-serviceaccount
      containers:
        - name: nginx-ingress-controller
          image: siriuszg/nginx-ingress-controller:0.26.1
          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 -> 33
            runAsUser: 33
          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:
  - default:
    min:
      memory: 90Mi
      cpu: 100m
    type: Container

未修改使用 NodePort方式 service-nodeport.yaml

apiVersion: v1
kind: Service
metadata:
  name: ingress-nginx
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
spec:
  type: NodePort
  ports:
    - name: http
      port: 80
      targetPort: 80
      protocol: TCP
    - name: https
      port: 443
      targetPort: 443
      protocol: TCP
  selector:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
​
---

<1>、执行两个yaml文件

[root@VM_0_7_centos ingress]# kubectl apply -f mandatory.yaml
namespace/ingress-nginx unchanged
configmap/nginx-configuration unchanged
configmap/tcp-services unchanged
configmap/udp-services unchanged
serviceaccount/nginx-ingress-serviceaccount unchanged
clusterrole.rbac.authorization.k8s.io/nginx-ingress-clusterrole unchanged
role.rbac.authorization.k8s.io/nginx-ingress-role unchanged
rolebinding.rbac.authorization.k8s.io/nginx-ingress-role-nisa-binding unchanged
clusterrolebinding.rbac.authorization.k8s.io/nginx-ingress-clusterrole-nisa-binding unchanged
daemonset.apps/nginx-ingress-controller unchanged
limitrange/ingress-nginx configured
[root@VM_0_7_centos ingress]# kubectl apply -f service-nodeport.yaml
service/ingress-nginx configured
[root@VM_0_7_centos ingress]#

<2>、给需要固定的节点打标签

kubectl label nodes 10.0.0.2 custom/ingress-controller-ready=true

<3>、查看情况

2、部署具体Ingress代理规则文件

现在情况是这样,其实这个Service用不用都可以,因为pod的IP与Node的IP一致,网络中的其他主机也是可以访问到的了。我们只需将Ingress的域名指向该台Node 10.0.0.2 即可。示例如下:

test-ingress.yaml 内容如下

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-chat
  namespace: default
  annotations:
    kubernetes.io/ingress.class: "nginx"
    kubernetes.io/tls-acme: "true"
    nginx.ingress.kubernetes.io/proxy-body-size: 50m
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  rules:
  - host: myapp.zzz888.com
    http:
      paths:
      - path: /a(/|$)(.*)
        backend:
          serviceName: nginx-deployment-svc
          servicePort: 80
      - path: /b(/|$)(.*)
        backend:
          serviceName: nginx-test-deploy
          servicePort: 80

由于没买域名,所以通过修改hosts的方式进行测试。

应用后的Ingress如下:

访问测试

3、结合TKE中LoadBlance,面向外网暴露。

更改SVC的访问类型

更改本地Hosts

访问测试

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 从无到有基于腾讯云TKE部署Kubernetes全流程(一)

    这里我们希望的是,提供一个腾讯云TKE中部署整个基础环境,以及对部分服务的一个示例。

    蒋经纬
  • 从无到有基于腾讯云TKE部署Kubernetes全流程(四)

    前面的TKE集群工作都有所完成了,现在我们尝试通过这一系列工具使得,流程完全自动化。

    蒋经纬
  • 从无到有基于腾讯云TKE部署Kubernetes全流程(三)

    只能实现一对一挂载,因为硬盘只支持一次挂载,通过硬盘创建的PVC为RWO,单机读写。

    蒋经纬
  • 从无到有基于腾讯云TKE部署Kubernetes全流程(二)

    TKE中Kuberntes集群已经部署完成后,现在我们需要了解哪些东西,为后续选型使用呢?

    蒋经纬
  • 容器服务 TKE 上服务暴露的几种方式

    作者刘飞鸿,腾讯游戏高级工程师,热衷于开源、云计算相关技术。目前主要负责腾讯游戏后台架构设计和运维工作。 预备知识 1. K8S 上 Service 类型 C...

    腾讯云原生
  • 12月容器月报 | 降低 65% 业务成本的弹性容器EKS「竞价实例」上线

    ? 2020年12月 ? ? VOL:08 ? ? ? ? 腾小云告诉你最前线的产品新特性, 总有一款让你心动~ ? 云说新品 ? 容器产品新特性 12月上新...

    腾讯云原生
  • 如何在容器服务中获取客户端真实源IP

    jokey,腾讯云容器产品工程师,热衷于云原生领域。目前主要负责腾讯云TKE 的售中、售后的技术支持,根据客户需求输出合理技术方案与最佳实践。 适用范围:腾讯...

    腾讯云原生
  • kubernetes系列教程(十八)TKE中实现ingress服务暴露

    上一篇文章中介绍了基于Nginx实现Ingress Controller的实现,介绍了Nginx Ingress Controller安装、相关功能,TLS,高...

    HappyLau谈云计算
  • 11月容器技术产品月报 | 云原生监控正式公测

    ? 2020年11月 ? ? VOL:07 ? ? ? ? 腾小云告诉你最前线的产品新特性, 总有一款让你心动~ ? 云说新品 ? 容器产品新特性 11月上新...

    腾讯云原生
  • 小报温馨提示:您的弹性容器服务正在配送

    2019年匆匆而去,留下的是我们每一个人所有的努力,在新的一年里,它们将陪伴着我们继续新的征程,见证新的里程。年初是奋斗的季节,年末是收获的时刻,2019年的最...

    腾讯云原生
  • 在腾讯云容器服务 TKE 中实践 DevOps

    jokey,腾讯云容器产品工程师,热衷于云原生领域。目前主要负责腾讯云TKE 的售中、售后的技术支持,根据客户需求输出合理技术方案与最佳实践。 概述 DevO...

    腾讯云原生
  • Nginx Ingress on TKE 部署最佳实践

    开源的 Ingress Controller 的实现使用量最大的莫过于 Nginx Ingress 了,功能强大且性能极高。Nginx Ingress 有多种部...

    imroc
  • 云原生应用负载均衡系列 (2): 入口流量分发、容错与高可用调度

    冉昕,腾讯云服务网格TCM产品经理,现负责云原生流量接入网关与应用通信可观测性等产品特性策划与设计工作。 引言 在云原生应用负载均衡系列第一篇文章《云原生应...

    腾讯云原生
  • 搬砖武士|手把手教你在容器服务 TKE 上使用 LB直通 Pod

    roc,腾讯工程师,负责腾讯云TKE的售中、售后的技术支持,根据客户需求输出合理技术方案与最佳实践,为客户业务保驾护航。 什么是 LB 直通 Pod ? Ku...

    腾讯云原生
  • 开工必备!50+篇超实用云原生技术干货合集

    kai 开 gong 工 da 大 ji 吉 新年新气象,更要1G棒 2020年没写完的代码,现在还有思路吗? 2021年开始使用云原生技术了吗? 一开工就遇...

    腾讯云原生
  • CD+服务网格灰度发布实践,一文带你体验如何编排更灵活

    作者廖红坤,CODING DevOps 产品策划。从事过多年运维开发,云计算、Kubernetes、云原生深度实践者,有丰富的 DevOps 平台设计经验。

    腾讯云原生
  • 在 istio 中使用 namespace 进行资源/租户隔离

    PaaS 场景中,需要在集群中给客户提供容器部署他们自己开发的代码,如果使用 命名空间 来表示租户,则需要有效隔离租户,让隔壁的租户无法访问本租户的资源。下面的...

    谢正伟
  • 使用腾讯云容器服务TKE VS 自建k8s 集群

    TKE(Tencent Kubernetes Engine) 是腾讯云提供的容器服务PAAS 平台,基于kubernetes, 集成了腾讯云vpc网络,负载均衡...

    caryguo
  • 基于Kubernetes 构建.NET Core 的技术体系

    很多公司技术支持岗位的工作,如配置域名,部署环境,修改复位配置,服务重启,扩容缩容,梳理和完善监控,根据开发的需要查找日志等工作,需要和开发进行大量的沟通,如什...

    张善友

扫码关注云+社区

领取腾讯云代金券