<ruby id="bdb3f"></ruby>

    <p id="bdb3f"><cite id="bdb3f"></cite></p>

      <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
        <p id="bdb3f"><cite id="bdb3f"></cite></p>

          <pre id="bdb3f"></pre>
          <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

          <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
          <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

          <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                <ruby id="bdb3f"></ruby>

                ThinkChat2.0新版上線,更智能更精彩,支持會話、畫圖、視頻、閱讀、搜索等,送10W Token,即刻開啟你的AI之旅 廣告
                # 如何訪問K8S中的服務 ![image](https://i.imgur.com/UYvC8Il.png) # Ingress 介紹 Kubernetes 暴露服務的方式目前只有三種:LoadBlancer Service、NodePort Service、Ingress;前兩種估計都應該很熟悉,具體的可以參考下 [這篇文](https://mritd.me/2016/12/06/try-traefik-on-kubernetes//)章;下面詳細的嘮一下這個 Ingress # Ingress 是個什么玩意 可能從大致印象上 Ingress 就是能利用 Nginx、Haproxy 啥的負載均衡器暴露集群內服務的工具;那么問題來了,集群內服務想要暴露出去面臨著幾個問題: - #### Pod 漂移問題 眾所周知 Kubernetes 具有強大的副本控制能力,能保證在任意副本(Pod)掛掉時自動從其他機器啟動一個新的,還可以動態擴容等,總之一句話,這個 Pod 可能在任何時刻出現在任何節點上,也可能在任何時刻死在任何節點上;那么自然隨著 Pod 的創建和銷毀,Pod IP 肯定會動態變化;那么如何把這個動態的 Pod IP 暴露出去?這里借助于 Kubernetes 的 Service 機制,Service 可以以標簽的形式選定一組帶有指定標簽的 Pod,并監控和自動負載他們的 Pod IP,那么我們向外暴露只暴露 Service IP 就行了;這就是 NodePort 模式:即在每個節點上開起一個端口,然后轉發到內部 Service IP 上,如下圖所示 ![image](https://i.imgur.com/4Sc7zCj.jpg) - #### 端口管理問題 采用 NodePort 方式暴露服務面臨一個坑爹的問題是,服務一旦多起來,NodePort 在每個節點上開啟的端口會及其龐大,而且難以維護;這時候引出的思考問題是 “能不能使用 Nginx 啥的只監聽一個端口,比如 80,然后按照域名向后轉發?” 這思路很好,簡單的實現就是使用 DaemonSet 在每個 node 上監聽 80,然后寫好規則,因為 Nginx 外面綁定了宿主機 80 端口(就像 NodePort),本身又在集群內,那么向后直接轉發到相應 Service IP 就行了,如下圖所示 ![image](https://i.imgur.com/eGRg6UN.jpg) - #### 域名分配及動態更新問題 從上面的思路,采用 Nginx 似乎已經解決了問題,但是其實這里面有一個很大缺陷:每次有新服務加入怎么改 Nginx 配置?總不能手動改或者來個 Rolling Update 前端 Nginx Pod 吧?這時候 “偉大而又正直勇敢的” Ingress 登場,如果不算上面的 Nginx,Ingress 只有兩大組件:Ingress Controller 和 Ingress Ingress 這個玩意,簡單的理解就是 你原來要改 Nginx 配置,然后配置各種域名對應哪個 Service,現在把這個動作抽象出來,變成一個 Ingress 對象,你可以用 yml 創建,每次不要去改 Nginx 了,直接改 yml 然后創建/更新就行了;那么問題來了:”Nginx 咋整?” Ingress Controller 這東西就是解決 “Nginx 咋整” 的;Ingress Controoler 通過與 Kubernetes API 交互,動態的去感知集群中 Ingress 規則變化,然后讀取他,按照他自己模板生成一段 Nginx 配置,再寫到 Nginx Pod 里,最后 reload 一下,工作流程如下圖 ![image](https://i.imgur.com/Ws2gBHl.jpg) 當然在實際應用中,最新版本 Kubernetes 已經將 Nginx 與 Ingress Controller 合并為一個組件,所以 Nginx 無需單獨部署,只需要部署 Ingress Controller 即可。 # 懟一個 Nginx Ingress 上面啰嗦了那么多,只是為了講明白 Ingress 的各種理論概念,下面實際部署很簡單 ### 配置 ingress RBAC cat nginx-ingress-controller-rbac.yml #apiVersion: v1 #kind: Namespace #metadata: # name: kube-system --- apiVersion: v1 kind: ServiceAccount metadata: name: nginx-ingress-serviceaccount namespace: kube-system --- apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRole metadata: name: nginx-ingress-clusterrole 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: kube-system 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 - create - update --- apiVersion: rbac.authorization.k8s.io/v1beta1 kind: RoleBinding metadata: name: nginx-ingress-role-nisa-binding namespace: kube-system roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: nginx-ingress-role subjects: - kind: ServiceAccount name: nginx-ingress-serviceaccount namespace: kube-system --- apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRoleBinding metadata: name: nginx-ingress-clusterrole-nisa-binding roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: nginx-ingress-clusterrole subjects: - kind: ServiceAccount name: nginx-ingress-serviceaccount namespace: kube-system ### 部署默認后端 我們知道 前端的 Nginx 最終要負載到后端 service 上,那么如果訪問不存在的域名咋整?官方給出的建議是部署一個 默認后端,對于未知請求全部負載到這個默認后端上;這個后端啥也不干,就是返回 404,部署如下 kubectl create -f default-backend.yaml 這個 default-backend.yaml 文件可以在 github [Ingress 倉庫](https://github.com/kubernetes/ingress-nginx/tree/master) 找到. 針對官方配置 我們單獨添加了 nodeselector 指定,綁定LB地址 以方便DNS 做解析。 cat default-backend.yaml apiVersion: extensions/v1beta1 kind: Deployment metadata: name: default-http-backend labels: k8s-app: default-http-backend namespace: kube-system spec: replicas: 1 template: metadata: labels: k8s-app: default-http-backend spec: terminationGracePeriodSeconds: 60 containers: - name: default-http-backend # Any image is permissable as long as: # 1. It serves a 404 page at / # 2. It serves 200 on a /healthz endpoint image: harbor-demo.dianrong.com/kubernetes/defaultbackend:1.0 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 nodeSelector: kubernetes.io/hostname: 172.16.200.209 --- apiVersion: v1 kind: Service metadata: name: default-http-backend namespace: kube-system labels: k8s-app: default-http-backend spec: ports: - port: 80 targetPort: 8080 selector: k8s-app: default-http-backend ### 部署 Ingress Controller 部署完了后端就得把最重要的組件 Nginx+Ingres Controller(官方統一稱為 Ingress Controller) 部署上 kubectl create -f nginx-ingress-controller.yaml 注意: 官方的 Ingress Controller 有個坑,默認注釋了hostNetwork 工作方式。以防止端口的在宿主機的沖突。沒有綁定到宿主機 80 端口,也就是說前端 Nginx 沒有監聽宿主機 80 端口(這還玩個卵啊);所以需要把配置搞下來自己加一下 hostNetwork cat nginx-ingress-controller.yaml apiVersion: extensions/v1beta1 kind: Deployment metadata: name: nginx-ingress-controller labels: k8s-app: nginx-ingress-controller namespace: kube-system spec: replicas: 1 template: metadata: labels: k8s-app: nginx-ingress-controller spec: # hostNetwork makes it possible to use ipv6 and to preserve the source IP correctly regardless of docker configuration # however, it is not a hard dependency of the nginx-ingress-controller itself and it may cause issues if port 10254 already is taken on the host # that said, since hostPort is broken on CNI (https://github.com/kubernetes/kubernetes/issues/31307) we have to use hostNetwork where CNI is used # like with kubeadm # hostNetwork: true terminationGracePeriodSeconds: 60 hostNetwork: true serviceAccountName: nginx-ingress-serviceaccount containers: - image: harbor-demo.dianrong.com/kubernetes/nginx-ingress-controller:0.9.0-beta.1 name: nginx-ingress-controller readinessProbe: httpGet: path: /healthz port: 10254 scheme: HTTP livenessProbe: httpGet: path: /healthz port: 10254 scheme: HTTP initialDelaySeconds: 10 timeoutSeconds: 1 ports: - containerPort: 80 hostPort: 80 - containerPort: 443 hostPort: 443 env: - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace args: - /nginx-ingress-controller - --default-backend-service=$(POD_NAMESPACE)/default-http-backend # - --default-ssl-certificate=$(POD_NAMESPACE)/ingress-secret nodeSelector: kubernetes.io/hostname: 172.16.200.102 ### 部署 Ingress 從上面可以知道 Ingress 就是個規則,指定哪個域名轉發到哪個 Service,所以說首先我們得有個 Service,當然 Service 去哪找這里就不管了;這里默認為已經有了兩個可用的 Service,以下以 Dashboard 為例 先寫一個 Ingress 文件,語法格式啥的請參考 官方文檔,由于我的 Dashboard 都在kube-system 這個命名空間,所以要指定 namespace. apiVersion: extensions/v1beta1 kind: Ingress metadata: name: dashboard-ingress namespace: kube-system annotations: kubernetes.io/ingress.class: "nginx" spec: rules: - host: fox-dashboard.dianrong.com http: paths: - backend: serviceName: kubernetes-dashboard servicePort: 80 裝逼成功截圖如下 ![image](https://i.imgur.com/AmVOgxK.png) ### 部署 Ingress TLS 上面已經搞定了 Ingress,下面就順便把 TLS 懟上;官方給出的樣例很簡單,大致步驟就兩步:創建一個含有證書的 secret、在 Ingress 開啟證書;但是我不得不噴一下,文檔就提那么一嘴,大坑一堆,比如多域名配置,TLS功能的啟動都沒。啟用tls 需要在 nginx-ingress-controller添加參數,上面的controller以配置好。 --default-ssl-certificate=$(POD_NAMESPACE)/ingress-secret ### 證書格式轉換 創建secret 需要使用你的證書文件,官方要求證書的編碼需要使用base64。轉換方法如下: 證書轉換pem 格式: openssl x509 -inform DER -in cert/doamin.crt -outform PEM -out cert/domain.pem 證書編碼轉換base64 cat domain.crt | base64 > domain.crt.base64 ### 創建 secret ,需要使用base64 編碼格式證書。 cat ingress-secret.yml apiVersion: v1 data: tls.crt: LS0tLS1CRU tls.key: LS0tLS1CRU kind: Secret metadata: name: ingress-secret namespace: kube-system type: Opaque 其實這個配置比如證書轉碼啥的沒必要手動去做,可以直接使用下面的命令創建,kubectl 將自動為我們完整格式的轉換。 kubectl create secret tls ingress-secret --key certs/ttlinux.com.cn-key.pem --cert certs/ttlinux.com.cn.pem ### 重新部署 Ingress 生成完成后需要在 Ingress 中開啟 TLS,Ingress 修改后如下 cat dashboard-ingress.yml apiVersion: extensions/v1beta1 kind: Ingress metadata: name: dashboard-ingress namespace: kube-system annotations: kubernetes.io/ingress.class: "nginx" spec: tls: - hosts: - fox-dashboard.dianrong.com secretName: ingress-secret rules: - host: fox-dashboard.dianrong.com http: paths: - backend: serviceName: kubernetes-dashboard servicePort: 80 注意:一個 Ingress 只能使用一個 secret(secretName 段只能有一個),也就是說只能用一個證書,更直白的說就是如果你在一個 Ingress 中配置了多個域名,那么使用 TLS 的話必須保證證書支持該 Ingress 下所有域名;并且這個 secretName 一定要放在上面域名列表最后位置,否則會報錯 did not find expected key 無法創建;同時上面的 hosts 段下域名必須跟下面的 rules 中完全匹配 更需要注意一點:之所以這里單獨開一段就是因為有大坑;Kubernetes Ingress 默認情況下,當你不配置證書時,會默認給你一個 TLS 證書的,也就是說你 Ingress 中配置錯了,比如寫了2個 secretName、或者 hosts 段中缺了某個域名,那么對于寫了多個 secretName 的情況,所有域名全會走默認證書;對于 hosts 缺了某個域名的情況,缺失的域名將會走默認證書,部署時一定要驗證一下證書,不能 “有了就行”;更新 Ingress 證書可能需要等一段時間才會生效 最后重新部署一下即可 kubectl delete -f dashboard-ingress.yml kubectl create -f dashboard-ingress.yml 部署 TLS 后 80 端口會自動重定向到 443,最終訪問截圖如下 ![image](https://i.imgur.com/CXLDMHV.png) ### ingress 高級用法 ![image](https://i.imgur.com/cZ6gqVi.png) - lvs 反向代理到 物理nginx。完成https拆包,繼承nginx所有功能 - nginx 反向代理到ingress-control。 ingress-control 有兩種部署方式 。 - ingress-control 使用nodePort 方式暴漏服務 - ingress-control 使用hostNetwork 方式暴漏服務 #### 總結分析 1. ingress-control 在自己的所屬的namespace=ingress, 是可以夸不同namespace提供反向代理服. 1. 如果需要提供夸NS 訪問ingress,先給 ingress-control創建RBAC . 1. ingress-control 使用hostnetwork 模式 性能比使用service nodePort 性能好很多。因為hostnetwork 是直接獲取pod 的IP? ![Orchestrate Common Functionality](https://box.kancloud.cn/4a65334f34670910fc40eebe1b421c1b_1079x1014.png)
                  <ruby id="bdb3f"></ruby>

                  <p id="bdb3f"><cite id="bdb3f"></cite></p>

                    <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
                      <p id="bdb3f"><cite id="bdb3f"></cite></p>

                        <pre id="bdb3f"></pre>
                        <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

                        <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
                        <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

                        <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                              <ruby id="bdb3f"></ruby>

                              哎呀哎呀视频在线观看