ASP.NET Core on K8S學習之旅（12）Ingress

阿新 • • 發佈：2020-05-11

本篇已加入《.NET Core on K8S學習實踐系列文章索引》，可以點選檢視更多容器化技術相關係列文章。

一、關於Ingress

　　Kubernetes對外暴露Service主要有三種方式：NodePort、LoadBalancer 以及 Ingress。前兩種我們在第四篇《你必須知道的Service》一文中已經加以介紹，這裡我們主要來看看Ingress是個什麼鬼。

　　官網對 Ingress 的定義為管理對外服務到叢集內服務之間規則的集合，通俗點講就是它定義規則來允許進入叢集的請求被轉發到叢集中對應服務上，從來實現服務暴漏。Ingress 能把叢集內 Service 配置成外網能夠訪問的 URL，流量負載均衡，終止SSL，提供基於域名訪問的虛擬主機等等。

　　我們可以再次回顧一下我們通常訪問一個業務的流程：

User在瀏覽中輸入一個域名
DNS至業務入口，這裡一般指外部負載均衡器（Load Balancer），比如阿里雲的SLB服務
外部負載均衡器反向代理到K8S的入口，比如Ingress
Ingress將請求轉交給對應的Service
Service將請求對應到某一個具體的Pod

　　瞭解了整個流程，我們再結合官網的定義來看Ingress，可以知道Ingress就是一個K8S叢集業務的入口，一個統一訪問入口。我們可以使用Traefik、Istio、Nginx、HAProxy來作為Ingress使用，這裡我們主要介紹Nginx Ingress，因為我們比較熟悉Nginx一些。

二、Nginx Ingress的安裝與配置

　　這裡我們在k8s-master上執行以下的yaml檔案來通過DaemonSet的方式部署Nginx Ingress，這個yaml檔案可以從ingress-nginx的github上獲取，這裡我選擇的是0.30.0版本。

　　獲取方式：https://github.com/kubernetes/ingress-nginx/tree/nginx-0.30.0/deploy

　　在static目錄下，將mandatory.yaml檔案獲取下來如下程式碼所示，這裡我做了一點修改（注意我標紅的配置）：

　　（1）將原本為Deployment的型別換為了DaemonSet

　　（2）為Ingress-Controller增加hostNetwork: true的配置，即直接佔用宿主機80/443埠

　　（3）將Ingress-Controller部署到有ingressHost: yes這個label的Node節點上，即我的k8s-node1伺服器上

　　（4）將Ingress-Controller的映象源改為阿里雲映象倉庫：registry.cn-hangzhou.aliyuncs.com

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:
  # replicas: 1
  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:
      # wait up to five minutes for the drain of connections
      terminationGracePeriodSeconds: 300
      serviceAccountName: nginx-ingress-serviceaccount
      nodeSelector:
        kubernetes.io/os: linux
        ingressHost: "yes"
      hostNetwork: true
      containers:
        - name: nginx-ingress-controller
          image: registry.cn-hangzhou.aliyuncs.com/google_containers/nginx-ingress-controller:0.30.0
          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 -> 101
            runAsUser: 101
          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:
  - min:
      memory: 90Mi
      cpu: 100m
    type: Container

　　這裡順便說下Ingress的兩種部署方式：

　　（1）基於NodePort方式

　　基於NodePort的部署思路就是通過在每個節點上開闢NodePort的埠，將流量引入進來，而後通過iptables首先轉發到ingress-controller容器中(圖中的nginx容器)，而後由nginx根據ingress的規則進行判斷，將其轉發到對應的應用web容器中。

　　（2）基於HostNetwork方式

　　相比較起來，HostNetwork模式不再需要建立一個nodePort的svc，而是直接在每個節點都建立一個ingress-controller的容器，而且將該容器的網路模式設為HostNetwork。也就是說每個節點物理機的80和443埠將會被ingress-controller中的nginx容器佔用。當流量通過80/443埠進入時，將直接進入到nginx中。而後nginx根據ingress規則再將流量轉發到對應的web應用容器中。

　　OK，兩種模式我們就瞭解到這裡，本文采用的是基於hostNetwork的方式佔用宿主機80/443埠來作為流量入口。

　　然後，我們就可以執行建立命令來建立Ingress-Controller了：

kubectl apply -f mandatory.yaml

　　執行後的顯示如下圖所示，它會執行一系列的建立工作如namespace、configmap、serviceaccount、rbac以及daemonset等：

　　Ingress-Controller建立好之後，我們再來建立一個指導Ingress進行路由轉發的規則集ingress-nginx.yaml，其配置如下：

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: nginx-ingress
  namespace: xdp-poc
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/rewrite-target: /api/$2
spec:
  rules:
  - host: portal.k8s.xi-life.cn
    http:
      paths:
      - path: /apple(/|$)(.*)
        backend:
          serviceName: apple-api-svc
          servicePort: 80
      - path: /banana(/|$)(.*)
        backend:
          serviceName: banana-api-svc
          servicePort: 80

　　它的作用其實是幫助Nginx生成正確的Nginx.conf，幫助Nginx將請求轉發不同的K8s叢集中的Service入口進行處理。這裡，我定義了兩個後端Service服務，稍後我會介紹這兩個Service，現在我們現將其建立一下：

kubectl apply -f ingress-nginx.yaml

　　好了，搭建和配置部分到此為止，下面我們可以準備剛剛提到的兩個Service來進行一個簡單的驗證了。

三、Nginx Ingress的使用驗證

3.1 WebAPI專案準備

　　這裡我準備兩個ASP.NET Core WebAPI專案，他們的程式碼很簡單，就只有一個HomeController，負責請求到api/home路由時返回一個json即可。

　　其中，AppleApi專案返回：

// GET api/home
[HttpGet]
public ActionResult<IEnumerable<string>> Get()
{
    return new string[] { "AppleApi-Home", "v1.0", "Welcome to use AppleApi!" };
}

　　BananApi專案返回：

// GET api/home
[HttpGet]
public ActionResult<IEnumerable<string>> Get()
{
    return new string[] { "BananaApi-Home", "v1.0", "Welcome to use BananaApi!" };
}

　　這部分的程式碼檔案可以在我的github上獲取：點此獲取。

　　然後，我們將這兩個專案分別打一個docker映象並上傳到docker hub上，你可以直接使用我的映象進行這個實驗，具體的打包映象和上傳映象的過程我就不演示了。

　　直接拉取映象：docker pull xilife/apple-api-demo:1.0 / docker pull xilife/banana-api-demo:1.0

3.2 部署yaml檔案準備

　　接下來，我們就分別為兩個API專案準備部署yaml檔案，並應用該yaml檔案建立pod和service：

　　（1）deploy-appleapi-svc.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: apple-api-demo
  namespace: xdp-poc
  labels:
    name: apple-api-demo
spec:
  replicas: 2
  selector:
    matchLabels:
      name: apple-api-demo
  template:
    metadata:
      labels:
        name: apple-api-demo
    spec:
      containers:
      - name: apple-api-demo
        image: edisonsaonian/apple-api-demo:1.0
        ports:
        - containerPort: 80
        imagePullPolicy: IfNotPresent

---

kind: Service
apiVersion: v1
metadata:
  name: apple-api-svc
  namespace: xdp-poc
spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: 80
  selector:
    name: apple-api-demo

　　需要注意的就是：確保這裡Service中定義的namespace（這裡是xdp-poc）、服務名（這裡是apple-api-svc）以及埠（這裡是80）跟之前我們在ingress-nginx.yaml中設定的後端服務名和埠保持一致，否則無法實現請求轉發。下面的BananaApi也是需要保持一致，就不再贅述。

　　（2）deploy-bananaapi-svc.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: banana-api-demo
  namespace: xdp-poc
  labels:
    name: banana-api-demo
spec:
  replicas: 2
  selector:
    matchLabels:
      name: banana-api-demo
  template:
    metadata:
      labels:
        name: banana-api-demo
    spec:
      containers:
      - name: banana-api-demo
        image: edisonsaonian/banana-api-demo:1.0
        ports:
        - containerPort: 80
        imagePullPolicy: IfNotPresent

---

kind: Service
apiVersion: v1
metadata:
  name: banana-api-svc
  namespace: xdp-poc
spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: 80
  selector:
    name: banana-api-demo

　　最後，我們將其部署到K8s叢集：

kubectl apply -f deploy-appleapi-svc
kubectl apply -f deploy-bananaapi-svc

　　現在可以通過kubectl看看是否已經Running：

3.3 快速驗證Ingress

　　由於我們設定的host是portal.k8s.xi-life.cn，因此我們現在自己的客戶機上修改一下hosts檔案（Windows的話在system32/etc/drivers/hosts）增加一條記錄，然後就可以通過瀏覽器輸入域名來進行訪問測試了：

　　（1）apple-api

　　（2）banana-api

四、小結

　　本文介紹了Ingress的基本概念與Nginx Ingress的安裝與配置，然後通過部署兩個ASP.NET Core WebAPI服務到K8s叢集進行Ingress的快速驗證。當然，我們也可以使用自己的閘道器來代替Ingress作為外部統一流量入口，也可以使用雲產品的LoadBalancer或API閘道器來替代Ingress也都是可以的（不缺錢的情況下）。

參考資料

（1）樑寬，《再也不踩坑的Kubernetes實戰指南》

（2）李振良，《一天入門Kubernets教程》

（3）馬哥（馬永亮），《Kubernetes快速入門》

（4）花田犯的錯，《K8S Nginx Ingress介紹》

（5）Lucie_xxm，《Ingress 統一訪問入口》

作者：周旭龍

出處：https://edisonchou.cnblogs.com

本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文連結。

ASP.NET Core on K8S學習之旅（12）Ingress

一、關於Ingress

二、Nginx Ingress的安裝與配置

三、Nginx Ingress的使用驗證

3.1 WebAPI專案準備

3.2 部署yaml檔案準備

3.3 快速驗證Ingress

四、小結

參考資料

ASP.NET Core on K8S學習之旅（12）Ingress

ASP.NET Core on K8S學習之旅（14）Ingress灰度釋出

ASP.NET Core on K8S學習之旅（13）Ocelot API閘道器接入

ASP.NET Core on K8S學習初探（3）部署API到K8S

.NET Core on K8S快速入門課程（Jessetalk）

ASP.NET Core on K8S深入學習（1）K8S基礎知識與叢集搭建

ASP.NET Core on K8S深入學習（2）部署過程解析與Dashboard

ASP.NET Core on K8S深入學習（3）Deployment

ASP.NET Core on K8S深入學習（3-2）DaemonSet與Job

ASP.NET Core on K8S深入學習（4）你必須知道的Service

ASP.NET Core on K8S深入學習（5）Rolling Update

ASP.NET Core on K8S深入學習（7）Dashboard知多少

ASP.NET Core on K8S深入學習（9）Secret & Configmap

ASP.NET Core on K8S 入門學習系列文章目錄

小白的linux學習之旅（二）

小白的linux學習之旅（一）

Node.js學習之旅（二）-----MongoDB的安裝與啟動

Spring學習之旅（四）Spring工作原理再探

ASP.NET Core 一步步搭建個人網站（7）_Linux系統移植

我的機器學習之旅（四）：回歸與工程應用

ASP.NET Core on K8S學習之旅（12）Ingress

一、關於Ingress

二、Nginx Ingress的安裝與配置

三、Nginx Ingress的使用驗證

3.1 WebAPI專案準備

3.2 部署yaml檔案準備

3.3 快速驗證Ingress

四、小結

參考資料

相關推薦