ansible-role-flanneld

このAnsibleプレイブックは、Ansibleを使ったKubernetesの簡易手法 - Workerで使用されます。flanneldバイナリをインストールし、設定します。Flannelは、クラスター内の複数のノード間でレイヤー3のIPv4ネットワークを提供します。Flannelは、コンテナがホストとどのようにネットワーク接続されるかを制御せず、ホスト間のトラフィックがどのように輸送されるかのみを管理します。しかし、FlannelはKubernetes用のCNIプラグインを提供し、Dockerとの統合に関するガイダンスも行っています。

バージョン

すべてのリリースにタグを付けており、セマンティックバージョニングを維持するようにしています。このロールを使用する場合は、最新のタグを確認することをお勧めします。マスターブランチは開発状態にあり、タグは安定したリリースを示します。一般的に、マスターブランチも良好な状態を保つようにしています。タグ8.0.0+0.16.1は、このロールのバージョン8.0.0で、Flannelバージョン0.16.1と一緒に使用されることを意図しています（新しいバージョンでも動作するかもしれません）。ロール自体が変更された場合、X.Y.Zの部分が+の前に増加します。Flannelのバージョンが変更されると、X.Y.Zの部分が+の後に増加します。これにより、バグ修正や新しいメジャーバージョンにタグを付けることができ、特定のFlannelリリースのためにまだ開発が行われている間も対応できます。

要件

• etcdクラスターが稼働している必要があります（ansible-role-etcdを参照）。このロールは、Ansibleのk8s_etcdグループ内で見つかった最初のノードに接続し、etcdctlを実行してetcdに新しいエントリを追加します。そのエントリにはFlannelネットワークの設定が含まれ、"flannel_etcd_prefix/config"にあります。
• CNIプラグイン（ansible-role-cniを参照）

変更履歴

CHANGELOG.mdを参照

ロールの変数

# K8sサービスがリッスンするインターフェース。すべてのクラスター
# 通信はVPNインターフェースを使用するため、インターフェース名は
# 通常"wg0"、"tap0"、または"peervpn0"です。
k8s_interface: "tap0"
# KubernetesホストにK8s証明書やその他の設定が保存される
# ディレクトリ。
k8s_conf_dir: "/var/lib/kubernetes"
# CNIネットワークプラグインディレクトリ
k8s_cni_conf_dir: "/etc/cni/net.d"
# K8s証明書をコピーするディレクトリ。デフォルトでは
# ユーザーのローカル$HOMEに展開されます（"ansible-playbook ..."を
# 実行するユーザー）にプラス"/k8s/certs"。これは、ユーザーの$HOMEディレクトリが例えば
# "/home/da_user"の場合、"k8s_ca_conf_directory"は
# "/home/da_user/k8s/certs"の値を持つことを意味します。
k8s_ca_conf_directory: "{{ '~/k8s/certs' | expanduser }}"

etcd_bin_dir: "/usr/local/bin"
etcd_client_port: 2379
etcd_certificates:
  - ca-etcd.pem
  - ca-etcd-key.pem
  - cert-etcd.pem
  - cert-etcd-key.pem

flannel_version: "v0.16.1"
flannel_etcd_prefix: "/kubernetes-cluster/network"
flannel_ip_range: "10.200.0.0/16"
flannel_backend_type: "vxlan"
flannel_cni_interface: "cni0"
flannel_subnet_file_dir: "/run/flannel"
flannel_options_dir: "/etc/flannel"
flannel_bin_dir: "/usr/local/sbin"
flannel_cni_conf_file: "10-flannel"
flannel_cni_spec_version: "0.3.1"

flannel_systemd_restartsec: "5"
flannel_systemd_limitnofile: "40000"
flannel_systemd_limitnproc: "1048576"
# Flannelのsystemdサービスファイル内の"ExecStartPre"ディレクティブ。このコマンドは
# Flannelサービスが開始する前に実行されます。
flannel_systemd_execstartpre: "/bin/mkdir -p {{flannel_subnet_file_dir}}"
# Flannelのsystemdサービスファイル内の"ExecStartPost"ディレクティブ。このコマンドは
# Flannelサービスが開始した後に実行されます。Hetznerクラウドで実行している場合
# これが重要になることがあります。この場合、「flannel.1」インターフェースのTXチェックサムオフロード
# パラメーターを変更します。Flannel vxlanカプセル化内（すべてUDP内）
# のカーネル/ドライバのチェックサムオフロードバグがあるようです。
# flannel_systemd_execstartpost: "/sbin/ethtool -K flannel.1 tx off"

flannel_settings:
  "etcd-cafile": "{{k8s_conf_dir}}/ca-etcd.pem"
  "etcd-certfile": "{{k8s_conf_dir}}/cert-etcd.pem"
  "etcd-keyfile": "{{k8s_conf_dir}}/cert-etcd-key.pem"
  "etcd-prefix": "{{flannel_etcd_prefix}}"
  "iface": "{{k8s_interface}}"
  "public-ip": "{{hostvars[inventory_hostname]['ansible_' + k8s_interface].ipv4.address}}"
  "subnet-file": "{{flannel_subnet_file_dir}}/subnet.env"
  "ip-masq": "true"
  "healthz-ip": "0.0.0.0"
  "healthz-port": "0" # 0 = 無効化

flannel_cni_conf: |
  {
    "name": "{{flannel_cni_interface}}",
    "cniVersion": "{{flannel_cni_spec_version}}",
    "plugins": [
      {
        "type": "flannel",
        "delegate": {
          "hairpinMode": true,
          "isDefaultGateway": true
        }
      },
      {
        "type": "portmap",
        "capabilities": {
          "portMappings": true
        }
      }
    ]
  }

flannel_settingsで定義されるFlannelデーモンの設定は、flannel_settings_userという変数を定義することで上書きできます。また、この変数を使用して追加の設定を追加することもできます。例えば、healthz-ipのデフォルト値を上書きし、kubeconfig-file設定を追加するには、group_vars/all.ymlまたは適切な場所に次の設定を追加します：

flannel_settings_user:
  "healthz-ip": "1.2.3.4"
  "kubeconfig-file": "/etc/k8s/k8s.cfg"

デフォルトではコメントアウトされているflannel_systemd_execstartpost: "/sbin/ethtool -K flannel.1 tx off"について。PodからPodへの通信が機能しているが（ホスト間）、PodからServiceまたはNodeからServiceへの通信が機能しない場合（これもホスト間で）、この変数と内容を設定することで役立つかもしれません。少なくともHetznerクラウドでのWireGuard VPN経由のFlannelトラフィックの実行に役立ちました。この場合、TXオフロードが機能せず、これがチェックサムエラーを引き起こしています。この問題を特定する方法は次の通りです。SSHを介して2つのワーカーノードにログインします。例えばworker01で実行中のサービスを特定し、worker02でアクセスを試みます。例えば、kube-dnsやcorednsポッドは、基本的にすべてのKubernetesクラスターで実行されるため、良い候補です。通常、DNSクエリはUDPプロトコルを介して送信されますが、DNSはTCPでも機能します。したがって、kube-dnsがworker01で実行されていると仮定し、worker02でDNSサービスに接続しようとします。

telnet 10.32.0.254 53
Trying 10.32.0.254...

しかし、何も起こりません。そこで、worker01でtcpdumpを実行します。例えば、tcpdump -nnvvvS -i any src host <ip_of_worker02>。これで、worker02からworker01へのすべてのトラフィックをキャプチャします。再度、worker02でtelnet 10.32.0.254 53を実行すると、以下のような出力が得られるかもしれません：

22:17:18.500515 IP (tos 0x0, ttl 64, id 32604, offset 0, flags [none], proto UDP (17), length 110)
    10.8.0.112.43977 > 10.8.0.111.8472: [udp sum ok] OTV, flags [I] (0x08), overlay 0, instance 1
IP (tos 0x10, ttl 63, id 10853, offset 0, flags [DF], proto TCP (6), length 60)
    10.200.94.0.40912 > 10.200.1.37.53: Flags [S], cksum 0x74e3 (incorrect -> 0x890f), seq 3891002740, win 43690, options [mss 65495,sackOK,TS val 2436992709 ecr 0,nop,wscale 7], length 0
...

最後の行を詳しく見ると、例えばcksum 0x74e3 (incorrect -> 0x890f)のようになっており、これが問題です。SYNパケットはチェックサムが不正なためドロップされます。すべてのホストでflannel.1インターフェースのチェックサムオフロードを無効にすると（少なくともHetznerクラウドで）、以下のように動作します：

telnet 10.32.0.254 53
Trying 10.32.0.254...
Connected to 10.32.0.254.
Escape character is '^]'.
...

そして再度tcpdumpの出力を確認すると：

22:34:26.605677 IP (tos 0x0, ttl 64, id 794, offset 0, flags [none], proto UDP (17), length 110)
    10.8.0.112.59225 > 10.8.0.111.8472: [udp sum ok] OTV, flags [I] (0x08), overlay 0, instance 1
IP (tos 0x10, ttl 63, id 16989, offset 0, flags [DF], proto TCP (6), length 60)
    10.200.94.0.42152 > 10.200.1.37.53: Flags [S], cksum 0xd49b (correct), seq 1673757006, win 43690, options [mss 65495,sackOK,TS val 2438020768 ecr 0,nop,wscale 7], length 0
...

最後の行ではチェックサムが正しいことが確認できます。Flannelインターフェースのプロトコルオフロード状態や他の機能はethtool -k flannel.1で確認できます。

依存関係

• etcd（ansible-role-etcdを参照）
• CNIプラグイン（ansible-role-cniや、CNIプラグインをインストールする他のロールを参照）

例プレイブック

- hosts: flannel
  roles:
    - githubixx.flanneld

ライセンス

GNU GENERAL PUBLIC LICENSE バージョン3

著者情報

http://www.tauceti.blog