欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

k8s之ingress-nginx詳解和部署方案

 更新時間：2022年07月19日 11:38:12   作者：最美dee時光  
Ingress是一種向k8s集群外部的客戶端公開服務的方法,下面這篇文章主要給大家介紹了關于k8s之ingress-nginx詳解和部署方案的相關資料,文中通過實例代碼介紹的非常詳細,需要的朋友可以參考下

本篇是基于k8s-v1.15.0版本，在現(xiàn)有集群上部署ingress。

1、ingress介紹

K8s集群對外暴露服務的方式目前只有三種：Loadblancer；Nodeport；ingress

前兩種熟悉起來比較快，而且使用起來也比較方便，在此就不進行介紹了。

下面詳細講解下ingress這個服務，ingress由兩部分組成：

  • ingress controller：將新加入的Ingress轉化成Nginx的配置文件并使之生效
  • ingress服務：將Nginx的配置抽象成一個Ingress對象，每添加一個新的服務只需寫一個新的Ingress的yaml文件即可

其中ingress controller目前主要有兩種：基于nginx服務的ingress controller和基于traefik的ingress controller。

而其中traefik的ingress controller，目前支持http和https協(xié)議。由于對nginx比較熟悉，而且需要使用TCP負載，所以在此我們選擇的是基于nginx服務的ingress controller。

但是基于nginx服務的ingress controller根據(jù)不同的開發(fā)公司，又分為k8s社區(qū)的ingres-nginx和nginx公司的nginx-ingress。
在此根據(jù)github上的活躍度和關注人數(shù)，我們選擇的是k8s社區(qū)的ingres-nginx。

k8s社區(qū)提供的ingress，github地址如下：https://github.com/kubernetes/ingress-nginx
nginx社區(qū)提供的ingress，github地址如下：https://github.com/nginxinc/kubernetes-ingress

2、ingress的工作原理

ingress具體的工作原理如下:

step1：ingress contronler通過與k8s的api進行交互，動態(tài)的去感知k8s集群中ingress服務規(guī)則的變化，然后讀取它，并按照定義的ingress規(guī)則，轉發(fā)到k8s集群中對應的service。

step2：而這個ingress規(guī)則寫明了哪個域名對應k8s集群中的哪個service，然后再根據(jù)ingress-controller中的nginx配置模板，生成一段對應的nginx配置。

step3：然后再把該配置動態(tài)的寫到ingress-controller的pod里，該ingress-controller的pod里面運行著一個nginx服務，控制器會把生成的nginx配置寫入到nginx的配置文件中，然后reload一下，使其配置生效,以此來達到域名分配置及動態(tài)更新的效果。

3、ingress可以解決的問題

1）動態(tài)配置服務

如果按照傳統(tǒng)方式, 當新增加一個服務時, 我們可能需要在流量入口加一個反向代理指向我們新的k8s服務. 而如果用了Ingress, 只需要配置好這個服務, 當服務啟動時, 會自動注冊到Ingress的中, 不需要而外的操作。

2）減少不必要的端口暴露

配置過k8s的都清楚, 第一步是要關閉防火墻的, 主要原因是k8s的很多服務會以NodePort方式映射出去, 這樣就相當于給宿主機打了很多孔, 既不安全也不優(yōu)雅. 而Ingress可以避免這個問題, 除了Ingress自身服務可能需要映射出去, 其他服務都不要用NodePort方式。

4、部署ingress（deployment的方式）

1）配置文件準備（粘貼下面網(wǎng)址的yanl文件）

github連接地址：

https://github.com/kubernetes/ingress-nginx/blob/master/deploy/static/mandatory.yaml

或者

https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/mandatory.yaml

2）配置文件介紹和設置ingress的網(wǎng)絡模式

1> namespace.yaml

創(chuàng)建一個獨立的命名空間 ingress-nginx。

2> configmap.yaml

ConfigMap是存儲通用的配置變量的，類似于配置文件，使用戶可以將分布式系統(tǒng)中用于不同模塊的環(huán)境變量統(tǒng)一到一個對象中管理；而它與配置文件的區(qū)別在于它是存在集群的“環(huán)境”中的，并且支持K8S集群中所有通用的操作調用方式。

從數(shù)據(jù)角度來看，ConfigMap的類型只是鍵值組，用于存儲被Pod或者其他資源對象（如RC）訪問的信息。這與secret的設計理念有異曲同工之妙，主要區(qū)別在于ConfigMap通常不用于存儲敏感信息，而只存儲簡單的文本信息。

ConfigMap可以保存環(huán)境變量的屬性，也可以保存配置文件。

創(chuàng)建pod時，對configmap進行綁定，pod內(nèi)的應用可以直接引用ConfigMap的配置。相當于configmap為應用/運行環(huán)境封裝配置。
pod使用ConfigMap，通常用于：設置環(huán)境變量的值、設置命令行參數(shù)、創(chuàng)建配置文件。

3> default-backend.yaml

如果外界訪問的域名不存在的話，則默認轉發(fā)到default-http-backend這個Service，其會直接返回404。

4> rbac.yaml

負責Ingress的RBAC授權的控制，其創(chuàng)建了Ingress用到的ServiceAccount、ClusterRole、Role、RoleBinding、ClusterRoleBinding。

5> with-rbac.yaml

是Ingress的核心，用于創(chuàng)建ingress-controller。前面提到過，ingress-controller的作用是將新加入的Ingress進行轉化為Nginx的配置。

6> 各文件的作用：

  • configmap.yaml:提供configmap可以在線更新nginx的配置
  • default-backend.yaml:提供一個缺省的后臺錯誤頁面 404
  • namespace.yaml:創(chuàng)建一個獨立的命名空間 ingress-nginx
  • rbac.yaml:創(chuàng)建對應的role rolebinding 用于rbac
  • tcp-services-configmap.yaml:修改L4負載均衡配置的configmap
  • udp-services-configmap.yaml:修改L4負載均衡配置的configmap
  • with-rbac.yaml:有應用rbac的nginx-ingress-controller組件

3）修改配置文件

設置 hostNetwork: true

由于ingress 使用到物理機的80/443 端口，所以需要設置為hostNetwork模式

4）拉取鏡像（通過查看ingress的yaml文件可以看出）和創(chuàng)建svc文件

拉取鏡像

docker pull quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.30.0

或者

docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/nginx-ingress-controller:0.30.0
kubectl apply -f mandatory.yaml

創(chuàng)建svc：https://github.com/kubernetes/ingress-nginx/blob/master/deploy/baremetal/service-nodeport.yaml

5）指定運行節(jié)點（需要打標簽）

nginx-ingress-controller會隨意選擇一個node節(jié)點運行pod，為此需要我們把nginx-ingress-controller運行到指定的node節(jié)點上
首先需要給需要運行nginx-ingress-controller的node節(jié)點打標簽，在此我們把nginx-ingress-controller運行在指定的node節(jié)點上

kubectl get nodes –show-labels         #先查看各個node上的lables信息
kubectl label nodes node3 nginx=nginx  #給node3打標簽
kubectl get nodes –show-labels         #查看node3上的lables

修改ingress的yaml文件中的標簽

5、部署ingress（DaemonSet的方式）

官方原始文件使用的是deployment，replicate 為 1，這樣將會在某一臺節(jié)點上啟動對應的nginx-ingress-controller pod。外部流量訪問至該節(jié)點，由該節(jié)點負載分擔至內(nèi)部的service。測試環(huán)境考慮防止單點故障，改為DaemonSet然后刪掉replicate ，配合親和性部署在制定節(jié)點上啟動nginx-ingress-controller pod，確保有多個節(jié)點啟動nginx-ingress-controller pod，后續(xù)將這些節(jié)點加入到外部硬件負載均衡組實現(xiàn)高可用性。

1）添加hostNetwork

true：添加該字段，暴露nginx-ingress-controller pod的服務端口（80）

2）添加親和性屬性

增加親和性部署，有custom/ingress-controller-ready 標簽的節(jié)點才會部署該DaemonSet

3）設置節(jié)點的label

kubectl label nodes node2 custem/ingress-controller-ready=true
kubectl label nodes node3 custem/ingress-controller-ready=true
kubectl label nodes node4 custem/ingress-controller-ready=true

4）修改yaml文件（和deployment部署ingress的文件一樣，只需要修改此處即可）

4）執(zhí)行并部署ingress

完整版文件如下

cat mandatory-deamon.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: Deployment
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: 2
  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:
      hostNetwork: true
      # wait up to five minutes for the drain of connections
      terminationGracePeriodSeconds: 300
      serviceAccountName: nginx-ingress-serviceaccount
      nodeSelector:
        kubernetes.io/os: linux
        custem/ingress-controller-ready: 'true'
      tolerations:
        - key: "kubernetes.io/os"
          operator: "Equal"
          value: "linux"
          effect: "NoSchedule"
      containers:
        - name: nginx-ingress-controller
          image: www.my.com/k8s/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
kubectl apply -f mandatory-deamon.yaml
kubectl get ds -n ingress-nginx 
kubectl get pod -n ingress-nginx  -o wide

注意：大家可能會想node2上也打了標簽，為什么node2上沒有；原因很簡單，我的node2是master，已經(jīng)有了污點的標簽，從親和性上就已經(jīng)不再容忍任何pod運行到master上，所以只能看到node3和node4上有nginx-ingress的pod。

6、案例測試

1）創(chuàng)建deployment模板并修改

kubectl create deployment httpd --image=www.my.com/web/httpd:latest --dry-run -o yaml > http-dep.yaml

2）創(chuàng)建svc模板并修改

kubectl expose deployment httpd --port=8000 --target-port=80 --type=ClusterIP  --dry-run -o yaml > http-svc.yaml

3）測試訪問

curl 10.1.95.78:8000

4）創(chuàng)建ingress

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: httpd
  namespace: default
spec:
  rules:
  - host: www.http123.com
    http:
      paths:
      - path: /
        backend:
          serviceName: httpd
          servicePort: 8000

5）綁定hosts，瀏覽器測試

也可以使用dns服務器，通過自建的dns服務器完成域名解析，從而避免頻繁的修改hosts文件

詳見輕量級域名解析服務器之dnsmasq

C:\Windows\System32\drivers\etc\hosts添加10.10.0.111 www.http123.com

總結

到此這篇關于k8s之ingress-nginx詳解和部署方案的文章就介紹到這了,更多相關ingress-nginx部署方案內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

相關文章

  • ES業(yè)務數(shù)據(jù)遷移遇到的精度問題BUG

    ES業(yè)務數(shù)據(jù)遷移遇到的精度問題BUG

    這篇文章主要為大家介紹了ES業(yè)務數(shù)據(jù)遷移遇到的BUG精度問題，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進步，早日升職加薪
    2022-06-06
  • 詳解kubernetes pod的編排和生命周期

    詳解kubernetes pod的編排和生命周期

    這篇文章主要介紹了kubernetes pod的編排和生命周期的相關資料，幫助大家更好的理解和學習使用K8S，感興趣的朋友可以了解下
    2021-04-04
  • K8S?Operator部署及自定義詳解

    K8S?Operator部署及自定義詳解

    這篇文章主要為大家介紹了K8S?Operator部署及自定義詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進步，早日升職加薪
    2023-04-04
  • kubeadm?搭建?K8s的詳細過程

    kubeadm?搭建?K8s的詳細過程

    這篇文章主要介紹了kubeadm?搭建?K8s詳細過程，環(huán)境使用?VirtualBox?構建的3臺虛擬機，虛擬機網(wǎng)絡配置的相關步驟給大家介紹的非常詳細,需要的朋友可以參考下
    2022-04-04
  • 使用k8tz解決pod內(nèi)的時區(qū)問題(坑的解決)

    使用k8tz解決pod內(nèi)的時區(qū)問題(坑的解決)

    時區(qū)的不一致，會帶來很多困擾。即使代碼與時區(qū)無關，但容器日志與系統(tǒng)日志時間相關聯(lián)排查問題也會讓人頭疼，這篇文章主要介紹了使用k8tz優(yōu)雅的解決pod內(nèi)的時區(qū)問題,需要的朋友可以參考下
    2022-10-10
  • kubernetes-1.25.6二進制部署方式

    kubernetes-1.25.6二進制部署方式

    這篇文章主要介紹了kubernetes-1.25.6二進制部署方式,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教
    2024-07-07
  • 一篇文章讀懂K8S的PV和PVC以及實踐攻略

    一篇文章讀懂K8S的PV和PVC以及實踐攻略

    本文詳細介紹了Kubernetes中的存儲卷（Volume）機制,包括PersistentVolume（PV）、PersistentVolumeClaim（PVC）及其與后端存儲的關系,文中通過代碼介紹的非常詳細,需要的朋友可以參考下
    2024-10-10
  • k8s查看pod日志的幾種實用方法匯總

    k8s查看pod日志的幾種實用方法匯總

    Pod是Kubernetes中能夠創(chuàng)建和部署的最小單元,是Kubernetes集群中的一個應用實例,總是部署在同一個節(jié)點Node上,下面這篇文章主要給大家介紹了k8s查看pod日志的幾種實用方法,需要的朋友可以參考下
    2022-07-07
  • k8s安裝CICD?devtron過程詳解

    k8s安裝CICD?devtron過程詳解

    這篇文章主要為大家介紹了k8s安裝CICD?devtron過程詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進步，早日升職加薪
    2022-11-11
  • kubernetes YAML文件的使用

    kubernetes YAML文件的使用

    這篇文章主要介紹了kubernetes YAML文件的使用，幫助大家更好的理解和學習使用kubernetes，感興趣的朋友可以了解下
    2021-04-04

最新評論