如何配置kubernetes-aws中的集群IP？

Question

我是kubernetes的新手，剛剛在AWS上使用kube-up獲得了kubernetes v.1.3.5集群。 到目前為止，我一直在玩kubernetes來理解它的機制（節點，pods，svc和東西）。 基於我最初（或可能粗略）的理解，我幾乎沒有問題：

1）如何路由到集群IP在這里工作（即在kube-aws中）？ 我看到服務的IP在10.0.0.0/16范圍內。 我使用rc = 3的股票nginx進行了部署，然后通過暴露節點端口將服務附加到它。 一切都很棒！ 我可以從我的開發機器連接到該服務。 此nginx服務的群集IP為10.0.33.71:1321。 現在，如果我ssh到其中一個minions（或節點或VMS）並執行“telnet 10.0.33.71 1321”，它會按預期連接。 但我無能為力如何工作，我在kubernetes的VPC設置中找不到與10.0.0.0/16相關的任何路由。 在這里引起了什么確實會導致像telnet這樣的app成功連接？ 但是，如果我進入主節點並執行“telnet 10.0.33.71 1321”，它將無法連接。 為什么它無法從主站連接？

2）每個節點內都有一個cbr0接口。 每個minion節點的cbr0配置為10.244.x.0 / 24，master的cbr0配置為10.246.0.0/24。 我可以從任何節點（包括主節點）ping到任何10.244.xx pod。 但是我無法從任何一個minion節點ping 10.246.0.1（主節點內的cbr0）。 這可能發生什么？

這是由kubernetes在aws中建立的路線。 VPC。

Destination     Target
172.20.0.0/16   local
0.0.0.0/0       igw-<hex value>
10.244.0.0/24   eni-<hex value> / i-<hex value>
10.244.1.0/24   eni-<hex value> / i-<hex value>
10.244.2.0/24   eni-<hex value> / i-<hex value>
10.244.3.0/24   eni-<hex value> / i-<hex value>
10.244.4.0/24   eni-<hex value> / i-<hex value>
10.246.0.0/24   eni-<hex value> / i-<hex value>

Answer 1

Mark Betz （ Olark的SRE ）在三篇文章中介紹了Kubernetes網絡：

• 莢
• 服務 ：
• 進入

對於pod，您正在查看：

你發現：

• etho0 ：一個“物理網絡接口”
• docker0 / cbr0 ：用於連接兩個以太網段的橋 ，無論其協議如何。
• veth0 ， 1 ， 2 ：虛擬網絡接口，每個容器中的一個。
  docker0是默認網關 veth0的。 它被命名為“自定義橋”的cbr0 。
  Kubernetes通過共享相同的veth0來啟動容器，這意味着每個容器必須暴露不同的端口。
• pause ：一個特殊容器以“ pause ”開始，檢測發送到pod的SIGTERM，並將其轉發給容器。
• 節點 ：主機
• 集群 ：一組節點
• 路由器/網關

事情的最后一個方面是事情開始變得更加復雜：

Kubernetes為每個節點上的網橋分配總地址空間，然后根據構建網橋的節點分配該空間內的網橋地址。
其次，它增加了路由規則在10.100.0.1網關告訴它如何往每個橋的包應路由，即哪個節點的eth0橋梁，可以通過達成。

虛擬網絡接口，網橋和路由規則的這種組合通常稱為覆蓋網絡 。

當pod與另一個pod聯系時，它將通過一項服務 。
為什么？

群集中的Pod網絡是很好的東西，但是它本身不足以支持創建持久的系統。 那是因為Kubernetes的豆莢是短暫的 。
您可以使用pod IP地址作為端點，但無法保證下次重新創建pod時地址不會更改 ，這可能由於多種原因而發生。

這意味着：您需要一個反向代理/動態負載均衡器。 而且它更有彈性。

服務是一種kubernetes資源，可以將代理配置為將請求轉發到一組pod 。
將接收流量的一組容器由選擇器確定，該選擇器匹配在創建容器時分配給容器的標簽

該服務使用自己的網絡。 默認情況下，其類型為“ ClusterIP ”; 它有自己的IP。

這是兩個pod之間的通信路徑：

它使用kube-proxy 。
此代理自身使用netfilter 。

netfilter是一個基於規則的數據包處理引擎 。
它在內核空間中運行，並查看其生命周期中各個點的每個數據包。
它根據規則匹配數據包，當它找到匹配它的規則時，將采取指定的操作。
它可以采取的許多行動包括將數據包重定向到另一個目的地。

在這種模式下，kube-proxy：

• 在本地主機接口上打開一個端口 （上例中的10400）以偵聽對測試服務的請求，
• 插入netfilter規則，將目的地為服務IP的數據包重新路由到自己的端口 ，以及
• 將這些請求轉發到端口8080上的pod。

這就是對10.3.241.152:80的請求神奇地成為對10.0.2.2:8080的請求的10.0.2.2:8080 。
鑒於netfilter的功能，所有這些都需要使所有服務都能用於kube-proxy以打開端口並為該服務插入正確的netfilter規則，以響應來自主api服務器的更改的通知。集群。

但：

這個故事還有一點點扭曲。
我在上面提到過， 由於編組數據包 ， 用戶空間代理很昂貴 。 在kubernetes 1.2中， kube-proxy獲得了在iptables模式下運行的能力 。

在這種模式下，kube-proxy通常不再是集群間連接的代理，而是委托netfilter檢測綁定服務IP的數據包並將其重定向到pods，所有這些都發生在內核空間中。
在這種模式下，kube-proxy的工作或多或少局限於保持netfilter規則同步。

網絡架構變為：

但是，這不適合需要外部固定IP的外部 （面向公眾）通信。

您有專門的服務： nodePort和LoadBalancer ：

NodePort類型的服務是具有附加功能的ClusterIP服務：它可以在節點的IP地址以及服務網絡上分配的群集IP上訪問。
這樣做的方式非常簡單：

當kubernetes創建NodePort服務時， kube-proxy分配范圍為30000-32767的端口，並在每個節點的eth0接口上打開此端口（因此名稱為“NodePort”） 。

與此端口的連接將轉發到服務的群集IP。

你得到：

Loadbalancer更先進，允許使用stand端口公開服務。
請參閱此處的映射：

$ kubectl get svc service-test
NAME      CLUSTER-IP      EXTERNAL-IP     PORT(S)          AGE
openvpn   10.3.241.52     35.184.97.156   80:32213/TCP     5m

然而：

LoadBalancer類型的服務有一些限制。

• 您無法配置lb以終止https流量。
• 您無法執行虛擬主機或基於路徑的路由， 因此您無法使用單個負載平衡器以任何實用的方式代理多個服務 。

這些限制導致在版本1.2中添加了用於配置負載平衡器的單獨kubernetes資源，稱為Ingress 。

Ingress API支持TLS終止，虛擬主機和基於路徑的路由 。 它可以輕松設置負載均衡器來處理多個后端服務。
該實現遵循基本的kubernetes模式：資源類型和管理該類型的控制器。
在這種情況下，資源是Ingress，其包括對網絡資源的請求

例如：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test-ingress
  annotations:
    kubernetes.io/ingress.class: "gce"
spec:
  tls:
    - secretName: my-ssl-secret
  rules:
  - host: testhost.com
    http:
      paths:
      - path: /*
        backend:
          serviceName: service-test
          servicePort: 80

入口控制器負責通過將環境中的資源驅動到必要狀態來滿足該請求。
使用Ingress時，您可以創建類型為NodePort的服務，並讓入口控制器弄清楚如何獲取節點的流量。

GCE負載平衡器，AWS彈性負載平衡器以及NGiNX和HAproxy等流行代理都有入口控制器實現。