資訊專欄INFORMATION COLUMN
摘要：前言最近在產品新版本的服務發現和負載均衡方案上遇到了一個問題，在盡量不改動原生使用方式和代碼前提下，對又重新復習了一遍，略有體會。所有訪問該的請求，都會被轉發到后端的中。使用這種方案的原因，不外乎是外部無法訪問容器服務。
前言
最近在產品新版本的服務發現和負載均衡方案上遇到了一個問題，在盡量不改動原生k8s使用方式和代碼前提下，對service又重新復習了一遍，略有體會。
Servicek8s中service是一個面向微服務架構的設計，它從k8s本身解決了容器集群的負載均衡，并開放式地支持了用戶所需要的各種負載均衡方案和使用場景。
通常，一個service被創建后會在集群中創建相應的endpoints，隨后，controller-manager中的endpointsController會去檢查并向該endpoints填入關于這個service，符合下述所有條件的后端端點（即pod）：
相同的namespace；
pod的labels能滿足service.Spec.selector（除非service.Spec.selector為空，這種情況下不會自動創建endpoints）；
如果service開放了port，且是以字符串名字的形式（targetPort=[字符串]），則相應的pod的某個container中必須有配置同名的port；
當endpoints被更新后，kube-proxy會感知，并根據更新后的endpoints，在宿主機上做轉發規則的配置，kube-proxy目前支持iptables、ipvs兩種負載均衡方式，默認是iptables。
DNS絕大部分使用k8s的人都會使用kubedns做服務發現和service domain的解析。kubedns會建立長連接即時檢查service的變化，一旦發現有service被創建，會根據service的類型，在數據庫中構建service domain 到指定的CNAME或IP（cluster-IP）的映射，作為對該service domain 的dns解析結果。
service 的類型 ClusterIP最普遍的service類型，也是默認類型。ClusterIP類型的service創建時，k8s會通過etcd從可分配的IP池中分配一個IP，該IP全局唯一，且不可修改。所有訪問該IP的請求，都會被iptables轉發到后端的endpoints中。
該類型下，service的cluster-ip會作為kube-dns的解析結果，返回給客戶端。基本上這是私有云中服務內部常用的方案，但是也只能集群內服務互相訪問。
NodePort通過node的IP進行地址轉換實現服務的可訪問性，外部訪問集群中任意一個node：port即可以訪問服務。
舉個例子:一個單副本的deployment，其pod運行在node2上，通過nodePort方式開放服務，外部client訪問node1_ip:port即可訪問到容器服務。這個過程中原理是：
client訪問node1_ip:port
node1對數據包做SNAT，將來源地址改成node1_ip
node1對數據包做DNAT,將目的地址改成node2_ip
node2收到數據包，根據port查找自身的端口，這個端口在service創建時就會與自身運行的port做映射，所以這里數據包會被轉發到真實的容器中
數據響應由容器發給node1，node1再返回給client
這種方案下，node上會產生端口的占用，所以要確保端口可用性。
另外，通過指定service.spec.externalTrafficPolicy=Local可以設置node上kube-proxy不轉發到其他node，參照上面的例子，由于node1沒有響應的pod在運行，所以node1上會直接drop數據包。
使用這種方案的原因，不外乎是：外部無法訪問容器服務。
LoadBalancer需要外部支持（GCP and Azure），用戶訪問service.spec.external-ip,該IP對應到一個外部負載均衡的vip，外部服務對這個vip的請求，會被loadbalancer通過健康檢查和轉發，發送到一個運行著該服務pod的node上，并同樣通過nodePort里的端口映射，發送給容器。
上述是幾種比較普遍的service，隨著社區發展，又出現了一些新的類型，可以做更靈活的適配。
ExternalName用戶可以指定一個任意的名字，作為該service被解析的CNAME,這種類型的servcie不用指定clusterIP，因此kube-proxy不會管理這類service，這類service需要使用1.7版本以上的kubedns。比如用戶想創建一個service，但要讓所有容器訪問該service的請求都引導到用戶自己定義的外部域名服務，就可以通過這個方式實現?？梢哉f這個是最自由的一個方式：你希望服務被如何解析，服務就能被如何解析。你甚至可以給多個service配置同一個externalName。
headless serviceheadless service是一個特殊的ClusterIP類service，這種service創建時不指定clusterIP(--cluster-ip=None)，因為這點，kube-proxy不會管這種service，于是node上不會有相關的iptables規則。
當headless service有配置selector時，其對應的所有后端節點，會被記錄到dns中，在訪問service domain時kube-dns會將所有endpoints返回，選擇哪個進行訪問則是系統自己決定；
當selector設置為空時，headless service會去尋找相同namespace下與自己同名的pod作為endpoints。這一點被應用到statefulset中，當一個三副本的statefulset（mysql1，mysql2,mysql3）運行在不同節點時，我們可以通過域名的方式對他們分別訪問。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/32648.html
摘要：與已運行相關的過濾規則負責檢查待調度與上已有之間的親和性關系。并且每個打分函數都可以配置對應的權重值，下面介紹調度器策略配置時，也會涉及權重值的配置。默認權重值是，如果覺得某個打分函數特別重要，便可以加大該權重值。 一、概述 Kubernetes 是 Google 開源的容器集群管理系統（谷歌內部:Borg），而今天要介紹的 kube-scheduler 是 k8s 系統的核心組件之一...
摘要：本文將主要分析原生的網絡策略。筆者認為這個問題主要是因為使用者不了解網絡策略的省缺行為?？蛇x字段，字符串，策略規則類型，表示該網絡策略中包含哪些類型的策略，可選為或?；ハ嚅g為或的關系，滿足其中一條則放行。標準，除了指定的放行外其他都禁止。 k8s中的網絡策略主要分為原生 NetworkPolicy 和第三方網絡插件提供的網絡策略。本文將主要分析原生Networkpolicy的網絡策略。...
摘要：簡稱，是在年發布的一個開源項目。網絡要能夠通信，必須部署網絡，是其中一個可選方案。最常使用，可以管理多個副本，并確保按照期望的狀態運行，底層調用。用于每個最多只運行一個副本的場景。 Kubernetes 簡稱 k8s，是 google 在 2014 年發布的一個開源項目。 Kubernetes 解決了哪些問題？ 真實的生產環境應用會包含多個容器，而這些容器還很可能會跨越多個服務器主機部...
摘要：年月的華為大會上，兩人開始了對的討論。聯合創始人及梁勝在月上海中，聯合華為布道華為云和以下簡稱的合作由來已久。這一觀點與梁勝的看法不謀而合。甫一見面，方璞便向梁勝拋出了一個重磅問題：在K8S之后，你覺得未來最有前途的容器技術是什么呢？方璞是華為云容器服務域的產品總監，主要負責華為云容器的構建和部署。我覺得是Istio。方璞說。2016年9月的華為CONNECT大會上，兩人開始了對Istio的...
摘要：組件會給每個分配一個，則替代了的來實現服務發現，在的容器內部依然可以訪問服務來獲取元數據信息。的需要在中實現一個，目前只有，而則維護了自己的版本在其中提供了。 在Rancher 1.0版本開始，Rancher逐步增加了Kubernetes、Swarm、Mesos等多編排引擎的支持，很多朋友就此產生了疑惑，諸如Cattle引擎和這幾個之間到底什么關系？每種引擎是如何支持的？自家的業務環境...
閱讀 2189·2021-11-15 11:38
閱讀 1151·2021-09-06 15:02
閱讀 3380·2021-08-27 13:12
閱讀 1353·2019-08-30 14:20
閱讀 2389·2019-08-29 15:08
閱讀 636·2019-08-29 14:08
閱讀 1723·2019-08-29 13:43
閱讀 1464·2019-08-26 12:11
