2. 程式人生 > >kubernetes物件之Ingress

kubernetes物件之Ingress

阿新 • • 發佈：2019-06-11

系列目錄

概述

向外網暴露叢集內服務，以使客戶端能夠訪問，有以下幾種方法，本文重點描述Ingress。

LoadBalancer

LoadBalancer一般由雲服務供應商提供或者使用者自定義，執行在叢集之外。在建立service時為其配置LoadBalancer相關引數，當從外網訪問叢集內servcie時，使用者直接連線到LoadBalancer伺服器，LoadBalancer伺服器再將流量轉發到叢集內service。Loadbalancer配置及使用方法與各雲服務供應商有關，本文不詳細描述。

NodePort

這種方式要求叢集中部分節點有被外網訪問的能力。Kubernetes為每個NodePort型別的服務在叢集中的每個節點上分配至少一個主機網路埠號。客戶通過能被外網訪問的節點IP加上節點埠的方式訪問服務。大多數情況下不會通過這種方式向叢集外暴露服務，原因有四。

  • 其一：大多情況下，為了安全起見，叢集中的節點位於完全內網環境中，不應該有被外網直接訪問的能力。一般外網訪問叢集中的節點都是通過邊界伺服器如閘道器、跳板等，而這種邊界伺服器需要通過各種方式進行安全加固。

  • 其二：如果叢集內節點可以從外網直接訪問的話，則會將叢集內節點地址、服務名稱、埠號等資訊直接暴露在外，非常不安全。

  • 其三：服務埠號一般由系統自動分配，並非固定，而服務名稱也可能發生變更，此時外部客戶端需要跟蹤變更並修改，屬於重試耦合。

  • 其四：這種方式，每個服務至少向外網暴露一個埠號，當服務很多時不易於管理。

Ingress

Ingress不是某種產品、元件的名稱，它應該是kubernetes向叢集外暴露服務的一種思路、技術，使用者完全可以根據這種思路提供自己的Ingress實現，當然kubernetes提供了預設Ingress實現還有其它第三方實現，一般無需自己開發。它的思路是這樣的，首先在叢集內執行一個服務或者pod也可以是容器，不管是什麼它至少應該有一個外網可以訪問的IP，至少向外網開放一個埠號，讓它充當反向代理伺服器。當外網想要訪問叢集內service時，只需訪問這個反向代理伺服器並指定相關引數，代理伺服器根據請求引數並結合內部規則，將請求轉發到service。這種思路與LoadBalancer的不同之處是它就位於叢集內，而LoadBalancer位於叢集外。與NodePort的不同之處是叢集只向外暴露一個服務或者pod等，而NodePort是暴露全部service。

Kubernetes用nginx實現反向代理伺服器，稱為Ingress Controller，是pod型別資源。同時提供了Ingress型別物件，通過建立Ingress物件配置nginx反向代理伺服器的轉發規則。Nginx反向代理伺服器收到來自外網的請求後，用請求的URL地址、請求頭欄位區別不同service，然後轉發請求。

部署Ingress Controller

在Kubernetes中，Ingress Controller典型是pod型別資源，其部署方式與普通pod相同，通過Deployment、DaemonSet等副本控制器部署，其中更值推薦的是DaemonSet方式。Ingress Controller需要部署在具備連通外網能力的節點上，首先在目標節點打上Ingress Controller專用標籤，然後在DaemonSet的配置檔案中配置節點選擇器選中此類標籤，控制pod例項可以部署的節點，通過為節點增減相關標籤控制Ingress Controller的pod例項個數。Ingress Controller一般佔用兩個節點主機埠，http用80，https用443。詳細參考：這裡。外網通過http://節點外網ip:80/...或者https://節點外網ip:80/...就可以訪問內部服務了，當前首先需要建立Ingress物件配置訪問策略。

建立Ingress物件

本節通過建立各種Ingress物件，展示Ingress的各種典型用法。

Single Service Ingress

配置檔案:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test-ingress
spec:
  backend:
    serviceName: testsvc
    servicePort: 80

然後通過kubectl create -f建立物件,這同建立一般物件並沒有很多區別,前面已經多次提到過,這裡不再詳細描述

檢視物件:

$ kubectl get ing
NAME                RULE          BACKEND        ADDRESS
test-ingress        -             testsvc:80     107.178.254.228

以上配置中沒有具體的rule，所以諸如http(s)://107.178.254.228/xxx之類的請求都轉發到testsvc的80埠。

其於URL轉發(Simple fanout)

假如要實現以下目標:

foo.bar.com -> 178.91.123.132 -> / foo    s1:80
                                 / bar    s2:80

其中foo.bar.com是http請求體頭部中的host欄位，178.91.123.132是Ingress Controller外網地址，當請求路徑與/foo匹配時轉發到s1服務的80埠，當與/bar匹配時轉發到s2服務的80埠，其最核心邏輯是用URL區分不同服務。

配置如下：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - path: /foo
        backend:
          serviceName: s1
          servicePort: 80
      - path: /bar
        backend:
          serviceName: s2
          servicePort: 80

檢視物件:

$ kubectl get ing
NAME      RULE          BACKEND   ADDRESS
test      -
          foo.bar.com
          /foo          s1:80
          /bar          s2:80

基於名稱的虛擬主機(Name based virtual hosting)

實現如下目錄:

foo.bar.com --|                 |-> foo.bar.com s1:80
              | 178.91.123.132  |
bar.foo.com --|                 |-> bar.foo.com s2:8

這種方式的核心邏輯是用http請求中的host欄位區分不同服務，而不是URL。如host: foo.bar.com的請求被轉發到s1服務80埠，如host: bar.foo.com的請求被轉發到s2服務80埠。

配置：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - backend:
          serviceName: s1
          servicePort: 80
  - host: bar.foo.com
    http:
      paths:
      - backend:
          serviceName: s2
          servicePort: 80
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - backend:
          serviceName: s1
          servicePort: 80
  - host: bar.foo.com
    http:
      paths:
      - backend:
          serviceName: s2
          servicePort: 80

TLS

利用Secret型別物件為Ingress Controller提供私鑰及證書，對通訊鏈路加密。

Secret配置：

apiVersion: v1
data:
  tls.crt: base64 encoded cert
  tls.key: base64 encoded key
kind: Secret
metadata:
  name: testsecret
  namespace: default
type: Secret

在Ingress物件中引用

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: no-rules-map
spec:
  tls:
  - secretName: testsecret
  backend:
    serviceName: s1
    servicePort: 80
** 更新Ingress物件**

使用kubectl edit命令編輯Ingress實時物件：

$ kubectl get ing
NAME      RULE          BACKEND   ADDRESS
test      -                       178.91.123.132
          foo.bar.com
          /foo          s1:80
$ kubectl edit ing test

在彈出的編輯器中修改：

spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - backend:
          serviceName: s1
          servicePort: 80
        path: /foo
  - host: bar.baz.com
    http:
      paths:
      - backend:
          serviceName: s2
          servicePort: 80
        path: /foo
..

儲存關稍後確認更新：

$ kubectl get ing
NAME      RULE          BACKEND   ADDRESS
test      -                       178.91.123.132
          foo.bar.com
          /foo          s1:80
          bar.baz.com
          /foo          s2:80

參考：

$ kubectl get ing
NAME      RULE          BACKEND   ADDRESS
test      -                       178.91.123.132
          foo.bar.com
          /foo          s1:80
          bar.baz.com
          /foo          s2:80

Ingress-NginX傳遞自定義header

問題現場:

配置好Ingress之後可以通過Ingress正常訪問系統，但是輸入使用者名稱密碼之後登陸失敗。但是通過NodePort暴露服務時可以正常訪問和登入。接下來進過除錯發現是在獲取使用者資訊時出錯，無法從Request header中取到自定義的使用者資訊欄位。

參考此文章發現，NginX預設會將使用者自定義的header過濾掉，除非開啟 underscores_in_headers ，經過測試，在NginX中開啟 underscores_in_headers 之後系統登入正常。那麼如何在Ingress-NginX中開啟此項呢：

kind: ConfigMap
apiVersion: v1
metadata:
  name: nginx-configuration
  namespace: ingress-nginx
  labels:
    app: ingress-nginx
data:
  enable-underscores-in-headers: "true"

參考連結1：

參考鏈

相關推薦

kubernetes物件之Ingress

系列目錄 概述 向外網暴露叢集內服務，以使客戶端能夠訪問，有以下幾種方法，本文重點描述Ingress。 LoadBalancer LoadBalancer一般由雲服務供應商提供或者使用者自定義，執行在叢集之外。在建立service時為其配置LoadBalancer相關引數，當從外網訪問叢集內servcie

【微服務】Kubernetes物件之Deployment（重要）

Kubernetes Deployment： Deployment為Pod和Replica Set（升級版的 Replication Controller）提供宣告式更新。 只需要在 Deployment 中描述您想要的目標狀態是什麼，Deployment cont

【微服務】Kubernetes物件之Service（重要）

Kubernetes Service： Kubernetes Service 定義了這樣一種抽象：一個 Pod 的邏輯分組，一種可以訪問它們的策略 —— 通常稱為微服務。 這一組 Pod 能夠被 Service 訪問到，通常是通過 Label Selector實現的

kubernetes物件之deployment

系列目錄 簡述 Deployment為Pod和ReplicaSet提供了一個宣告式定義(declarative)方法，用來替代以前的ReplicationController來方便的管理應用。典型的應用場景包括： 定義Deployment來建立Pod和ReplicaSet 滾動升級和回滾應用 擴容和縮容

kubernetes物件之Job

系列目錄 job是什麼 對於ReplicaSet、ReplicationController等型別的控制器而言，它希望pod保持預期數目、持久執行下去，除非使用者明確刪除，否則這些物件一直存在，它們針對的是耐久性任務，如web服務等。對於非耐久性任務，比如壓縮檔案，任務完成後，pod需要結束執行，不需要p

kubernetes物件之Volume

系列目錄 概述 Volume是對各種儲存資源的抽象、虛擬化。為管理、控制、使用儲存資源提供統一介面。Openstack中的volume為虛擬機器提供儲存，Docker中的volume為容器提供儲存。因為在kubernetes中可部署執行最小單位是pod ,所以kubernetes的volume為pod提供

Kubernetes K8S之Ingress詳解與示例

  K8S之Ingress概述與說明，並詳解Ingress常用示例   主機配置規劃 伺服器名稱(hostname)系統版本配置內網IP外網IP(模擬) k8s-master CentOS7.7 2C/4G/20G 172.16.1.110 10.0.0.110 k8s-

kubernetes之Ingress部署

min root 好的 sts memory com 變化 分享 hang 1，如何訪問K8S中的服務： 1，Ingress介紹 Kubernetes 暴露服務的方式目前只有三種：LoadBlancer Service、NodePort Service、

kubernetes-核心資源之Ingress

1、Ingress 在Kubernetes中，服務和Pod的IP地址僅可以在叢集網路內部使用，對於叢集外的應用是不可見的。為了使外部的應用能夠訪問叢集內的服務，在Kubernetes中可以通過NodePort和LoadBalancer這兩種型別的服務，或者使用Ingress。 插曲--------------

kubernetes之ingress安裝及遇到的rbac問題

話不多少，直接上建立步驟 一、default-backend apiVersion: extensions/v1beta1 kind: Deployment metadata: name: default-http-backend labels:

kubernetes 原始碼分析之ingress（一）

kubernetes的服務對外暴露通常有三種方式分別為nodeport、loadbalancer和ingress。nodeport很容易理解就是在每個主機上面啟動一個服務埠暴露出去，這樣弊端是造成埠浪費；loadbalancer這種方式目前只能在gce的平臺跑的

kubernetes部署之創建TLS證書(2)

efault control sage 啟用 簽名證書 sched amd .json 進行 研究過kubernetes的同事們都知道，kubernetes如果需要啟用TLS認證，那麽制作證書是必不可少的一步。然而，很多人在制作證書上遇到了很多的麻煩。今天主要記錄一次我在部

小物件之checkbox復選框

data 圖片 是否 開始 alt blog 並且 ech key 有時候需要輸出一組checkbox復選框，並且做根據選定元素將其選中的功能，以往都要在模板中循環輸出checkbox標簽，同時加以判斷是否需要選中，這樣就會造成很多開始閉合標簽 以前都是這樣寫 現在我將

kubernetes實戰之二（Pod）

namespace temp 準備 版本 containe tcp esp .cn lur Pod是kubernetes的基本操作單元，也是應用運行的載體。整個kubernetes系統都是圍繞著Pod展開的，比如如何部署運行Pod、如何保證Pod的可靠性、如何訪問Pod等。

Kubernetes 實踐之 service

請求分發 tps spec eat 直接 sele 服務 節點 emp service是k8s最核心的概念。通過創建service，可以為一組具有相同功能的容器應用提供一個統一的入口地址，並且將請求負載分發到後端的各個容器應用上去 service定義詳解 ymal

Kubernetes學習之路（十一）之資源清單定義

map latest dem kubectl 服務發現 bject 均衡 ima limit 一、Kubernetes常用資源 以下列舉的內容都是 kubernetes 中的 Object，這些對象都可以在 yaml 文件中作為一種 API 類型來配置。 類別 名稱

Kubernetes使用Nginx Ingress暴露Dashboard

strong ann 學會 itl 環境 kubectl back sys erro Kubernetes使用Nginx Ingress暴露Dashboard [TOC] 1. 環境說明 可用的kubernetes集群 可用的nginx ingress controlle

Kubernetes排程之親和性和反親和性

背景 Kubernetes中的排程策略可以大致分為兩種，一種是全域性的排程策略，要在啟動排程器時配置，包括kubernetes排程器自帶的各種predicates和priorities演算法；另一種是執行時排程策略，包括nodeAffinity（主機親和性），podAffinity（

Kubernetes學習之路（一）之Kubeadm部署K8S集群

chown you eof onf 訪問 perf 處的 iyu inter 一個星期會超過多少閱讀量呢？？發布一篇，看看是否重新在51上寫學習博文，有老鐵支持嘛？？ 使用kubeadm部署集群 節點名稱 ip地址 部署說明 Pod 網段 Service網段 系統說明

Python學習第一天:面向物件之封裝

　　封裝是根據職責將屬性和方法 封裝到一個抽象的類中。 下面是我在學習中的練習案例： 1.小明愛跑步 class Person: def __init__(self,name,weight): self.name = name self.weight = w