優勢知識Kubernetes 網絡訓練營第2期

時間 2021-08-12

標籤 html node linux git github docker 數據庫編程 segmentfault api 欄目系統網絡简体版

原文原文鏈接

愛分享愛生活加油 2021

百度網盤html

提取碼：qhhv

K8S 底層網絡所須要解決的兩個問題node

協助 k8s , 給每一個 NODE上的 docker 容器都分配互相不衝突的 IP
在這些 IP 地址之間簡歷一個覆蓋網絡(overlay Network), 經過這個覆蓋網絡, 將數據包原封不動地傳遞到目標容器內.

Open vSwitch

Open vSwitch 能夠創建多鍾通訊隧道, 例如Open vswitch with GRE/VXALN. 在K8S 場景下, 咱們主要簡歷 L3 到 L3 的隧道. 網絡架構以下linux

image.png

須要完成的步驟以下:git

刪除docker daemon 建立的網橋 docker0 已避免 docker0地址衝突.github
手工建立一個linux網橋, 手動配置網橋的 IPdocker
創建 Open vswitch 網橋 ovs-bridge, 使用 ovs-vsctl 給ovs-bridge 添加gre端口, 在添加端口是, 須要將目標 NODE 的 IP 地址設置爲對端 IP 地址. 每一個對端 IP 地址都須要這麼操做.數據庫
將 ovs-bridge 做爲網絡接口, 加入docker 的網橋上(docker0 或本身手工建立的網橋)編程
重啓 ovs-bridge 網橋和 docker 的網橋, 並添加一個docker 的網段到docker 網橋的路由規則中segmentfault

網絡通訊過程

當容器內的應用訪問另外一個容器地址時, 數據包會經過容器內的默認路由發送給docker0網橋, ovs的網橋是做爲docker0 網橋的端口存在的, 它會將數據發送給ovs 網橋, ovs 經過gre隧道送達對端的node.api

配置步驟

在兩個節點都安裝ovs

安裝ovs

yum install openvswitch

禁用selinux 並重啓

#vi /etc/selinux/conifg
SELINUX=disabled

查看ovs狀態

systemctl status openvswtich

建立網橋和 gre 隧道

在每一個node上建立ovs 網橋 br0 而後在網橋上建立 gre 隧道

#建立ovs網橋
ovs-vsctl add-br br0
# 建立 GRE 隧道鏈接對端, remote_ip 爲對端 eth0 的 IP, 注意在另外一臺機器上設置對端的時候,IP 要改成當前這臺機器的 IP
ovs-vsctl add-port br0 gre1 -- set interface gre1 type gre option:remote_ip=192.168.18.128
# 添加br0 到本地 docker0 網橋, 使得容器流量經過 ovs 進入 tunnel
brctl addif docker0 br0
#啓動br0 docker0 網橋
ip link set dev br0 up
ip link set dev docker0 up

因爲128, 131 ip的兩臺機器docker0 網段分別是172.17.43.0/24, 172.17.42.0/24, 這兩個網段的路由都須要通過本機docker0網橋.其中一個24網段經過ovs的gre 隧道到達對端. 所以須要在每一個node上配置經過docker0 網橋的路由規則

ip route add 172.17.0.0/16 dev docker0

清空 docker 自帶的iptables 規則及linux 的規則, 後者存在拒絕ICMP 保溫經過防火牆的規則

iptables -t nat -F; iptalbes -F

直接路由

網絡模型

image.png

在默認狀況下docker0 的IP 在node 網絡是無法感知到的, 經過手工設置路由, 可讓pod 在不一樣node 之間互通.

實現方式

經過部署multilayer switch (MLS) 來實現

假設 POD1 所在的 docker0 網橋的 IP 網段是 10.1.10.0 , NODE1 地址爲 192. 168.1.128; 而 POD2 所在 docker0 ip 網段爲 10.1.20.0 NODE2 地址爲 192.168.1.129

1 在NODE 1 上添加一條到node2 上 docker0 的靜態路由規則

route add -net 10.1.20.0 netmask 255.255.255.0 gw 192.168.1.129

2 在 NODE 2 上添加一條到 NODE 1 上 docker0 的靜態路由規則

route add -net 10.1.10.0 netmask 255.255.255.0 gw 192.168.1.128

3 驗證連通性, 在 NODE1 上 ping node2 上的 docker0 網絡

ping 10.1.20.1

大規模集羣下的實現方式, 手工創建 linux bridge 已避免 docker daemon 創建docker0 形成 IP 段衝突, 而後使用docker 的--bridge 命令來指定網橋.

而後在每一個節點運行quagga 路由學習軟件.

calico

Calico 工做方式

Calico能夠建立並管理一個3層平面網絡，爲每一個工做負載分配一個徹底可路由的IP地址。工做負載能夠在沒有IP封裝或網絡地址轉換的狀況下進行通訊，以實現裸機性能，簡化故障排除和提供更好的互操做性。在須要使用overlay網絡的環境中，Calico提供了IP-in-IP隧道技術，或者也能夠與flannel等其餘overlay網絡配合使用。

Calico還提供網絡安全規則的動態配置。使用Calico的簡單策略語言，就能夠實現對容器、虛擬機工做負載和裸機主機各節點之間通訊的細粒度控制。

Calico v3.4於2018.12.10號發佈，可與Kubernetes、OpenShift和OpenStack良好地集成使用。

注意: 在Mesos, DC/OS和Docker orchestrators中使用Calico時，目前只支持到了 Calico v2.6.

uguo

Calico的IPIP與BGP模式

IPIP是一種將各Node的路由之間作一個tunnel，再把兩個網絡鏈接起來的模式。啓用IPIP模式時，Calico將在各Node上建立一個名爲」tunl0″的虛擬網絡接口。以下圖所示。
BGP模式則直接使用物理機做爲虛擬路由路（vRouter），再也不建立額外的tunnel

calico 在linux 內核中實現一個vRouter來負責數據轉發, 經過 BGP 協議,將node 節點上的路由信息在整個calico 網絡中廣播, 並自動設置到達其餘節點的路由轉發規則.

image.png

Calico BGP模式在小規模集羣中能夠直接互聯，在大規模集羣中能夠經過額外的BGP route reflector來完成。

image.png

Calico主要組件

Calico利用了Linux內核原生的路由和iptables防火牆功能。進出各個容器、虛擬機和物理主機的全部流量都會在路由到目標以前遍歷這些內核規則。

Felix：主要的Calico代理agent，運行每臺計算機上管理endpoints資源。
calicoctl：容許從命令行界面配置實現高級策略和網絡。
orchestrator plugins：提供與各類流行的雲計算編排工具的緊密集成和同步支持。
key/value store：存儲Calico的策略配置和網絡狀態信息，目前主要使用etcdv3或k8s api。
calico/node：在每一個主機上運行，從key/value存儲中讀取相關的策略和網絡配置信息，並在Linux內核中實現它。
Dikastes/Envoy：可選的Kubernetes sidecars，能夠經過相互TLS身份驗證保護工做負載到工做負載的通訊，並增長應用層控制策略。

Felix

Felix是一個守護程序，它在每一個提供endpoints資源的計算機上運行。在大多數狀況下，這意味着它須要在託管容器或VM的宿主機節點上運行。 Felix 負責編制路由和ACL規則以及在該主機上所需的任何其餘內容，以便爲該主機上的endpoints資源正常運行提供所需的網絡鏈接。

根據特定的編排環境，Felix負責如下任務：

管理網絡接口，Felix將有關接口的一些信息編程到內核中，以使內核可以正確處理該endpoint發出的流量。特別是，它將確保主機正確響應來自每一個工做負載的ARP請求，並將爲其管理的接口啓用IP轉發支持。它還監視網絡接口的出現和消失，以便確保針對這些接口的編程獲得了正確的應用。
編寫路由，Felix負責將到其主機上endpoints的路由編寫到Linux內核FIB（轉發信息庫）中。這能夠確保那些發往目標主機的endpoints的數據包被正確地轉發。
編寫ACLs，Felix還負責將ACLs編程到Linux內核中。這些ACLs用於確保只能在endpoints之間發送有效的網絡流量，並確保endpoints沒法繞過Calico的安全措施。
報告狀態，Felix負責提供有關網絡健康情況的數據。特別是，它將報告配置其主機時發生的錯誤和問題。該數據會被寫入etcd，以使其對網絡中的其餘組件和操做纔可見。

Orchestrator Plugin

每一個主要的雲編排平臺都有單獨的Calico網絡插件（例如OpenStack，Kubernetes）。這些插件的目的是將Calico更緊密地綁定到編排工具中，容許用戶管理Calico網絡，就像他們管理編排工具中內置的網絡工具同樣。

一個好的Orchestrator插件示例是Calico Neutron ML2 驅動程序。該插件與Neutron的ML2插件集成，容許用戶經過Neutron API調用來配置Calico網絡，實現了與Neutron的無縫集成。

Orchestrator插件負責如下任務：

API Translation，每一個雲編排工具都不可避免地擁有本身的一套用於管理網絡的API接口規範， Orchestrator插件的主要工做就是將這些API轉換爲Calico的數據模型，而後將其存儲在Calico的數據存儲區中。這種轉換中的一些工做將很是簡單，其餘一部分可能更復雜，以便將單個複雜操做（例如，實時遷移）轉換爲Calico網絡指望的一系列更簡單的操做。
Feedback，若有須要，orchestrator插件將從Calico網絡向編排器提供管理命令的反饋信息。包括提供有關Felix存活的信息，以及若是網絡配置失敗則將某些endpoints標記爲失敗。

etcd

etcd是一個分佈式鍵值存儲數據庫，專一於實現數據存儲一致性。 Calico使用etcd提供組件之間的數據通訊，並做爲能夠保證一致性的數據存儲，以確保Calico始終能夠構建出一個準確的網絡。

根據orchestrator插件的不一樣，etcd既能夠是做爲主數據存儲使用，也能夠是一個單獨數據存儲的輕量級鏡像。例如，在OpenStack部署中，OpenStack數據庫被認爲是「真實配置信息的來源」，而etcd用於鏡像其中有關網絡配置的信息，並用於服務其餘Calico組件。

etcd組件穿插在整個部署中。它能夠被分爲兩組主機節點：核心集羣和代理。

對於小型部署，核心集羣能夠是一個節點的etcd集羣（一般與orchestrator插件組件位於同一節點上）。這種部署模型很簡單但沒有爲etcd提供冗餘。在etcd失敗的狀況下，orchstrator插件必須重建數據庫，例如OpenStack，它須要插件從OpenStack數據庫從新同步狀態到etcd。

在較大的部署中，核心羣集能夠根據etcd管理指南進行擴展。

此外，在運行Felix或orchstrator插件的每臺計算機上，會運行一個etcd代理服務。這減小了etcd核心集羣上的負載，併爲主機節點屏蔽了etcd服務集羣的細節。在etcd集羣與orchstrator插件在同一臺機器上都有成員的狀況下，能夠放棄在該機器上使用etcd代理。

etcd負責執行如下任務：

Data Storage，etcd以分佈式、一致和容錯的方式存儲Calico網絡的數據（對於至少三個etcd節點的cluster大小）。這確保Calico網絡始終處於已知良好狀態，同時容許運行etcd的個別機器節點失敗或沒法訪問。Calico網絡數據的這種分佈式存儲提升了Calico組件從數據庫讀取的能力。
Communication，etcd也用做組件之間的通訊服務。咱們經過讓非etcd組件監視鍵值空間中的某些點來確保他們看到已經作出的任何更改，從而容許他們及時響應這些更改。該功能容許將狀態信息提交到數據庫，而後觸發基於該狀態數據的進一步網絡配置管理。

BGP Client (BIRD)

Calico在每一個運行Felix服務的節點上都部署一個BGP客戶端。 BGP客戶端的做用是讀取Felix程序編寫到內核中並在數據中心內分發的路由信息。

BGP客戶端負責執行如下任務：

路由信息分發，當Felix將路由插入Linux內核FIB時，BGP客戶端將接收它們並將它們分發到集羣中的其餘工做節點。

BGP Route Reflector (BIRD)

對於較大規模的部署，簡單的BGP可能成爲限制因素，由於它要求每一個BGP客戶端鏈接到網狀拓撲中的每個其餘BGP客戶端。這須要愈來愈多的鏈接，迅速變得難以維護，甚至會讓一些設備的路由表撐滿。

所以，在較大規模的部署中，Calico建議部署BGP Route Reflector。一般是在Internet中使用這樣的組件充當BGP客戶端鏈接的中心點，從而防止它們須要與羣集中的每一個BGP客戶端進行通訊。爲了實現冗餘，也能夠同時部署多個BGP Route Reflector服務。Route Reflector僅僅是協助管理BGP網絡，並無endpoint數據會經過它們。

在Calico中，此BGP組件也是使用的最多見的BIRD，配置爲Route Reflector運行，而不是標準BGP客戶端。

BGP Route Reflector負責如下任務：

集中式的路由信息分發，當Calico BGP客戶端將路由從其FIB通告到Route Reflector時，Route Reflector會將這些路由通告給部署集羣中的其餘節點。

BIRD是什麼

BIRD是布拉格查理大學數學與物理學院的一個學校項目，項目名是BIRD Internet Routing Daemon的縮寫。目前，它由CZ.NIC實驗室開發和支持。

BIRD項目旨在開發一個功能齊全的動態IP路由守護進程，主要針對（但不限於）Linux，FreeBSD和其餘類UNIX系統，並在GNU通用公共許可證下分發。詳細信息參照官網https://bird.network.cz/。

做爲一個開源的網絡路由守護進程項目，BRID設計並支持瞭如下功能：

both IPv4 and IPv6 protocols
multiple routing tables
the Border Gateway Protocol (BGPv4)
the Routing Information Protocol (RIPv2, RIPng)
the Open Shortest Path First protocol (OSPFv2, OSPFv3)
the Babel Routing Protocol
the Router Advertisements for IPv6 hosts
a virtual protocol for exchange of routes between different routing tables on a single host
a command-line interface allowing on-line control and inspection of status of the daemon
soft reconfiguration (no need to use complex online commands to change the configuration, just edit the configuration file and notify BIRD to re-read it and it will smoothly switch itself to the new configuration, not disturbing routing protocols unless they are affected by the configuration changes)
a powerful language for route filtering

K8S 中部署 calico

修改kube-api server 啓動參數

--allow-priviledge=true (calico 須要特權模式)

修改kubelet 啓動參數 --network-plugin=cni

假設K8S 環境包含兩個node節點 node1 (192,168.18.3) , node2 (192.168.18.4)

建立calico 服務, 主要包括calico-node 和 calico policy controller, 須要的K8S 資源對象以下

configmap: calico-config 包含calico的配置參數
secret: calico-etcd-secrets 用於TLS 鏈接etcd
在每一個節點以daemonset的形式部署calico/node 容器
在每一個節點都安裝calico cni 二進制文件和網絡配置參數(由install-cni 容器完成)
部署一個名爲calico/kube-policy-controller的deployment, 爲K8S 集羣中的POD 設置network policy

官方 calico k8s 安裝 yaml 文件以下

calico-etcd.yaml

---
# Source: calico/templates/calico-etcd-secrets.yaml
# The following contains k8s Secrets for use with a TLS enabled etcd cluster.
# For information on populating Secrets, see http://kubernetes.io/docs/user-guide/secrets/
apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: calico-etcd-secrets
  namespace: kube-system
data:
  # Populate the following with etcd TLS configuration if desired, but leave blank if
  # not using TLS for etcd.
  # The keys below should be uncommented and the values populated with the base64
  # encoded contents of each file that would be associated with the TLS data.
  # Example command for encoding a file contents: cat <file> | base64 -w 0
  # etcd-key: null
  # etcd-cert: null
  # etcd-ca: null
---
# Source: calico/templates/calico-config.yaml
# This ConfigMap is used to configure a self-hosted Calico installation.
kind: ConfigMap
apiVersion: v1
metadata:
  name: calico-config
  namespace: kube-system
data:
  # Configure this with the location of your etcd cluster.
  #ETCD的服務地址
  etcd_endpoints: "http://<ETCD_IP>:<ETCD_PORT>"
  # If you're using TLS enabled etcd uncomment the following.
  # You must also populate the Secret below with these files.
  etcd_ca: ""   # "/calico-secrets/etcd-ca"
  etcd_cert: "" # "/calico-secrets/etcd-cert"
  etcd_key: ""  # "/calico-secrets/etcd-key"
  # Typha is disabled.
  typha_service_name: "none"
  # Configure the backend to use.
  calico_backend: "bird"

  # Configure the MTU to use
  veth_mtu: "1440"

  # The CNI network configuration to install on each node.  The special
  # values in this config will be automatically populated.
  cni_network_config: |-
    {
      "name": "k8s-pod-network",
      "cniVersion": "0.3.1",
      "plugins": [
        {
          "type": "calico",
          "log_level": "info",
          "etcd_endpoints": "__ETCD_ENDPOINTS__",
          "etcd_key_file": "__ETCD_KEY_FILE__",
          "etcd_cert_file": "__ETCD_CERT_FILE__",
          "etcd_ca_cert_file": "__ETCD_CA_CERT_FILE__",
          "mtu": __CNI_MTU__,
          "ipam": {
              "type": "calico-ipam"
          },
          "policy": {
              "type": "k8s"
          },
          "kubernetes": {
              "kubeconfig": "__KUBECONFIG_FILEPATH__"
          }
        },
        {
          "type": "portmap",
          "snat": true,
          "capabilities": {"portMappings": true}
        }
      ]
    }

---
# Source: calico/templates/rbac.yaml

# Include a clusterrole for the kube-controllers component,
# and bind it to the calico-kube-controllers serviceaccount.
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: calico-kube-controllers
rules:
  # Pods are monitored for changing labels.
  # The node controller monitors Kubernetes nodes.
  # Namespace and serviceaccount labels are used for policy.
  - apiGroups: [""]
    resources:
      - pods
      - nodes
      - namespaces
      - serviceaccounts
    verbs:
      - watch
      - list
  # Watch for changes to Kubernetes NetworkPolicies.
  - apiGroups: ["networking.k8s.io"]
    resources:
      - networkpolicies
    verbs:
      - watch
      - list
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: calico-kube-controllers
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: calico-kube-controllers
subjects:
- kind: ServiceAccount
  name: calico-kube-controllers
  namespace: kube-system
---
# Include a clusterrole for the calico-node DaemonSet,
# and bind it to the calico-node serviceaccount.
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: calico-node
rules:
  # The CNI plugin needs to get pods, nodes, and namespaces.
  - apiGroups: [""]
    resources:
      - pods
      - nodes
      - namespaces
    verbs:
      - get
  - apiGroups: [""]
    resources:
      - endpoints
      - services
    verbs:
      # Used to discover service IPs for advertisement.
      - watch
      - list
  - apiGroups: [""]
    resources:
      - nodes/status
    verbs:
      # Needed for clearing NodeNetworkUnavailable flag.
      - patch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: calico-node
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: calico-node
subjects:
- kind: ServiceAccount
  name: calico-node
  namespace: kube-system

---
# Source: calico/templates/calico-node.yaml
# This manifest installs the calico-node container, as well
# as the CNI plugins and network config on
# each master and worker node in a Kubernetes cluster.
kind: DaemonSet
apiVersion: apps/v1
metadata:
  name: calico-node
  namespace: kube-system
  labels:
    k8s-app: calico-node
spec:
  selector:
    matchLabels:
      k8s-app: calico-node
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
  template:
    metadata:
      labels:
        k8s-app: calico-node
      annotations:
        # This, along with the CriticalAddonsOnly toleration below,
        # marks the pod as a critical add-on, ensuring it gets
        # priority scheduling and that its resources are reserved
        # if it ever gets evicted.
        scheduler.alpha.kubernetes.io/critical-pod: ''
    spec:
      nodeSelector:
        beta.kubernetes.io/os: linux
      hostNetwork: true
      tolerations:
        # Make sure calico-node gets scheduled on all nodes.
        - effect: NoSchedule
          operator: Exists
        # Mark the pod as a critical add-on for rescheduling.
        - key: CriticalAddonsOnly
          operator: Exists
        - effect: NoExecute
          operator: Exists
      serviceAccountName: calico-node
      # Minimize downtime during a rolling upgrade or deletion; tell Kubernetes to do a "force
      # deletion": https://kubernetes.io/docs/concepts/workloads/pods/pod/#termination-of-pods.
      terminationGracePeriodSeconds: 0
      priorityClassName: system-node-critical
      initContainers:
        # This container installs the CNI binaries
        # and CNI network config file on each node.
        - name: install-cni
          image: calico/cni:v3.8.0
          command: ["/install-cni.sh"]
          env:
            # Name of the CNI config file to create.
            - name: CNI_CONF_NAME
              value: "10-calico.conflist"
            # The CNI network config to install on each node.
            - name: CNI_NETWORK_CONFIG
              valueFrom:
                configMapKeyRef:
                  name: calico-config
                  key: cni_network_config
            # The location of the etcd cluster.
            - name: ETCD_ENDPOINTS
              valueFrom:
                configMapKeyRef:
                  name: calico-config
                  key: etcd_endpoints
            # CNI MTU Config variable
            - name: CNI_MTU
              valueFrom:
                configMapKeyRef:
                  name: calico-config
                  key: veth_mtu
            # Prevents the container from sleeping forever.
            - name: SLEEP
              value: "false"
          volumeMounts:
            - mountPath: /host/opt/cni/bin
              name: cni-bin-dir
            - mountPath: /host/etc/cni/net.d
              name: cni-net-dir
            - mountPath: /calico-secrets
              name: etcd-certs
        # Adds a Flex Volume Driver that creates a per-pod Unix Domain Socket to allow Dikastes
        # to communicate with Felix over the Policy Sync API.
        - name: flexvol-driver
          image: calico/pod2daemon-flexvol:v3.8.0
          volumeMounts:
          - name: flexvol-driver-host
            mountPath: /host/driver
      containers:
        # Runs calico-node container on each Kubernetes node.  This
        # container programs network policy and routes on each
        # host.
        - name: calico-node
          image: calico/node:v3.8.0
          env:
            # The location of the etcd cluster.
            - name: ETCD_ENDPOINTS
              valueFrom:
                configMapKeyRef:
                  name: calico-config
                  key: etcd_endpoints
            # Location of the CA certificate for etcd.
            - name: ETCD_CA_CERT_FILE
              valueFrom:
                configMapKeyRef:
                  name: calico-config
                  key: etcd_ca
            # Location of the client key for etcd.
            - name: ETCD_KEY_FILE
              valueFrom:
                configMapKeyRef:
                  name: calico-config
                  key: etcd_key
            # Location of the client certificate for etcd.
            - name: ETCD_CERT_FILE
              valueFrom:
                configMapKeyRef:
                  name: calico-config
                  key: etcd_cert
            # Set noderef for node controller.
            - name: CALICO_K8S_NODE_REF
              valueFrom:
                fieldRef:
                  fieldPath: spec.nodeName
            # Choose the backend to use.
            - name: CALICO_NETWORKING_BACKEND
              valueFrom:
                configMapKeyRef:
                  name: calico-config
                  key: calico_backend
            # Cluster type to identify the deployment type
            - name: CLUSTER_TYPE
              value: "k8s,bgp"
            # Auto-detect the BGP IP address.
            - name: IP
              value: "autodetect"
            # Enable IPIP
            - name: CALICO_IPV4POOL_IPIP
              value: "Always"
            # Set MTU for tunnel device used if ipip is enabled
            - name: FELIX_IPINIPMTU
              valueFrom:
                configMapKeyRef:
                  name: calico-config
                  key: veth_mtu
            # The default IPv4 pool to create on startup if none exists. Pod IPs will be
            # chosen from this range. Changing this value after installation will have
            # no effect. This should fall within `--cluster-cidr`.
            - name: CALICO_IPV4POOL_CIDR
              value: "192.168.0.0/16"
            # Disable file logging so `kubectl logs` works.
            - name: CALICO_DISABLE_FILE_LOGGING
              value: "true"
            # Set Felix endpoint to host default action to ACCEPT.
            - name: FELIX_DEFAULTENDPOINTTOHOSTACTION
              value: "ACCEPT"
            # Disable IPv6 on Kubernetes.
            - name: FELIX_IPV6SUPPORT
              value: "false"
            # Set Felix logging to "info"
            - name: FELIX_LOGSEVERITYSCREEN
              value: "info"
            - name: FELIX_HEALTHENABLED
              value: "true"
          securityContext:
            privileged: true
          resources:
            requests:
              cpu: 250m
          livenessProbe:
            httpGet:
              path: /liveness
              port: 9099
              host: localhost
            periodSeconds: 10
            initialDelaySeconds: 10
            failureThreshold: 6
          readinessProbe:
            exec:
              command:
              - /bin/calico-node
              - -bird-ready
              - -felix-ready
            periodSeconds: 10
          volumeMounts:
            - mountPath: /lib/modules
              name: lib-modules
              readOnly: true
            - mountPath: /run/xtables.lock
              name: xtables-lock
              readOnly: false
            - mountPath: /var/run/calico
              name: var-run-calico
              readOnly: false
            - mountPath: /var/lib/calico
              name: var-lib-calico
              readOnly: false
            - mountPath: /calico-secrets
              name: etcd-certs
            - name: policysync
              mountPath: /var/run/nodeagent
      volumes:
        # Used by calico-node.
        - name: lib-modules
          hostPath:
            path: /lib/modules
        - name: var-run-calico
          hostPath:
            path: /var/run/calico
        - name: var-lib-calico
          hostPath:
            path: /var/lib/calico
        - name: xtables-lock
          hostPath:
            path: /run/xtables.lock
            type: FileOrCreate
        # Used to install CNI.
        - name: cni-bin-dir
          hostPath:
            path: /opt/cni/bin
        - name: cni-net-dir
          hostPath:
            path: /etc/cni/net.d
        # Mount in the etcd TLS secrets with mode 400.
        # See https://kubernetes.io/docs/concepts/configuration/secret/
        - name: etcd-certs
          secret:
            secretName: calico-etcd-secrets
            defaultMode: 0400
        # Used to create per-pod Unix Domain Sockets
        - name: policysync
          hostPath:
            type: DirectoryOrCreate
            path: /var/run/nodeagent
        # Used to install Flex Volume Driver
        - name: flexvol-driver-host
          hostPath:
            type: DirectoryOrCreate
            path: /usr/libexec/kubernetes/kubelet-plugins/volume/exec/nodeagent~uds
---

apiVersion: v1
kind: ServiceAccount
metadata:
  name: calico-node
  namespace: kube-system

---
# Source: calico/templates/calico-kube-controllers.yaml

# See https://github.com/projectcalico/kube-controllers
apiVersion: apps/v1
kind: Deployment
metadata:
  name: calico-kube-controllers
  namespace: kube-system
  labels:
    k8s-app: calico-kube-controllers
spec:
  # The controllers can only have a single active instance.
  replicas: 1
  selector:
    matchLabels:
      k8s-app: calico-kube-controllers
  strategy:
    type: Recreate
  template:
    metadata:
      name: calico-kube-controllers
      namespace: kube-system
      labels:
        k8s-app: calico-kube-controllers
      annotations:
        scheduler.alpha.kubernetes.io/critical-pod: ''
    spec:
      nodeSelector:
        beta.kubernetes.io/os: linux
      tolerations:
        # Mark the pod as a critical add-on for rescheduling.
        - key: CriticalAddonsOnly
          operator: Exists
        - key: node-role.kubernetes.io/master
          effect: NoSchedule
      serviceAccountName: calico-kube-controllers
      priorityClassName: system-cluster-critical
      # The controllers must run in the host network namespace so that
      # it isn't governed by policy that would prevent it from working.
      hostNetwork: true
      containers:
        - name: calico-kube-controllers
          image: calico/kube-controllers:v3.8.0
          env:
            # The location of the etcd cluster.
            - name: ETCD_ENDPOINTS
              valueFrom:
                configMapKeyRef:
                  name: calico-config
                  key: etcd_endpoints
            # Location of the CA certificate for etcd.
            - name: ETCD_CA_CERT_FILE
              valueFrom:
                configMapKeyRef:
                  name: calico-config
                  key: etcd_ca
            # Location of the client key for etcd.
            - name: ETCD_KEY_FILE
              valueFrom:
                configMapKeyRef:
                  name: calico-config
                  key: etcd_key
            # Location of the client certificate for etcd.
            - name: ETCD_CERT_FILE
              valueFrom:
                configMapKeyRef:
                  name: calico-config
                  key: etcd_cert
            # Choose which controllers to run.
            - name: ENABLED_CONTROLLERS
              value: policy,namespace,serviceaccount,workloadendpoint,node
          volumeMounts:
            # Mount in the etcd TLS secrets.
            - mountPath: /calico-secrets
              name: etcd-certs
          readinessProbe:
            exec:
              command:
              - /usr/bin/check-status
              - -r
      volumes:
        # Mount in the etcd TLS secrets with mode 400.
        # See https://kubernetes.io/docs/concepts/configuration/secret/
        - name: etcd-certs
          secret:
            secretName: calico-etcd-secrets
            defaultMode: 0400

---

apiVersion: v1
kind: ServiceAccount
metadata:
  name: calico-kube-controllers
  namespace: kube-system
---
# Source: calico/templates/calico-typha.yaml

---
# Source: calico/templates/configure-canal.yaml

---
# Source: calico/templates/kdd-crds.yaml

kubectl apply -f calico-etcd.yaml

注意修改參數

做者：陳sir的知識圖譜
連接：https://www.jianshu.com/p/99ecbe793f92
來源：簡書
著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。

咱們知道，在k8s裏面最小的管理單元是pod，一個主機能夠跑多個pod，一個pod裏面能夠跑多個容器。

如上面所示，一個pod裏面全部的容器共享一個網絡命名空間(network namespace)，因此，pod裏面的容器之間通訊，能夠直接經過localhost來完成，pod裏面的容器之間經過localhost+端口的方式來通訊（這和應用程序在宿主機的通訊方式是同樣的）。

那麼pod和pod之間的通訊呢？一般來講，咱們給應用程序定死端口會給應用程序水平擴展帶來不少不便，因此k8s不會使用定死端口這樣的方法，而是採用其餘方法來解決pod之間尋址的問題

每一個pod都會有一個本身的ip，能夠將Pod像VM或物理主機同樣對待。這樣pod和pod之間的通訊就不須要像容器同樣，經過內外端口映射來通訊了，這樣就避免了端口衝突的問題。

特殊的狀況下（好比運維作網絡檢測或者程序調試），能夠在pod所在的宿主機想向pod的ip+端口發起請求，這些請求會轉發到pod的端口，可是pod自己它本身是不知道端口的存在的。

所以，k8s的網絡遵循如下原則：

一個節點的pod和其餘節點的pod通訊不須要經過作網絡地址轉換（NAT）
一個節點上全部的agent控制程序（如deamon和kubelet）能夠和這個節點上的pod通訊
節點主機網絡中的Pod能夠與其餘全部節點上的全部Pod通訊，而無需NAT

把上面這個pod替換成容器也是成立的，由於pod裏面的容器和pod共享網絡。

基本上的原則就是，k8s的裏面的pod能夠自由的和集羣裏面的任何其餘pod通訊（即便他們是部署在不一樣的宿主機），並且pod直接的通訊是直接使用pod本身的ip來通訊，他們不知道宿主機的ip，因此，對於pod之間來講，宿主機的網絡信息是透明的，好像不存在同樣。

而後，定了這幾個原則以後，具體的實現k8s的這個網絡模型有好多種實現，咱們這裏介紹的是Flannel，是其中最簡單的一種實現。

Flannel實現pod之間的通訊，是經過一種覆蓋網絡（overlay network），把數據包封裝在另一個網絡來作轉發，這個覆蓋網絡能夠給每個pod分配一個獨立的ip地址，使他們看起來都是一臺具備獨立ip的物理主機同樣。

下面這個就是k8s用覆蓋網絡來實現的一個例子：

flannel覆蓋網絡

能夠看到有3個node，在多個node上創建一個覆蓋網絡，子網網段是100.95.0.0/16,而後，最終到容器級別，每一個容器在這個網段裏面獲取到一個獨立的ip。而宿主機所在的局域網絡的網段是172.20.32.0/19

看這兩個網段，就知道，fannel給這個集羣建立了一個更大的網絡給pod使用，能夠容納的主機數量達到65535（2^16）個。

對於每一個宿主機，fannel給每一個了一個小一點的網絡100.96.x.0/24，提供給每一個這個宿主機的每個pod使用，也就是說，每個宿主機能夠有256(2^8)個pod。docker默認的網橋docker0用的就是這個網絡，也就是全部的docker經過docker0來使用這個網絡。即便說，對於容器來講，都是經過docker0這個橋來通訊，和咱們日常單機的容器是同樣的（若是你不給建立的容器指定網絡的話，默認用的是docker0，參考我之前寫的關於docker bridge的文章）

那麼，對於同一個host裏面的容器通訊，咱們上面說了是經過這個臺宿主機的裏面的docker0這個網橋來通訊。那對於跨宿主機，也便是兩個宿主機之間的容器是怎麼通訊的呢？fannel使用了宿主機操做系統的kernel route和UDP（這是其中一種實現）包封裝來完成。下圖演示了這個通訊過程：

fannel網絡中跨宿主機的容器通訊

如圖所示，100.96.1.2(container-1) 要和100.96.2.3(container-2)通訊，兩個容器分別處於不一樣的宿主機。
假設有一個包是從100.96.1.2發出去給100.96.2.3，它會先通過docker0，由於docker0這個橋是全部容器的網關。而後這個包會通過route table處理，轉發出去到局域網172.20.32.0/19. 而這個route table的對應處理這類包的規則又是從哪裏來的呢？它們是由fannel的一個守護程序flanneld建立的。

每一臺宿主機都會跑一個flannel的deamon的進程，這個進程的程序會往宿主機的route table裏面寫入特定的路由規則，這個規則大概是這樣的。

Node1的route table

admin@ip-172-20-33-102:~$ ip route
default via 172.20.32.1 dev eth0
100.96.0.0/16 dev flannel0  proto kernel  scope link  src 100.96.1.0
100.96.1.0/24 dev docker0  proto kernel  scope link  src 100.96.1.1
172.20.32.0/19 dev eth0  proto kernel  scope link  src 172.20.33.102

圖例的數據包發出去的目標地址是100.96.2.3,它屬於網段100.96.0.0/16,這個目標地址命中第二條規則，也就是這個包會發到flannel0這個設備（dev），這flannel0是一個TUN設備。是在內核裏面的一個虛擬網絡設備（虛擬網卡）。

在內核（kernel）裏面，有兩種虛擬網卡設備，分別是TUN和TAP,其中TAP處理的是第二層（數據鏈路層）的幀，而TUN處理的是第三層（網絡層）的ip包。

應用程序能夠綁定到TUN和TAP設備，內核會把數據經過TUN或者TAP設備發送給這些程序，反過來，應用程序也能夠經過TUN和TAP向內核寫入數據，進而由內核的路由處理這些發出去的數據包。

那麼上面這個flannel0就是一個這樣的TUN設備。這個設備連到的是一個flannel的守護進程程序flanneld

而這個flanneld是幹嗎的呢？它能夠接受全部發往flannel0這個設備的數據包，而後作數據封裝處理，它的封裝的邏輯也很簡單，就是根據目標地址，找到這個這地址對應的在整個flannel網絡裏面對應物理ip和端口（這裏是Node2對應的物理ip），而後增長一個包頭，增長的包頭裏面目標地址爲這個實際的物理ip和端口（固然源地址也改爲了局域網絡的ip），將原來的數據包嵌入在新的數據包中，而後再把這個封裝後的包扔回去給內核，內核根據目標地址去路由規則匹配規則，發現目標地址ip是172.20.54.98,端口是8285. 根據ip匹配不到任何特定的規則，就用第一條default（默認）的規則，經過eth0這個物理網卡，把數據包發給局域網（這裏是UDP廣播出去）

當Node2的收到這個包後，而後根據端口8285發現他的目標地址原來是發給flanneld的，而後就直接交給flanneld這程序，flanneld收到包後，把包頭去掉，發現原來目標地址是100.96.2.3，而後就交換flannel0，flannel0把這個解開後的原包交給內核，內核發現它的目標地址是100.96.2.3，應該交給docker0來處理。（圖例裏面畫的是直接由flannel0交給docker0，沒有圖示出內核，實際上flannel0是一個TUN設備，是跑在內核的，數據通過它後能夠交給內核，由內核根據路由決定進一步怎麼forward）

以上就是這個通訊的過程，那麼這裏有一個問題： flanneld是怎麼知道100.96.2.3對應的目標地址是172.20.54.98:8285的呢？

這是由於flanneld維護了一個映射關係，它沒創造一個虛擬的容器ip（分配給容器新ip的時候），它就知道這個容器的ip其實是在哪臺宿主機上，而後把這個映射關係存儲起來，在k8s裏面flanneld存儲的這個映射關係放在etd上，這就是爲何flanneld爲何知道這個怎麼去封裝這些包了，下面就是etcd裏面的數據的：

admin@ip-172-20-33-102:~$ etcdctl ls /coreos.com/network/subnets
/coreos.com/network/subnets/100.96.1.0-24
/coreos.com/network/subnets/100.96.2.0-24
/coreos.com/network/subnets/100.96.3.0-24
admin@ip-172-20-33-102:~$ etcdctl get /coreos.com/network/subnets/100.96.2.0-24
{"PublicIP":"172.20.54.98"}

看上面這個數據，etcd裏面存儲的100.96.2.0-24這個網段的容器是放在172.20.54.98這臺宿主機上的。

那麼還有一個問題，端口8285又是怎麼知道的?

這個很簡單，flanneld的默認監聽的端口就是這個8285端口，flanneld啓動的時候，就監聽了UDP端口8285. 因此發給Node2：8285的全部UDP數據包會，flanneld這個進程會直接處理，如何去掉包頭就還原出來原來的包了，還原後交給TUN設備flannel0,由flannel0交給內核，內核根據Node2的路由規則交給docker0（Node2的路由規則和node1是基本上同樣的，除了第三位的網段標識不同，一個是100.96.1一個是100.92.2）：

admin@ip-172-20-54-98:~$ ip route
default via 172.20.32.1 dev eth0
100.96.0.0/16 dev flannel0  proto kernel  scope link  src 100.96.2.0
100.96.2.0/24 dev docker0  proto kernel  scope link  src 100.96.2.1
172.20.32.0/19 dev eth0  proto kernel  scope link  src 172.20.54.98

看Node2的這個規則，flannld去掉包頭解出來的原包的目標ip是100.96.2.3,由flannel0交回去給kennel，kennel發現命中第三條規則，因此會把這個包叫給docker0,繼而就進入了docker0這個橋的子網了，接下去就是docker的事情了，參考之前寫的文章。

最後一個問題，怎麼配置docker去使用100.96.x.0/24這個子網呢，若是是手工建立容器的話，這個也是很是簡單的，參考之前寫的關於docker bridge的這篇文章，可是在k8s裏面，是經過配置來實現的：

flanneld會把子網信息寫到一個配置文件/run/flannel/subnet.env裏

admin@ip-172-20-33-102:~$ cat /run/flannel/subnet.env
FLANNEL_NETWORK=100.96.0.0/16
FLANNEL_SUBNET=100.96.1.1/24
FLANNEL_MTU=8973
FLANNEL_IPMASQ=true

docker會使用這個配置的環境變了來做爲它的bridge的配置

dockerd --bip=$FLANNEL_SUBNET --mtu=$FLANNEL_MTU

以上，就是k8s如何使用flannel網絡來跨機器通訊的原理，整體來說，因爲flanneld這個守護神幹了全部的髒活累活（其實已是k8s的網絡實現裏面最簡單的一種了），使得pod和容器可以鏈接另一個pod或者容器變得很是簡單，就像連一個大局域網裏面任意以太主機同樣，他們只須要知道對方的虛擬ip就能夠直接通訊了，不須要作
NAT等複雜的規則處理。

那麼性能怎麼樣？

新版本的flannel不推薦在生產環境使用UDP的包封裝這種實現。只用它來作測試和調試用，由於它的性能表現和其餘的實現比差一些。

flannel0 利用的TUN設備作包封裝原理

看上面這個圖解，一個upd包須要來回在用戶空間(user space)和內核空間(kennel space)複製3次，這會大大增長網絡開銷。

官方的文檔裏面能夠看到其餘的包轉發實現方式，能夠進一步閱讀,其中host-gw的性能比較好，它是在第二層去作數據包處理。