github.phpd.cn/cilium/cilium@v1.6.12/Documentation/install/system_requirements.rst (about) 1 .. only:: not (epub or latex or html) 2 3 WARNING: You are looking at unreleased Cilium documentation. 4 Please use the official rendered version released here: 5 http://docs.cilium.io 6 7 .. _admin_system_reqs: 8 9 ******************* 10 System Requirements 11 ******************* 12 13 Before installing Cilium, please ensure that your system meets the minimum 14 requirements below. Most modern Linux distributions already do. 15 16 Summary 17 ======= 18 19 When running Cilium using the container image ``cilium/cilium``, the host 20 system must meet these requirements: 21 22 - `Linux kernel`_ >= 4.9.17 23 - :ref:`req_kvstore` etcd >= 3.1.0 or consul >= 0.6.4 24 25 When running Cilium as a native process on your host (i.e. **not** running the 26 ``cilium/cilium`` container image) these additional requirements must be met: 27 28 - `clang+LLVM`_ >=5.0 (Recommended: >=7.0) 29 - iproute2_ with BPF templating patches [#iproute2_foot]_ 30 31 .. _`clang+LLVM`: https://llvm.org 32 .. _iproute2: https://www.kernel.org/pub/linux/utils/net/iproute2/ 33 34 ======================== ========================== =================== 35 Requirement Minimum Version In cilium container 36 ======================== ========================== =================== 37 `Linux kernel`_ >= 4.9.17 no 38 Key-Value store (etcd) >= 3.1.0 no 39 Key-Value store (consul) >= 0.6.4 no 40 clang+LLVM >= 5.0.0 yes 41 iproute2 >= 5.0.0 [#iproute2_foot]_ yes 42 ======================== ========================== =================== 43 44 .. [#iproute2_foot] Requires support for BPF templating as documented 45 :ref:`below <iproute2_requirements>`. 46 47 Linux Distribution Compatibility Matrix 48 ======================================= 49 50 The following table lists Linux distributions that are known to work 51 well with Cilium. 52 53 ========================== ==================== 54 Distribution Minimum Version 55 ========================== ==================== 56 `Amazon Linux 2`_ all 57 `Container-Optimized OS`_ all 58 `CentOS`_ >= 7.0 [#centos_foot]_ 59 CoreOS_ stable (>= 1298.5.0) 60 Debian_ >= 9 Stretch 61 `Fedora Atomic/Core`_ >= 25 62 LinuxKit_ all 63 `RedHat Enterprise Linux`_ >= 8.0 64 Ubuntu_ >= 16.04.2, >= 16.10 65 Opensuse_ Tumbleweed, >=Leap 15.0 66 ========================== ==================== 67 68 .. _Amazon Linux 2: https://aws.amazon.com/amazon-linux-2/ 69 .. _CentOS: https://centos.org 70 .. _Container-Optimized OS: https://cloud.google.com/container-optimized-os/docs 71 .. _CoreOS: https://coreos.com/releases/ 72 .. _Debian: https://wiki.debian.org/DebianStretch 73 .. _Fedora Atomic/Core: http://www.projectatomic.io/blog/2017/03/fedora_atomic_2week_2/ 74 .. _LinuxKit: https://github.com/linuxkit/linuxkit/tree/master/kernel 75 .. _RedHat Enterprise Linux: https://www.redhat.com/en/technologies/linux-platforms/enterprise-linux 76 .. _Ubuntu: https://wiki.ubuntu.com/YakketyYak/ReleaseNotes#Linux_kernel_4.8 77 .. _Opensuse: https://www.opensuse.org/ 78 79 .. [#centos_foot] CentOS 7 requires a third-party kernel provided by `ElRepo <http://elrepo.org/tiki/tiki-index.php>`_ 80 whereas CentOS 8 ships with a supported kernel. 81 82 .. note:: The above list is based on feedback by users. If you find an unlisted 83 Linux distribution that works well, please let us know by opening a 84 GitHub issue or by creating a pull request that updates this guide. 85 86 .. _admin_kernel_version: 87 88 Linux Kernel 89 ============ 90 91 Cilium leverages and builds on the kernel BPF functionality as well as various 92 subsystems which integrate with BPF. Therefore, host systems are required to 93 run Linux kernel version 4.9.17 or later to run a Cilium agent. More recent 94 kernels may provide additional BPF functionality that Cilium will automatically 95 detect and use on agent start. 96 97 In order for the BPF feature to be enabled properly, the following kernel 98 configuration options must be enabled. This is typically the case with 99 distribution kernels. When an option can be built as a module or statically 100 linked, either choice is valid. 101 102 .. code:: bash 103 104 CONFIG_BPF=y 105 CONFIG_BPF_SYSCALL=y 106 CONFIG_NET_CLS_BPF=y 107 CONFIG_BPF_JIT=y 108 CONFIG_NET_CLS_ACT=y 109 CONFIG_NET_SCH_INGRESS=y 110 CONFIG_CRYPTO_SHA1=y 111 CONFIG_CRYPTO_USER_API_HASH=y 112 113 .. note:: 114 115 Users running Linux 4.10 or earlier with Cilium CIDR policies may face 116 :ref:`cidr_limitations`. 117 118 L7 proxy redirection currently uses ``TPROXY`` iptables actions as well 119 as ``socket`` matches. For L7 redirection to work as intended kernel 120 configuration must include the following modules: 121 122 .. code:: bash 123 124 CONFIG_NETFILTER_XT_TARGET_TPROXY=m 125 CONFIG_NETFILTER_XT_MATCH_MARK=m 126 CONFIG_NETFILTER_XT_MATCH_SOCKET=m 127 128 When ``xt_socket`` kernel module is missing the forwarding of 129 redirected L7 traffic does not work in non-tunneled datapath 130 modes. Since some notable kernels (e.g., COS) are shipping without 131 ``xt_socket`` module, Cilium implements a fallback compatibility mode 132 to allow L7 policies and visibility to be used with those 133 kernels. Currently this fallback disables ``ip_early_demux`` kernel 134 feature in non-tunneled datapath modes, which may decrease system 135 networking performance. This guarantees HTTP and Kafka redirection 136 works as intended. However, if HTTP or Kafka enforcement policies or 137 visibility annotations are never used, this behavior can be turned off 138 by adding the following to the helm configuration command line: 139 140 .. parsed-literal:: 141 142 helm template cilium \ 143 ... 144 --set global.enableXTSocketFallback=false 145 > cilium.yaml 146 147 Advanced Features and Required Kernel Version 148 ============================================= 149 Cilium requires Linux kernel 4.9.17 or higher, however development on additional 150 kernel features and functionality continues to progress in the Linux community. 151 Some Cilium features and functionality are dependent on newer kernel versions. 152 These additional Cilium features and functionality are enabled by upgrading to 153 a later kernel version as detailed below: 154 155 ======================= =============================== 156 Cilium Feature Minimum Kernel Version 157 ======================= =============================== 158 :ref:`cidr_limitations` >= 4.11 159 :ref:`host-services` >= 4.19.57, >= 5.1.16, >= 5.2 160 :ref:`kubeproxy-free` >= 4.19.57, >= 5.1.16, >= 5.2 161 ======================= =============================== 162 163 .. _req_kvstore: 164 165 Key-Value store 166 =============== 167 168 Cilium uses a distributed Key-Value store to manage, synchronize and distribute 169 security identities across all cluster nodes. The following Key-Value stores 170 are currently supported: 171 172 - etcd >= 3.1.0 173 - consul >= 0.6.4 174 175 See :ref:`install_kvstore` for details on how to configure the 176 ``cilium-agent`` to use a Key-Value store. 177 178 clang+LLVM 179 ========== 180 181 182 .. note:: This requirement is only needed if you run ``cilium-agent`` natively. 183 If you are using the Cilium container image ``cilium/cilium``, 184 clang+LLVM is included in the container image. 185 186 LLVM is the compiler suite that Cilium uses to generate BPF bytecode programs 187 to be loaded into the Linux kernel. The minimum supported version of LLVM 188 available to ``cilium-agent`` should be >=5.0. The version of clang installed 189 must be compiled with the BPF backend enabled. 190 191 See https://releases.llvm.org/ for information on how to download and install 192 LLVM. 193 194 .. _iproute2_requirements: 195 196 iproute2 197 ======== 198 199 .. note:: iproute2 is only needed if you run ``cilium-agent`` directly on the 200 host machine. iproute2 is included in the ``cilium/cilium`` container 201 image. 202 203 iproute2_ is a low level tool used to configure various networking related 204 subsystems of the Linux kernel. Cilium uses iproute2 to configure networking 205 and ``tc``, which is part of iproute2, to load BPF programs into the kernel. 206 207 The version of iproute2 must include the BPF templating patches. See the 208 links in the table below for documentation on how to install the correct 209 version of iproute2 for your distribution. 210 211 ================= ========================= 212 Distribution Link 213 ================= ========================= 214 Binary (OpenSUSE) `Open Build Service`_ 215 Source `Cilium iproute2 source`_ 216 ================= ========================= 217 218 .. _`Open Build Service`: https://build.opensuse.org/package/show/security:netfilter/iproute2 219 .. _`Cilium iproute2 source`: https://github.com/cilium/iproute2/tree/static-data 220 221 .. _firewall_requirements: 222 223 Firewall Rules 224 ============== 225 226 If you are running Cilium in an environment that requires firewall rules to enable connectivity, you will have to add the following rules to ensure Cilium works properly. 227 228 It is recommended but optional that all nodes running Cilium in a given cluster must be able to ping each other so ``cilium-health`` can report and monitor connectivity among nodes. This requires ICMP Type 0/8, Code 0 open among all nodes. TCP 4240 should also be open among all nodes for ``cilium-health`` monitoring. Note that it is also an option to only use one of these two methods to enable health monitoring. If the firewall does not permit either of these methods, Cilium will still operate fine but will not be able to provide health information. 229 230 If you are using VXLAN overlay network mode, Cilium uses Linux's default VXLAN port 8472 over UDP, unless Linux has been configured otherwise. In this case, UDP 8472 must be open among all nodes to enable VXLAN overlay mode. The same applies to Geneve overlay network mode, except the port is UDP 6081. 231 232 If you are running in direct routing mode, your network must allow routing of pod IPs. 233 234 As an example, if you are running on AWS with VXLAN overlay networking, here is a minimum set of AWS Security Group (SG) rules. It assumes a separation between the SG on the master nodes, ``master-sg``, and the worker nodes, ``worker-sg``. It also assumes ``etcd`` is running on the master nodes. 235 236 Master Nodes (``master-sg``) Rules: 237 238 ======================== =============== ==================== =============== 239 Port Range / Protocol Ingress/Egress Source/Destination Description 240 ======================== =============== ==================== =============== 241 2379-2380/tcp ingress ``worker-sg`` etcd access 242 8472/udp ingress ``master-sg`` (self) VXLAN overlay 243 8472/udp ingress ``worker-sg`` VXLAN overlay 244 4240/tcp ingress ``master-sg`` (self) health checks 245 4240/tcp ingress ``worker-sg`` health checks 246 ICMP 8/0 ingress ``master-sg`` (self) health checks 247 ICMP 8/0 ingress ``worker-sg`` health checks 248 8472/udp egress ``master-sg`` (self) VXLAN overlay 249 8472/udp egress ``worker-sg`` VXLAN overlay 250 4240/tcp egress ``master-sg`` (self) health checks 251 4240/tcp egress ``worker-sg`` health checks 252 ICMP 8/0 egress ``master-sg`` (self) health checks 253 ICMP 8/0 egress ``worker-sg`` health checks 254 ======================== =============== ==================== =============== 255 256 Worker Nodes (``worker-sg``): 257 258 ======================== =============== ==================== =============== 259 Port Range / Protocol Ingress/Egress Source/Destination Description 260 ======================== =============== ==================== =============== 261 8472/udp ingress ``master-sg`` VXLAN overlay 262 8472/udp ingress ``worker-sg`` (self) VXLAN overlay 263 4240/tcp ingress ``master-sg`` health checks 264 4240/tcp ingress ``worker-sg`` (self) health checks 265 ICMP 8/0 ingress ``master-sg`` health checks 266 ICMP 8/0 ingress ``worker-sg`` (self) health checks 267 8472/udp egress ``master-sg`` VXLAN overlay 268 8472/udp egress ``worker-sg`` (self) VXLAN overlay 269 4240/tcp egress ``master-sg`` health checks 270 4240/tcp egress ``worker-sg`` (self) health checks 271 ICMP 8/0 egress ``master-sg`` health checks 272 ICMP 8/0 egress ``worker-sg`` (self) health checks 273 2379-2380/tcp egress ``master-sg`` etcd access 274 ======================== =============== ==================== =============== 275 276 .. note:: If you use a shared SG for the masters and workers, you can condense 277 these rules into ingress/egress to self. If you are using Direct 278 Routing mode, you can condense all rules into ingress/egress ANY 279 port/protocol to/from self. 280 281 Privileges 282 ========== 283 284 The following privileges are required to run Cilium. When running the standard 285 Kubernetes `DaemonSet`, the privileges are automatically granted to Cilium. 286 287 * Cilium interacts with the Linux kernel to install BPF program which will then 288 perform networking tasks and implement security rules. In order to install 289 BPF programs system-wide, ``CAP_SYS_ADMIN`` privileges are required. These 290 privileges must be granted to ``cilium-agent``. 291 292 The quickest way to meet the requirement is to run ``cilium-agent`` as root 293 and/or as privileged container. 294 295 * Cilium requires access to the host networking namespace. For this purpose, 296 the Cilium pod is scheduled to run in the host networking namespace directly.