https://github.com/cilium/cilium

sort by:
Revision Author Date Message Commit Date
079bdaf Prepare for release v1.9.5 Signed-off-by: Chris Tarazi <chris@isovalent.com> 10 March 2021, 21:54:41 UTC
da19d74 adds a getting started guide for Rancher [ upstream commit 2b6e04fb6eafbb2337442f637807b4aa8b847671 ] Signed-off-by: Sean Winn <sean@isovalent.com> Signed-off-by: Paul Chaignon <paul@cilium.io> 10 March 2021, 20:09:05 UTC
76ec7ba nat: Create SNAT maps only if BPF NodePort is enabled [ upstream commit 602e5ce88482ca3cee1e232fc494e9b0e2faf53a ] The IPv4 and IPv6 SNAT maps are only used if BPF NodePort is enabled. Commit cac5218 ("datapath: remove SNAT maps entries when kube-proxy is enabled") removed the maps on startup if BPF NodePort is disabled. We were however still creating them regardless of the BPF NodePort status. The creation started a controller which then fails once the actual map is removed. This commit fixes the issue by not creating the userspace object, including the controller, for the SNAT maps when BPF NodePort is disabled. Fixes: cac5218 ("datapath: remove SNAT maps entries when kube-proxy is enabled") Fixes: https://github.com/cilium/cilium/issues/15141 Signed-off-by: Paul Chaignon <paul@cilium.io> 10 March 2021, 20:09:05 UTC
219ea4b daemon: Init KPR options early, before map info inits [ upstream commit 37ab40e23b83c2d906ae1ff8f54a125b6b16cf5d ] Initialize the kube-proxy replacement options earlier in the agent startup, to ensure all options have reach their final state (based on kernel probes and option conflict) when we initialize the BPF map information (e.g., create or not NAT maps based on whether BPF NodePort is enabled). Signed-off-by: Paul Chaignon <paul@cilium.io> 10 March 2021, 20:09:05 UTC
8155062 ctmap: Remove NatMap interface [ upstream commit 2a62b83ea422cd35c138d2ce26f6f3d84f954db0 ] Using the NatMap interface was causing issues when trying to check if the natMap attribute is nil. We don't need the NatMap interface and can simply use *nat.Map directly. Suggested-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Paul Chaignon <paul@cilium.io> 10 March 2021, 20:09:05 UTC
13efb49 envoy: Silently discard expected warnings if flowdebug is not enabled [ upstream commit 93962ed9c2fa3ac664f37a49206f97f00da96ab6 ] Envoy 1.17 keeps warning about a known runtime singleton issue which will not be fixed before Envoy release 1.18. Silently drop this warnings unless flowdebug is enabled (via --debug-verbose=flow). Remove this special treatment when the upstream envoy issue https://github.com/envoyproxy/envoy/issues/13504 is fixed. Fixes: #14919 Signed-off-by: Jarno Rajahalme <jarno@covalent.io> 10 March 2021, 03:56:33 UTC
eeefb78 datapath: Do not create NAT entry for egress ICMP ECHO_REPLY Previously, when ICMP ECHO was sent from outside to a host managed by Cilium, the handling of the reply to it (ICMP ECHO_REPLY) used to create the following entries: CT | src | dst | dir | +------------+-----------+-----+ | outside:0 | host:ID | OUT | NAT | src | dst | dir | +------------+-----------+-----+ | host:0 | outside:ID| OUT | <-- ICMP ECHO_REPLY +------------+-----------+-----+ | outside:ID | host:ID | IN | <-- ICMP ECHO The NAT IN entry was useful only to avoid pod->outside to be SNAT-ed with the same ID, but this is no longer the case after the "datapath: Fix unintended SNAT of ICMP ECHO" commit. Also, this removes the problematic CT GC case in which for such a CT entry a corresponding NAT OUT entry with the existing GC logic could not be found. Finally, do not skip SNAT for ICMP packets based on ID. Signed-off-by: Martynas Pumputis <m@lambda.lt> 10 March 2021, 00:48:43 UTC
df9b323 datapath: Fix unintended SNAT of ICMP ECHO Let's say that we have a pod sending ICMP ECHO request to outside. The handling of the request creates the following CT and NAT entries: CT | src | dst | dir | +------------+-----------+-----+ | outside:ID | pod:0 | OUT | NAT | src | dst | dir | +------------+-----------+-----+ | pod:ID | outside:0 | OUT | +------------+-----------+-----+ | outside:0 | host:ID | IN | Now, let's say that we have the outside sending ICMP echo request to the host running the pod with the same ID as above. The following NAT lookup is performed: outside:0 -> host:ID IN The lookup will find the NAT entry from the pod->outside case. This will translate the request making it to be delivered to the pod instead of the host. Fix this by making the ICMP ECHO ID placement in the NAT tuple to depend on the ICMP type instead of the packet direction. After this change, the NAT entries will be the same as above, but the lookup for the outside->host case is changed to the following: outside:ID -> host:0 IN (doesn't match any NAT entry above). Signed-off-by: Martynas Pumputis <m@lambda.lt> 10 March 2021, 00:48:43 UTC
dfb008a datapath: Fix ICMP ID placement in CT entries The [1] changed the ICMP ECHO/ECHO_REPLY ID placement in CT entries in order to fix the problem when an egress NAT entry for ECHO_REPLY cannot be found by a corresponding CT entry which lead to leaking NAT entries, as the CT GC could not find the NAT entries by the given CT entry. The changed placement introduced an interesting problem described below. What happens when a pod (10.154.0.89) sends ICMP EchoRequest to 8.8.8.8? A CT entry with the following key is created: dst src dport sport TUPLE_F_OUT | | | | | 0a 9a 00 59 08 08 08 08 00 00 08 00 01 00 <-- dst=pod because of the reverse before the second __ct_lookup. ("ICMP OUT 10.154.0.89:2048 -> 8.8.8.8:0 [...]" in the "cilium bpf ct list global" output). What happens when 8.8.8.8 sends ICMP EchoRequest to the pod? The lookup is performed for the reverse flow first with the following key: dst src dport sport TUPLE_F_OUT <-- dir is TUPLE_F_OUT | | | | | because we do the 0a 9a 00 59 08 08 08 08 00 00 08 00 01 00 lookup in reverse order first. The key matches the first __ct_lookup(), hence the return is CT_REPLY. Previously, before the changed ID placement, the CT key for 8.8.8.8 -> the pod lookup was: 0a 9a 00 59 08 08 08 08 08 00 00 00 01 00 This resulted in CT_NEW instead of CT_REPLY. [1]: https://github.com/cilium/cilium/pull/12729 Signed-off-by: Martynas Pumputis <m@lambda.lt> 10 March 2021, 00:48:43 UTC
3aaade9 .github: Improve digest formatting in workflow [ upstream commit c8d7b82c98398b136a61bdb0b662296c52ca34ee ] This just adjusts the formatting slightly to follow the digest formats that we have used to report recent releases. Cosmetic only. Signed-off-by: Joe Stringer <joe@cilium.io> Signed-off-by: Alexandre Perrin <alex@kaworu.ch> 09 March 2021, 09:20:49 UTC
635a795 contrib: Submit release PRs via user repo [ upstream commit 3560ec7455025a19dce7c8cc106d2bb225ec8b95 ] Rather than depending on the ability to push release PRs via the main cilium repo, rely on the release manager's repo for this instead. Signed-off-by: Joe Stringer <joe@cilium.io> Signed-off-by: Alexandre Perrin <alex@kaworu.ch> 09 March 2021, 09:20:49 UTC
ef4367c contrib: Move contributor remote detection to lib [ upstream commit 216dc75430e4481a694d6cb53042ec44e74afa66 ] Move this function into the common lib area so that it can be reused by other scripts such as the release scripts. Signed-off-by: Joe Stringer <joe@cilium.io> Signed-off-by: Alexandre Perrin <alex@kaworu.ch> 09 March 2021, 09:20:49 UTC
50f9883 contrib: Use 'get_remote' shell fn to fetch remote [ upstream commit f330af5accb0613150da8091f8b8a0af8ba9e86b ] This helps when you have multiple remotes like 'upstream', 'origin'. Signed-off-by: Joe Stringer <joe@cilium.io> Signed-off-by: Alexandre Perrin <alex@kaworu.ch> 09 March 2021, 09:20:49 UTC
452b182 checker: Add ExportedEquals checker [ upstream commit 57b25c58008002005617d38c97efab6581723df9 ] The updated protobuf implementation contains cyclical data structures and unexported fields that can not be compared. Add a new checker "ExportedEquals" that only compares exported fields of the given data structures. This ignoring of unexported fields is not safe for comparing arbitrary data structures which may store internal state in unexported fields. Use this new "ExportedEquals" checker to compare protobuf Messages. This avoids comparing global data structures pointer to by protobuf implementation specific fields. Avoid infinite recursion by keeping track which pointers have already been followed. Change existing use of checker.Equals to use simple Equals or HasLen instead when possible. Signed-off-by: Jarno Rajahalme <jarno@covalent.io> 09 March 2021, 02:28:58 UTC
4349138 envoy: Avoid copying protobuf.Message [ upstream commit 2df25bb53a211ddc76349004185952783786c4c0 ] protobuf.Message may contain a mutex, which trips the go vet linter in the CI. Fix by using .String() instead on debug messages, and using a pointer to transfer ownership rather than a copy. Signed-off-by: Jarno Rajahalme <jarno@covalent.io> 09 March 2021, 02:28:58 UTC
3c547ac envoy: Envoy API update Update Envoy API to be able to compile without using deprecated fields. Signed-off-by: Jarno Rajahalme <jarno@covalent.io> 09 March 2021, 02:28:58 UTC
ff27cac docs: Clarify external workload docs [ upstream commit 79d071977aceabc02c9e9ccac4c43b344f082f04 ] Instruct users to pull the Cilium image before disabling 'systemd-resolved.service'. Mention that the port 2379 needs to be explicitly given in LoadBalancer instructions. Signed-off-by: Jarno Rajahalme <jarno@covalent.io> 09 March 2021, 02:28:58 UTC
5078198 envoy: Do not use deprecated fields [ upstream commit 8105ca45ebbbafc5861ad62d48fcb4610495fb7d ] Use new options instead of these deprecated fields to avoid deprecation warnings: - RouteAction.max_grpc_timeout - Cluster.protocol_selection - Cluster.http2_protocol_options Define runtime option "overload.global_downstream_max_connections" to avoid a warning like: "there is no configured limit to the number of allowed active connections. Set a limit via the runtime key overload.global_downstream_max_connections" Fixes: #14919 Signed-off-by: Jarno Rajahalme <jarno@covalent.io> 09 March 2021, 02:28:58 UTC
6fbf803 doc: Fix masquerade option in AKS/Azure guides The option enableIPv4Masquerade is only known in 1.10+. 1.9 must use the masquerade option. Fixes: 07f15bf1327 ("doc: Move Azure IPAM out of beta") Reported-by: Andor Nemeth <andor_nemeth@swissre.com> Signed-off-by: Thomas Graf <thomas@cilium.io> 08 March 2021, 18:02:58 UTC
b4869be tools/licensegen: consider COPYING files [ upstream commit 9ae3e30c23eab65aada9023a2a75ac0fbae6e6fd ] Some projects use a COPYING file for their license. Consider these as well. Currently, the only vendored dependency using such a file is github.com/BurntSushi/toml: $ diff -u LICENSE.all LICENSE.all.new Signed-off-by: Tobias Klauser <tklauser@distanz.ch> --- LICENSE.all 2021-03-08 11:12:05.281088204 +0100 +++ LICENSE.all.new 2021-03-08 11:11:38.757023948 +0100 @@ -2132,6 +2132,29 @@ See the License for the specific language governing permissions and limitations under the License. +Name: vendor/github.com/BurntSushi/toml/COPYING +License: The MIT License (MIT) + +Copyright (c) 2013 TOML authors + +Permission is hereby granted, free of charge, to any person obtaining a copy +of this software and associated documentation files (the "Software"), to deal +in the Software without restriction, including without limitation the rights +to use, copy, modify, merge, publish, distribute, sublicense, and/or sell +copies of the Software, and to permit persons to whom the Software is +furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice shall be included in +all copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, +OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN +THE SOFTWARE. + Name: vendor/github.com/Microsoft/go-winio/LICENSE License: The MIT License (MIT) Signed-off-by: Tobias Klauser <tklauser@distanz.ch> 08 March 2021, 17:51:22 UTC
709bd32 config: remove POLICY_AUDIT_MODE from node_config.h [ upstream commit 1378bb1406be4316448d1a24e59d51192310a05c ] Fix: #15197 If audit mode is enabled at agent startup, the POLICY_AUDIT_MODE macro in node_config.h will override the corresponding settings in each endpoint's header file, which leads to runtime changes (via CLI/API) don't work. Looking at the code, the macro in node_config.h seems to be unnecessary and can be removed. And this can solve the problem described above. Signed-off-by: ArthurChiao <arthurchiao@hotmail.com> Signed-off-by: Tobias Klauser <tklauser@distanz.ch> 08 March 2021, 17:51:22 UTC
7531942 daemon: do not allow --auto-direct-node-routes when tunneling is enabled [ upstream commit a537ae3d2e8985b77a31fad5fb816e2c79ae0664 ] Enabling --auto-direct-node-routes when tunneling is enabled can cause traffic to leave the node through a physical interface (i.e. not encapsulated) rather than via the tunnel. Reported-by: Paul Chaignon <paul@cilium.io> Signed-off-by: Gilberto Bertin <gilberto@isovalent.com> Signed-off-by: Tobias Klauser <tklauser@distanz.ch> 08 March 2021, 17:51:22 UTC
a6d584b bpf: Fix bpf masquerade issue when host connecting to remote pod [ upstream commit 66dc91746d8220aeb0ebb5a5015ab1ab5962221f ] Invoking the agent as following on two nodes ... # ./daemon/cilium-agent --identity-allocation-mode=crd --enable-ipv6=true \ --enable-ipv4=true --disable-envoy-version-check=true --tunnel=disabled \ --k8s-kubeconfig-path=$HOME/.kube/config --kube-proxy-replacement=strict \ --enable-l7-proxy=false --enable-bpf-masquerade=true \ --enable-host-legacy-routing=false --auto-direct-node-routes=true \ --enable-bandwidth-manager=true --native-routing-cidr=10.217.0.0/16 ... I ran into the issue that the hostns (192.168.180.29) cannot connect to a remote Pod (10.217.1.175): # tcpdump -i enp2s0np0 -n [...] 11:59:01.002065 IP 192.168.180.29.38233 > 10.217.1.175.12865: Flags [S], seq 3173960079, win 64240, options [mss 1460,sackOK,TS val 444671211 ecr 0,nop,wscale 7], length 0 11:59:01.002113 IP 192.168.180.28.59227 > 192.168.180.29.38233: Flags [S.], seq 2874324629, ack 3173960080, win 65160, options [mss 1460,sackOK,TS val 3030265373 ecr 444671211,nop,wscale 7], length 0 11:59:01.002242 IP 192.168.180.29.38233 > 192.168.180.28.59227: Flags [R], seq 3173960080, win 0, length 0 What can be seen is that the SYN/ACK reply from remote gets wrongly masqueraded to the node IP address (192.168.180.28) of the Pod, hence the subsequent RST. Debugging further, what can be seen is that in snat_v4_needed() we do find an ipcache entry (the catchall case) where info->sec_label == REMOTE_NODE_ID does not match, and therefore we masq for the remote node. By default from daemon side, --enable-remote-node-identity is false which then also does not have an ipcache entry: # ./cilium/cilium bpf ipcache list | grep 192.168.180.29 10.217.0.152/32 4 0 192.168.180.29 10.217.0.208/32 23768 0 192.168.180.29 10.217.0.50/32 16762 0 192.168.180.29 10.217.0.69/32 104 0 192.168.180.29 f00d::a1d:0:0:a1bf/128 104 0 192.168.180.29 f00d::a1d:0:0:1be3/128 23768 0 192.168.180.29 f00d::a1d:0:0:ce91/128 104 0 192.168.180.29 10.217.0.91/32 104 0 192.168.180.29 10.217.0.219/32 42983 0 192.168.180.29 f00d::a1d:0:0:3088/128 16762 0 192.168.180.29 f00d::a1d:0:0:ae10/128 42983 0 192.168.180.29 f00d::a1d:0:0:dfe1/128 4 0 192.168.180.29 10.217.0.85/32 1 0 192.168.180.29 f00d::a1d:0:0:9dc8/128 1 0 192.168.180.29 Rerunning the agent with ... # ./daemon/cilium-agent --identity-allocation-mode=crd --enable-ipv6=true \ --enable-ipv4=true --disable-envoy-version-check=true --tunnel=disabled \ --k8s-kubeconfig-path=$HOME/.kube/config --kube-proxy-replacement=strict \ --enable-l7-proxy=false --enable-host-legacy-routing=false \ --auto-direct-node-routes=true --enable-bandwidth-manager=true \ --native-routing-cidr=10.217.0.0/16 --enable-bpf-masquerade=true \ --enable-remote-node-identity=true ... fixes the situation, and connectivity works as expected. ipcache then has the entry as well with REMOTE_NODE_ID sec label: # ./cilium/cilium bpf ipcache list | grep 192.168.180.29 10.217.0.85/32 6 0 192.168.180.29 10.217.0.91/32 104 0 192.168.180.29 10.217.0.50/32 16762 0 192.168.180.29 10.217.0.219/32 42983 0 192.168.180.29 10.217.0.152/32 4 0 192.168.180.29 f00d::a1d:0:0:dfe1/128 4 0 192.168.180.29 10.217.0.69/32 104 0 192.168.180.29 f00d::a1d:0:0:3088/128 16762 0 192.168.180.29 f00d::a1d:0:0:4a54/128 4 0 192.168.180.29 f00d::a1d:0:0:9dc8/128 6 0 192.168.180.29 f00d::a1d:0:0:a1bf/128 104 0 192.168.180.29 f00d::a1d:0:0:ae10/128 42983 0 192.168.180.29 f00d::a1d:0:0:1be3/128 23768 0 192.168.180.29 10.217.0.32/32 4 0 192.168.180.29 10.217.0.208/32 23768 0 192.168.180.29 192.168.180.29/32 6 0 0.0.0.0 <----- f00d::a1d:0:0:ce91/128 104 0 192.168.180.29 Given the code, make --enable-remote-node-identity=true a hard dependency for the --enable-bpf-masquerade=true option. If the latter could not be enabled, we also need to disable BPF host routing here. Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Tobias Klauser <tklauser@distanz.ch> 08 March 2021, 17:51:22 UTC
fe4c9ba service: Skip upsert of service for disabled IP family [ upstream commit ad61343d32f34198584d3a624286d41ecb338cb0 ] The following panic can happen when trying to upsert e.g. an IPv6 service in the datapath when IPv6 is disabled in the agent. The corresponding IPv6 lbmap doesn't exist so we get a nil pointer reference. panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x1cd5900] goroutine 147 [running]: github.com/cilium/cilium/pkg/bpf.(*Map).OpenOrCreate(0x0, 0x0, 0x0, 0x0) /go/src/github.com/cilium/cilium/pkg/bpf/map_linux.go:464 +0x40 github.com/cilium/cilium/pkg/maps/lbmap.updateRevNatLocked(0x2b1b5a0, 0xc000b365fc, 0x2b07380, 0xc000ae7e80, 0xc000b365f0, 0x1) /go/src/github.com/cilium/cilium/pkg/maps/lbmap/lbmap.go:331 +0x68 github.com/cilium/cilium/pkg/maps/lbmap.(*LBBPFMap).UpsertService(0xc0009f5040, 0xc000b3a1e0, 0x0, 0xc000b47470) /go/src/github.com/cilium/cilium/pkg/maps/lbmap/lbmap.go:130 +0x5b7 github.com/cilium/cilium/pkg/service.(*Service).upsertServiceIntoLBMaps(0xc00065a280, 0xc00066b420, 0x421e500, 0x0, 0x421e540, 0x0, 0x0, 0x421e540, 0x0, 0x0, ...) /go/src/github.com/cilium/cilium/pkg/service/service.go:749 +0x3de github.com/cilium/cilium/pkg/service.(*Service).UpsertService(0xc00065a280, 0xc000661a40, 0x0, 0x0, 0x0) /go/src/github.com/cilium/cilium/pkg/service/service.go:324 +0xc85 github.com/cilium/cilium/pkg/k8s/watchers.(*K8sWatcher).addK8sSVCs(0xc000974480, 0xc0009a34c0, 0x1d, 0xc0009b2a96, 0x7, 0x0, 0xc000b22f30, 0xc00012be48, 0x10, 0x7ffff7fb9108) /go/src/github.com/cilium/cilium/pkg/k8s/watchers/watcher.go:743 +0x47b github.com/cilium/cilium/pkg/k8s/watchers.(*K8sWatcher).k8sServiceHandler.func1(0x0, 0xc0009a34c0, 0x1d, 0xc0009b2a96, 0x7, 0xc000b22f30, 0x0, 0xc00012be48, 0xc0009b0390) /go/src/github.com/cilium/cilium/pkg/k8s/watchers/watcher.go:447 +0xbc7 github.com/cilium/cilium/pkg/k8s/watchers.(*K8sWatcher).k8sServiceHandler(0xc000974480) /go/src/github.com/cilium/cilium/pkg/k8s/watchers/watcher.go:490 +0x95 created by github.com/cilium/cilium/pkg/k8s/watchers.(*K8sWatcher).RunK8sServiceHandler /go/src/github.com/cilium/cilium/pkg/k8s/watchers/watcher.go:495 +0x3f This commit fixes it by exiting early from UpsertService if trying to upsert a service for an IP family that is disabled in the agent. Fixes: https://github.com/cilium/cilium/issues/15000 Fixes: https://github.com/cilium/cilium/pull/14607 Signed-off-by: Paul Chaignon <paul@cilium.io> Signed-off-by: Tobias Klauser <tklauser@distanz.ch> 08 March 2021, 17:51:22 UTC
f4621ed docs: Fix max. number of tail calls [ upstream commit 7715446c0b6ff071fd0494578def44790daa0bcb ] The Linux kernel allows for 33 chained tail calls, not 32 as currently documented. The difference comes from what looks like an off-by-one error that was then generalized to all JIT compilers [1]. 1 - https://lore.kernel.org/bpf/20191218095825.GA15840@Omicron/T/ Signed-off-by: Paul Chaignon <paul@cilium.io> Signed-off-by: Tobias Klauser <tklauser@distanz.ch> 08 March 2021, 17:51:22 UTC
13d4000 add L7 warning [ upstream commit 769123365c08746eb228fbd231b0cc1833eacca0 ] Signed-off-by: stimmerman <stimmerman@schubergphilis.com> Signed-off-by: Tobias Klauser <tklauser@distanz.ch> 08 March 2021, 17:51:22 UTC
1c2e436 docs: Clarify titles for allow-all-endpoints examples [ upstream commit 0a3fabbfe3b2131c9b527f4fd5476e271746846f ] The previous titles may reinforce the impression that the examples allow all, that is including world, remote nodes, etc., when they actually only allow all endpoints. Signed-off-by: Paul Chaignon <paul@cilium.io> Signed-off-by: Tobias Klauser <tklauser@distanz.ch> 08 March 2021, 17:51:22 UTC
1273c57 .github: remove comments of GH action versions Dependabot will update those commit SHAs automatically and the version number will quickly outdated. To avoid confusion, we will remove the comments related with the versions a SHA points to from all GH actions. Signed-off-by: André Martins <andre@cilium.io> 08 March 2021, 17:40:49 UTC
926fc7f contrib/release: do not require images to be download locally The SHAs are available in the GH run, so we can use the GH API to retrieve them automatically. Signed-off-by: André Martins <andre@cilium.io> 08 March 2021, 17:40:49 UTC
c1d2351 .github: generate release files automatically Having files with the right format will make it easier to download them locally and use them as part of the release process. Signed-off-by: André Martins <andre@cilium.io> 08 March 2021, 17:40:49 UTC
f676239 install: add digests into helm charts This commit adds a simple way to add the image digests into the official helm charts. Signed-off-by: André Martins <andre@cilium.io> 08 March 2021, 17:40:49 UTC
9ea3543 node-neigh: Bump arping vsn to accept netlink.Link This commit bumps github.com/cilium/arping version to accept netlink.Link instead of net.Interface. The change allows us to use netlink to query netdevs which avoids a possible deadlock described in the previous commit. Signed-off-by: Martynas Pumputis <m@lambda.lt> 08 March 2021, 11:55:39 UTC
3ee6824 vendor: Bump netlink to include timeouts The bumped version includes the change [1] which sets a timeout for a default netlink socket. This prevents deadlocks when receiving a netlink msg (netlink is not reliable proto). [1]: https://github.com/vishvananda/netlink/pull/614 Signed-off-by: Martynas Pumputis <m@lambda.lt> 08 March 2021, 11:55:39 UTC
039d9c6 build(deps): bump actions/setup-go from v1 to v2.1.3 Bumps [actions/setup-go](https://github.com/actions/setup-go) from v1 to v2.1.3. - [Release notes](https://github.com/actions/setup-go/releases) - [Commits](https://github.com/actions/setup-go/compare/v1...37335c7bb261b353407cff977110895fa0b4f7d8) Signed-off-by: dependabot[bot] <support@github.com> 08 March 2021, 11:44:52 UTC
64ec368 test: update internal lyft certificate [ upstream commit 29f01fd63ef8678f92830e171bd2fc2f7dd0fa04 ] These files are generated by $ cd test/k8sT/manifests $ openssl req -new -key internal-lyft.key -out internal-lyft.csr $ openssl x509 -req -days 3600 -in internal-lyft.csr -CA testCA.crt -CAkey testCA.key -CAcreateserial -out internal-lyft.crt -sha256 common name needs to be `www.lyft.com`. testCA.key password is `cilium` Signed-off-by: Jarno Rajahalme <jarno@covalent.io> 06 March 2021, 02:33:33 UTC
e69dd13 envoy: Update to release 1.17.1 [ upstream commit 0d5c1a05c31d77e84c85c0b9c4c42b9c092bfbbb ] Signed-off-by: Jarno Rajahalme <jarno@covalent.io> 06 March 2021, 02:33:33 UTC
4edcc27 test: add `ciliu.operator-suffix` cli option [ upstream commit 114130883bed3ec906ff172604b1f8142547eefa ] This option makes it possible to use new operator.image.suffix Helm value in test runs. Signed-off-by: Maciej Kwiek <maciej@isovalent.com> Signed-off-by: Jarno Rajahalme <jarno@covalent.io> 05 March 2021, 20:53:42 UTC
1b26cd9 helm: Add suffix for operator image [ upstream commit f0d37f8e9a17b579401b8c002966bb731aff5d74 ] Because operator has cloud provider custom suffixes we are not able to add custom suffixes (like `-dev` or `-ci`) for the operator image seamlesly. New operator-specific option allows to do this. Signed-off-by: Maciej Kwiek <maciej@isovalent.com> Signed-off-by: Jarno Rajahalme <jarno@covalent.io> 05 March 2021, 20:53:42 UTC
1705bf6 ci: remove params from upstream k8s job [ upstream commit 637a0258aea1f50872ff3edb0f419dda02b3bfb4 ] These params are not compatible with our master job configuration, which causes master builds to fail. These params are stored in jenkins PR upstream k8s job config, so there is no need for them to be in jenkinsfile. Signed-off-by: Maciej Kwiek <maciej@isovalent.com> Signed-off-by: Nicolas Busseneau <nicolas@isovalent.com> 05 March 2021, 20:53:42 UTC
f970bc6 backporting: Update instructions for backporting workflow [ upstream commit 198fe64d79b53c983ba74f09f5c7a1c34408666d ] Commit 02320e added support for working with Cilium forks. Document the additional steps that are required with this new workflow. Additionally, workflow scope might be needed with the GitHub token in some cases that update the corresponding yamls - ``(refusing to allow a Personal Access Token to create or update workflow `.github/workflows/go-check.yaml` without `workflow` scope`` Signed-off-by: Aditi Ghag <aditi@cilium.io> Signed-off-by: John Fastabend <john.fastabend@gmail.com> 05 March 2021, 20:53:42 UTC
614840c checkpatch: update image (skip backports, +1 check, -1 warning) [ upstream commit 42fcb077ca8a5ce92e8d11cb591f240d33557e8c ] Update the checkpatch image tag (and switch to quay.io) to benefit from the following changes: - Skip checkpatch validation on backport branches - Suppress reports of type COMMIT_LOG_LONG_LINE - Add a repo-wide check on commit subject length - Use $GITHUB_REPOSITORY variable when retrieving commits For skipping backports we could instead update the conditions for running the job in the current repo, but that would be troublesome if we want to mark the action as required in the future. Therefore, we delegate the decision to the shell script in the checkpatch image: it returns early if a PR is not based on the 'master' branch. Signed-off-by: Quentin Monnet <quentin@isovalent.com> Signed-off-by: John Fastabend <john.fastabend@gmail.com> 05 March 2021, 20:53:42 UTC
49a9502 pkg/kvstore: fix etcd segmentation violation [ upstream commit c6610045b599b75e396c5420ee3e780c0bc78cd3 ] Fixes the following panic: ``` goroutine 531 [running]: go.etcd.io/etcd/clientv3/concurrency.(*Session).Orphan(...) /go/src/github.com/cilium/cilium/vendor/go.etcd.io/etcd/clientv3/concurrency/session.go:90 go.etcd.io/etcd/clientv3/concurrency.(*Session).Close(0xc0017b2b70, 0xc003a40570, 0x2) /go/src/github.com/cilium/cilium/vendor/go.etcd.io/etcd/clientv3/concurrency/session.go:96 +0x2a github.com/cilium/cilium/pkg/kvstore.(*etcdClient).Close(0xc001cfe000) /go/src/github.com/cilium/cilium/pkg/kvstore/etcd.go:1654 +0x48e github.com/cilium/cilium/pkg/clustermesh.(*remoteCluster).restartRemoteConnection.func1(0x2b31500, 0xc000fed2c0, 0x3c79c80, 0x0) /go/src/github.com/cilium/cilium/pkg/clustermesh/remote_cluster.go:178 +0x40c github.com/cilium/cilium/pkg/controller.(*Controller).runController(0xc001933200) /go/src/github.com/cilium/cilium/pkg/controller/controller.go:205 +0xa77 created by github.com/cilium/cilium/pkg/controller.(*Manager).updateController /go/src/github.com/cilium/cilium/pkg/controller/manager.go:120 +0xb50 ``` Fixes: c1b05dfba81a ("pkg/kvstore: introduced a dedicated session for locks") Signed-off-by: André Martins <andre@cilium.io> Signed-off-by: John Fastabend <john.fastabend@gmail.com> 05 March 2021, 20:53:42 UTC
d396fe6 ci: use quay.io images in upstream tests [ upstream commit 676c2add9849bd9ec00448c7d0b13c2ed6d73736 ] Signed-off-by: Maciej Kwiek <maciej@isovalent.com> Signed-off-by: John Fastabend <john.fastabend@gmail.com> 05 March 2021, 20:53:42 UTC
144e7ed ci: disable endpointslice in 1.17 cluster [ upstream commit 3fb2c6ace5c5bc8fcfd02b6cdc127216bf40f3db ] This change makes sure that we don't enable EndpointSlice in 1.17 clusters, so we can make sure that Cilium picks up the Endpoint objects created in tests. This change is fixing CI on 1.17 clusters. The EndpointSlice->Endpoint transition was made to fix GKE runs, which started running on 1.17 clusters. This ended up breaking 1.17 runs on non-gke clusters. This change will fix 1.17 runs. Signed-off-by: Maciej Kwiek <maciej@isovalent.com> Signed-off-by: John Fastabend <john.fastabend@gmail.com> 05 March 2021, 20:53:42 UTC
9787069 cilium: encryption, do not try to auto-discover if user provides iface [ upstream commit 428b0b0dededab19efe95403381c7138bf22e57c ] We currently ignore the user provided interface in ENI modes. Lets not overwrite user input if they specify it. Fixes: 2c5e192676 ("encryption/loader: Attach bpf_network program to correct interface for ENI mode") Signed-off-by: John Fastabend <john.fastabend@gmail.com> 05 March 2021, 20:53:42 UTC
efc66b9 cilium: encryption, clear mark from xfrm state in endpoint route modes [ upstream commit bc8bb3c97b9217657a3b592e1259e3d7f8fa5f9f ] In endpoint route modes we have routes in the system to the endpoints so we can skip the route back to the interface with bpf_network.o set, previously used to do the redirect needed when the stack can not route. This will work back to 4.14 kernels where XFRM_OUTPUT_MARK was added. If we need to go back further an alternative route/mark/rule will need to be added. Before this patch we had in state rules like this, src 0.0.0.0 dst 192.168.62.241 proto esp spi 0x00000003 reqid 1 mode tunnel replay-window 0 mark 0xd00/0xf00 output-mark 0xd00/0xf00 The above will use the 'output-mark' field to set the skb->mark after decryption to 0xd00. But, after patch (and with endpoint routes enables) we set the output-mark to 0 with the following state rule. src 0.0.0.0 dst 192.168.62.241 proto esp spi 0x00000003 reqid 1 mode tunnel replay-window 0 mark 0xd00/0xf00 output-mark 0x0/0xf00 Signed-off-by: John Fastabend <john.fastabend@gmail.com> 05 March 2021, 20:53:42 UTC
10ec88a cilium: encryption, remove mark from fwd rule [ upstream commit 031455357e0540f9c83398bc8593ee8284a5f0b3 ] Make the fwd policy rule more permissive and remove the mark. This way it will match in both cases: the mark is set because we are running without subnet set, the case where the mark is 0 in the ENI case. Before this patch an example fwd policy was, src 0.0.0.0/32 dst 192.168.32.0/19 dir fwd priority 0 ptype main mark 0xd00/0xf00 tmpl src 0.0.0.0 dst 192.168.62.241 proto esp reqid 1 mode tunnel level use Notice the 'mark 0xd00/0xf00' case restricting the match. After thiis patch we drop the mark, which will make the match more permissive. src 0.0.0.0/32 dst 192.168.32.0/19 dir fwd priority 0 ptype main tmpl src 0.0.0.0 dst 192.168.62.241 proto esp reqid 1 mode tunnel level use Signed-off-by: John Fastabend <john.fastabend@gmail.com> 05 March 2021, 20:53:42 UTC
17a483a cilium: encryption, ENI mode uses overlapping CIDR for outer/inner IPs [ upstream commit eb1ca8515eff62d7e7c151b1a7aa394c94153b80 ] TLDR: Remove 0xd00 rule/routes and let xfrm stack clear mark, but restrict overlapping pod/network CIDRs to 4.19 and above kernels. Because ENI mode uses an outer IP that overlaps with the inner pod IPs we need to be extra careful with the routing/rule configurations. For example we currently put a route in the decrypt routing table that looks like this, 192.168.0.0/16 dev cilium_host mtu 9001 where 192.168.0.0/16 is the subnet IP in this example. The purpose of this rule is twofold. First in the encryption direction it should match the encrypted packet and send it to cilium_host for necessary rewrites. Second on decryption there should be a simliar rule to match and send traffic to the sending interface. Something like this, $POD_CIDR dev eth0 mtu But, in the ENI case the decrypted CIDR and the encrypted CIDR are the same so they collide and we get a single rule. Worse now received ESP packets will match above and be routed to cilium_host before they can be decrypted. cilium_host will become confused and send them to the stack. At this point the mark set by bpf_network will be dropped and the stack will miss the xfrm state lookup. eth0 (rx esp) -> bpf_packet (mark for decryption mark=0xd00) -> rule finds 0x0d00 uses routing table 200 -> route hits {$CIDR dev cilium_host} -> ESP packet on cilium host runs bpf_host -> bpf_host return CTX_ACT_OK -> cilium_host fwd to cilium_net mark = 0 now -> ESP packet (dev=cilium_net) lookup xfrm state -> XFRM_NOSTATE error because mark cleared So everything went sideways after the 0xd00 routing table hit. The reason we even have a 0xd00 routing rule is to clear the mark bits after decryption, but before pushing to stack. Expected flow, eth0 (rx esp) -> bpf_packet (mark for decryption mark=0xd00) -> rule finds 0x0d00 uses routing table 200 -> no match send to stack with mark=0xd00 dev=eth0 -> xfrm state lookup matches -> decrypted packet mark=0xd00 rule for 0x0d00 uses tbl 200 -> route decrypted packet to eth0 -> bpf_packet runs clears mark and sends to stack At this point a decrypted packet is sent to stack just as if it had arrived decrypted. We could remove the steps after the xfrm decrypt if the xfrm stack cleared the mark with an output_mark action in xfrm. We haven't done this yet because it doesn't work pre-4.19 kernels. For ENI + overlapping subnets we will put the 4.19 kernel requirement and remove the 0xd00 rule completely. This simplifies datapath to just, eth0 (rx esp) -> bpf_packet mark -> decrypt -> stack ... Much cleaner, but only usable where the output mark can be set. So we keep the fallback path to use the mark if the mark action is not available. Before this patch two ip rules will be set for encrypt and decrypt, $ ip rule 1: from all fwmark 0xe00/0xf00 lookup 200 1: from all fwmark 0xd00/0xf00 lookup 200 ... After this patch only the encrypt rule will be set, $ ip rule 1: from all fwmark 0xe00/0xf00 lookup 200 ... Signed-off-by: John Fastabend <john.fastabend@gmail.com> 05 March 2021, 20:53:42 UTC
770a1ff cilium: encryption, fix redirect when endpoint routes enabled [ upstream commit 287f49c293b31bc8044239fd29b27e829e798e80 ] If we have endpoint routes enabled we want to use the routing table to find the lxc* device. Trying to do this with redirects doesn't work and may cause cilium_host to drop the packet. Signed-off-by: John Fastabend <john.fastabend@gmail.com> 05 March 2021, 20:53:42 UTC
b330965 cilium: encryption, ENI with subnet encryption needs rules for link IP [ upstream commit 86d78df2650d7bc7b416746f025a93eb800bf45c ] In ENI mode we use link IP for outer IPsec headers. In order for rules to be configured with correct IPs do a link lookup to discover the correct IP. Without this patch we will be missing the 'in' policy rules shown here, root@ip-192-168-90-141:/home/cilium# ip x p src 0.0.0.0/0 dst 192.168.0.0/16 dir fwd priority 0 ptype main tmpl src 0.0.0.0 dst 192.168.90.141 proto esp reqid 1 mode tunnel level use src 0.0.0.0/0 dst 192.168.64.0/19 dir in priority 0 ptype main mark 0xd00/0xf00 tmpl src 0.0.0.0 dst 192.168.90.141 Signed-off-by: John Fastabend <john.fastabend@gmail.com> 05 March 2021, 20:53:42 UTC
c24618c cilium: encryption, set optional flag for fwd policy rules [ upstream commit 53650a85a3f9b43c226449be045a966859a697f6 ] The XFRM stack will check for fwd policies after a decrypt or encrypt operation is done. We don't really need these for policy reasons because Cilium BPF side is enforcing policy. We can't just delete the rules though. If we did the decrypted traffic, which will still have the xfrm context encoded in the skb, will fail policy match and generate a NOPOLICY error. But as is in ENI modes the template lookup is failing with an TMPL_MISMATCH error. To fix make the fwd rules less strict by adding the optional bit to the rule. This will skip the template lookup altogether on the kernel side. Although this is needed for ENI cases where the packet is handled by the routing stack we can enable it in all cases. Making other cases less strict is also OK. Before this we had fwd `ip x p` like this, root@ip-192-168-90-141:/home/cilium# ip x p src 0.0.0.0/0 dst 192.168.0.0/16 dir fwd priority 0 ptype main tmpl src 0.0.0.0 dst 192.168.0.0 proto esp reqid 1 mode tunnel Now we have a 'level use' included indicating the policy is not strict, root@ip-192-168-90-141:/home/cilium# ip x p src 0.0.0.0/0 dst 192.168.0.0/16 dir fwd priority 0 ptype main tmpl src 0.0.0.0 dst 192.168.0.0 proto esp reqid 1 mode tunnel level use This corresponds to kernel code, static inline int xfrm_policy_ok(const struct xfrm_tmpl *tmpl, const struct sec_path *sp, int start, unsigned short family) { int idx = start; if (tmpl->optional) { if (tmpl->mode == XFRM_MODE_TRANSPORT) return start; } else start = -1; for (; idx < sp->len; idx++) { if (xfrm_state_ok(tmpl, sp->xvec[idx], family)) return ++idx; if (sp->xvec[idx]->props.mode != XFRM_MODE_TRANSPORT) { if (start == -1) start = -2-idx; break; } } return start; } And with 'level use' we hit the first 'if (tmpl->optional)' so that the subsequent xfrm_state_ok checks are skipped. Signed-off-by: John Fastabend <john.fastabend@gmail.com> 05 March 2021, 20:53:42 UTC
1255da0 cilium: encryption, allow programming IPSec FWD policy and template IPs [ upstream commit d02b6b74447335abe36c6b9b59027c5417d647ee ] So far we've programmed FWD policy rules to mirror the IN policy rules, but this requires the outer IPSec tunnel dstIP and inner dstIP cidr to be non-overlapping. Also we've been setting the template IPs the same as the matching src/dst IPs. We are about to fix the ENI case where these assumptions are no longer true. In order to support this allow pushing unique FWD/IN policies and also specify matching IPs and template IPs. Note: It probably makes sense to do a heavier refactor here and rip out UpsertIPsecEndpoint(), at this point it just adds confusion in my opinion. But, lets avoid that at the moment for backports. Signed-off-by: John Fastabend <john.fastabend@gmail.com> 05 March 2021, 20:53:42 UTC
5b622d5 cilium: vendor, use cilium/netlink until upstream patches land [ upstream commit 49fe92ad035fe681af83c1eab95a52f0afb822a9 ] For encryption use cases we need the optional parameter in Xfrm template. While we wait for those patches to land upstream point at cilium/netlink with included patches. Signed-off-by: John Fastabend <john.fastabend@gmail.com> 05 March 2021, 20:53:42 UTC
41ebdf4 ipsec: Use 64bits for XFRM output sequence number [ upstream commit 4ea12ee32e48ea08de72aa36d45f8df0f5f468bf ] The anti-replay mechanism of IPSec has several implementations in the Linux kernel [1]. The legacy implementation, which we are currently using, relies on a 32bit output sequence number. On cluster with a high packet throughput and less frequent key rotations, this number can reach its maximum value quickly. In such cases, the RFC states [2] that the packet should be dropped and userspace should take care of replacing the xfrm state entry. To reduce the likelihood of that happening, we can use the ESN implementation of the anti-replay mechanism, which relies on a 64bits sequence number. Regardless of the sequence number size, we currently rely on the user to implement key management outside of Cilium. To prevent issues as described above from happening in the longer term, we may want to handle the key management ourselves. 1 - https://elixir.bootlin.com/linux/v5.11/source/net/xfrm/xfrm_replay.c#L707 2 - https://tools.ietf.org/html/rfc4303#page-25 Co-authored-by: John Fastabend <john.fastabend@gmail.com> Signed-off-by: Paul Chaignon <paul@cilium.io> Signed-off-by: John Fastabend <john.fastabend@gmail.com> 05 March 2021, 20:53:42 UTC
ebc6f25 cilium: encryption fix, ipv4-pod-subnets without encryptnode fails [ upstream commit f93a2fdd70648f760e73bde8c0d3e6a494177512 ] In the default mode encryption picks the outer IP headers to use based on the destination IP of the packet to be encrypted. This works because we create a IPSec rule that matches the destination IP of the packet using the node CIDR IP used to allocate IPs for that node. This allows us to scale rules with number of nodes instead of number of pods. However, in modes where a global IP pool is used for any pods we no longer have a subnet -> pod mapping that we use above. To handle this case, instead of adding a rule per pod, we rewrite the srcIP,dstIP after encryption using the ipcache. The ipcache has the pod->node mapping so we can use this reliable. Then we do a fib lookup to rewrite the src/dst MAC and redirect out the correct egress interface. But, we have a bug where nodeEncrypt routing rules are added even if encryptNode is not enabled. Additionally, when encryptNode is enabled we add wrong and possibly conflicting rules from the normal path. To fix ensure we only add encryptNode routes correctlyy from the subnetEncryption path with ipv4-pod-subnets is enabled. Signed-off-by: John Fastabend <john.fastabend@gmail.com> 05 March 2021, 20:53:42 UTC
7510ce6 build(deps): bump KyleMayes/install-llvm-action from v1 to v1.1.1 Bumps [KyleMayes/install-llvm-action](https://github.com/KyleMayes/install-llvm-action) from v1 to v1.1.1. - [Release notes](https://github.com/KyleMayes/install-llvm-action/releases) - [Commits](https://github.com/KyleMayes/install-llvm-action/compare/v1...32c4866ebb71e0949e8833eb49beeebed48532bd) Signed-off-by: dependabot[bot] <support@github.com> 05 March 2021, 10:28:59 UTC
7434806 Removed empty comment line from podLabels/Annotations Signed-off-by: Yurii Komar <IKOM@equinor.com> 04 March 2021, 23:13:43 UTC
d58b2ff Update generated README for Helm values [ upstream commit c082f4d4cfe5f2b628e2dec44922bdea93f8a0ca ] Signed-off-by: Yurii Komar <IKOM@equinor.com> Signed-off-by: Aditi Ghag <aditi@cilium.io> 04 March 2021, 23:13:43 UTC
75238fa helm: Fix and add missing podLabels [ upstream commit 040bed0a10b6928d93c274cc6e68369aa43f95bb ] Signed-off-by: Yurii Komar <IKOM@equinor.com> Signed-off-by: Aditi Ghag <aditi@cilium.io> 04 March 2021, 23:13:43 UTC
31609bb docs: Add note about running kpr on Kind [ upstream commit 1c40e0a87a4a7bf6cfb3153c045e4dcd8ff17f16 ] Signed-off-by: Martynas Pumputis <m@lambda.lt> Signed-off-by: Aditi Ghag <aditi@cilium.io> 04 March 2021, 23:13:43 UTC
a63ff04 cgroups: Determine cgroup v2 hierarchy root for Kind [ upstream commit e9ce8306400bf416087046b8d5b013b23ebdcb3e ] When running on Kind, multiple cilium-agent instances running on the same host will try to attach to the same cgroup v2 root bpf_sock programs. As the LB BPF maps cannot be shared among them, in-cluster LB won't work. To fix this, we try to derive a cgroup v2 sub-hierarchy from a cilium-agent process cgroup v2. This guarantees, that each bpf_sock will be attached to a different cgroup. The net_cls and net_prio discrepancy when running with cgroup v2 was spotted by Daniel Borkmann. Signed-off-by: Martynas Pumputis <m@lambda.lt> Signed-off-by: Aditi Ghag <aditi@cilium.io> 04 March 2021, 23:13:43 UTC
07f15bf doc: Move Azure IPAM out of beta [ upstream commit 51924951ecafb26dcdbeb1f9a39a0f1522986936 ] Mark the Azure IPAM mode as the preferred way to install on AKS and Azure. This also allows to simplify the inlining of all Azure related docs. Signed-off-by: Thomas Graf <thomas@cilium.io> Signed-off-by: Aditi Ghag <aditi@cilium.io> 04 March 2021, 23:13:43 UTC
ecfc6ce test: set COMPOSE_INTERACTIVE_NO_CLI in precheck https://github.com/moby/moby/issues/4209://github.com/moby/moby/issues/42093 causes precheck to fail for us. Setting this env var should fix that. Signed-off-by: Maciej Kwiek <maciej@isovalent.com> 03 March 2021, 10:04:41 UTC
70cd959 bpf: Fix wrong map type when fetching preallocate map flags [ upstream commit 7e5a97f5dddb59394484d401c230cbaba4e6a686 ] Previously, the wrong map type was passed into GetPreAllocateMapFlags(), causing the wrong flags to be returned. This caused maps such as the CT maps to be recreated, for example, but this was only observable on older kernels such as <= 4.9: ``` 2021-02-04T13:40:49.490752344Z level=debug msg="Registered BPF map" path=/sys/fs/bpf/tc/globals/cilium_ct4_global subsys=bpf ... 2021-02-04T13:40:49.494128705Z level=info msg="Regenerating restored endpoints" numRestored=2 subsys=daemon 2021-02-04T13:40:49.494245539Z level=debug msg="Registered BPF map" path=/sys/fs/bpf/tc/globals/cilium_ct4_global subsys=bpf 2021-02-04T13:40:49.494377306Z level=warning msg="Flags mismatch for BPF map" file-path=/sys/fs/bpf/tc/globals/cilium_ct4_global new=0 old=1 subsys=bpf 2021-02-04T13:40:49.494387620Z level=warning msg="Removing map to allow for property upgrade (expect map data loss)" file-path=/sys/fs/bpf/tc/globals/cilium_ct4_global subsys=bpf 2021-02-04T13:40:49.494392369Z level=warning msg="CT Map upgraded, expect brief disruption of ongoing connections" file-path=/sys/fs/bpf/tc/globals/cilium_ct4_global subsys=map-ct ``` The reason it was only observed on such kernels is because the CT maps are first created with MapTypeLRUHash. This type is not supported in 4.9 kernels so the call to GetMapType() will normalize the map type to another that is supported on the kernel. In this case, it would be MapTypeHash. As previously mentioned, the flags returned depend on the map type. So in the CT maps case, they're first created with MapTypeLRUHash and then normalized to MapTypeHash, which if `--preallocate-bpf-maps=false`, then the map will be created with BPF_F_NO_PREALLOC. However, in the map recreate path which occurs after endpoint restoration, bpf.(*Map).CheckAndUpgrade()'s logic was asymmetric in how it fetches the preallocate flags via GetPreAllocateMapFlags() compared to bpf.(*Map).openOrCreate() since the wrong map type was passed in. Concretely, it passed MapTypeLRUHash instead of MapTypeHash to GetPreAllocateMapFlags() which requires preallocation (meaning not BPF_F_NO_PREALLOC), hence returning 0 for the flags. Therefore, since the wrong map type was being passed, the wrong flags were returned. Fixes: 6c4f620679 ("bpf: Set BPF_F_NO_PREALLOC before comparing maps") Signed-off-by: Chris Tarazi <chris@isovalent.com> 01 March 2021, 16:16:41 UTC
702d7a1 .github: add stable tag for v1.9 releases At this moment, stable should point to the latest v1.9 release. Adding this in the GH action as we are building the images using GitHub Actions. Signed-off-by: André Martins <andre@cilium.io> 23 February 2021, 19:04:36 UTC
b898a8e backporting: Stop scripts from running on non-Linux [ upstream commit 05eabc71a8525fffba8977eabdfd6e763dcd08c7 ] This is mainly for the benefit of macOS users typing in the wrong terminal. Signed-off-by: Tom Payne <tom@isovalent.com> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 23 February 2021, 14:01:41 UTC
b207703 datapath: Do not log when kernel config not found [ upstream commit d93177132d8e1b260424d851ce995a5eec1537ac ] Previously, when cilium-agent couldn't find a kernel config (a case for distros which do not expose the config via /proc/config.gz, but instead they store it in /boot, which is not mounted into a cilium container), we logged the following message: level=info msg="BPF system config check: NOT OK." error="Kernel Config file not found" subsys=linux-datapath This confused users making them to think that the missing kernel config was to blame for their connectivity issues. Thus, this commit silences the message (missing CONFIG_BPF would anyway result in non-cryptic error message). We can bring the message back once https://github.com/cilium/cilium/issues/14314 has been resolved. Signed-off-by: Martynas Pumputis <m@lambda.lt> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 22 February 2021, 23:07:58 UTC
48441be docs: Document changes to `submit-backport` [ upstream commit 388e7aafe921d8fc993f65ba1324b62c804081fa ] Co-authored-by: Quentin Monnet <quentin@isovalent.com> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 22 February 2021, 23:07:58 UTC
c5e5905 contrib/submit-backport: Support creating PRs from forks [ upstream commit 01956570b62fd423281c787f1389d2b98ce03d60 ] This adds support for pushing backport PRs from Cilium forks. Because the names of remotes in forked repositories are not standardized, the `submit-backport` script is changed such that it accepts two branch arguments: The upstream remote and the user (fork) remote. The upstream remote is detected using the existing `get_remote` helper, while the user (fork) remote is guessed by checking for a remote matching `github.com/<user>/cilium`. Co-authored-by: Quentin Monnet <quentin@isovalent.com> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 22 February 2021, 23:07:58 UTC
d2f43a0 contrib: Support alternative orgs in `get_remote` [ upstream commit bbf5b2021cdb6eabbcb892367b253be7d8b44dea ] This commit adds a optional positional argument to `get_remote` to allow obtaining the remote of Cilium forks in other organizations than the default `cilium` one. Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 22 February 2021, 23:07:58 UTC
72eb778 contrib: Detect correct remote in start-backport [ upstream commit c7e2573b5b7f60a54242a3dd561c5830724d0355 ] Previously, the script assumed `origin` would point to the upstream branch. For users with forked repositories this is not necessarily true, therefore this commit auto-detects the remote name based on the git remote url. Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 22 February 2021, 23:07:58 UTC
49afd16 test: Use Endpoint instead of EndpointSlice in 1.17 [ upstream commit 6b8e99432f17bc345668f404ed7fd067cba71292 ] GKE keeps EndpointSlice controller disabled by default on 1.17 clusters. This change causes tests to use `Endpoint` object instead of `EndpointSlice` on 1.17 clusters. Signed-off-by: Maciej Kwiek <maciej@isovalent.com> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 22 February 2021, 23:07:58 UTC
94313fc bpf: Enable monitor aggregation in complexity tests [ upstream commit 2b9eac22f8c8a58166bf4029e52ae838052e844d ] Monitor aggregation can have a strong impact on complexity, especially the set of flags that should be monitored, as shown in #14552. We should therefore enable it in complexity tests to be sure to catch any regression. Intuitively, we could expect monitor aggregation to reduce program size and complexity because it removes packet tracing points [1]. However, if we set MONITOR_AGGREGATION to 3, the compiler won't be able to remove the check on the monitor variable in emit_trace_notify [2]. That means we will have less tracing points overall but the few tracing points we will have will cause a higher complexity increase (since they require more conditional jumps). These few tracing points with higher complexity also happen to be in BPF program with very high complexity today, increasing the chance of hitting complexity issues as in #14552. 1 - https://github.com/cilium/cilium/blob/42eb1edafdaccad2814e7c16a1795e501fcd76b3/bpf/lib/trace.h#L130-L131 2 - https://github.com/cilium/cilium/blob/42eb1edafdaccad2814e7c16a1795e501fcd76b3/bpf/lib/trace.h#L144-L145 Related: https://github.com/cilium/cilium/issues/14552 Signed-off-by: Paul Chaignon <paul@cilium.io> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 22 February 2021, 23:07:58 UTC
ff2725e bpf: Add =1 to max. configs manually [ upstream commit d281e3e07244e4b9f3f82c167d26ac47e3a6b483 ] In bpf/Makefile, for the datapath configs used in complexity tests, we automatically add =1 to all options since commit 4ac6df3 ("bpf: Fix compile-tested macros used in is_defined"), as required by our is_defined macro. There is no way (that I could find) to do this only for macros that don't already have a value. Therefore, to be able to define macros with values different from 1 in the next commit, we need to add the =1 manually. Signed-off-by: Paul Chaignon <paul@cilium.io> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 22 February 2021, 23:07:58 UTC
6a41d58 test: Delete all unmanaged pods with a single kubectl delete [ upstream commit 9f14ae336465be6b4d01b24547f1af0292196c62 ] In flake #14915, some pods are not found while attempting to restart unmanaged pods on GKE. The assumption is that those pods are for some reason deleted between the time we list unmanaged pods and the time we delete them in RestartUnmanagedPodsInNamespace. One reason this might happen is because we delete unmanaged pods one by one. We first list all pods, then iterate on them, and every time a pod is found unmanaged we run 'kubectl delete'. Since executing 'kubectl delete' can take some time, it may take a while between when we take a snapshot of all pods and when we delete the last pods in the list. To avoid this, we can list all pods and iterate on them to find unmanaged pods. Then, in a single go we can delete all unmanaged pods with a single 'kubectl delete' command. This commit implements that approach. Signed-off-by: Paul Chaignon <paul@cilium.io> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 22 February 2021, 23:07:58 UTC
1296e94 test: Avoid unnecessary restarts of unmanaged pods [ upstream commit fd918a062b6b72afe3c4419c8407eb8194b86771 ] In tests, after Cilium installations, we often restart unmanaged pods to ensure they are managed by Cilium. In particular, on GKE, we used to restart unmanaged pods from both the kube-system and the cilium namespaces. However, commit 48be458 ("test: GKE: Install Cilium in kube-system namespace") removed the cilium namespace to install Cilium in the kube-system namespace. One of the two calls to RestartUnmanagedPodsInNamespace is therefore unnecessary. In addition, we also already restart pods in the namespace of the log-gatherer pods for all CI environments (vs. just GKE). If that last namespace is the kube-system namespace, then we don't need any call to RestartUnmanagedPodsInNamespace for GKE. I expect this will fix flake #14915. In that flake, some pods are not found while attempting to restart unmanaged pods. The flake started appearing in master when we merged commit 48be458. The theory is that the two quick calls to RestartUnmanagedPodsInNamespace for the same namespace lead us, in the second call, to select pods that have already been restarted by the first call. Such pods may disappear between the time we select them and the time we actually execute 'kubectl delete', resulting in the error: Error from server (NotFound): pods "kube-dns-66d6b7c877-dp4q2" not found Fixes: 48be458 ("test: GKE: Install Cilium in kube-system namespace") Fixes: https://github.com/cilium/cilium/issues/14915 Signed-off-by: Paul Chaignon <paul@cilium.io> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 22 February 2021, 23:07:58 UTC
d72ab3c docs: Install Cilium in kube-system ns on GKE [ upstream commit 6d05fbff3c677e45373d33cdbc2e4129f2cf8135 ] Signed-off-by: Paul Chaignon <paul@cilium.io> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 22 February 2021, 23:07:58 UTC
abd4d41 test: GKE: Install Cilium in kube-system namespace [ upstream commit 48be4585666816cf27bc8f9986c2ea9b1cfb46d7 ] Cilium on GKE is coming back home! Signed-off-by: Paul Chaignon <paul@cilium.io> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 22 February 2021, 23:07:58 UTC
d6d7fc2 iptables: Skip CILIUM_TRANSIENT_FORWARD for IPv6 [ upstream commit 9d9cc658e70a74ee575784298d302a8bf56ebfac ] Commit 317a671 ("iptables: Populate CILIUM_FORWARD chain for IPv6") fixed the agent to add IPv6 counterparts to the Cilium IPv4 rules in CILIUM_FORWARD. The same method is however used to install rules in CILIUM_FORWARD and CILIUM_TRANSIENT_FORWARD. The IPv6 chain for CILIUM_TRANSIENT_FORWARD doesn't exist, resulting in the following error message: level=error msg="Command execution failed" cmd="[ip6tables -w 5 -A CILIUM_TRANSIENT_FORWARD -o cilium_host -m comment --comment cilium (transient): any->cluster on cilium_host forward accept -j ACCEPT]" error="exit status 1" subsys=iptables level=warning msg="ip6tables: No chain/target/match by that name." subsys=iptables level=warning msg="failed to install transient iptables rules" error="cannot install forward chain rules to CILIUM_TRANSIENT_FORWARD: exit status 1" subsys=datapath-loader This commit fixes it by skipping the installation of IPv6 rules in CILIUM_TRANSIENT_FORWARD. If we want those rules, more work is required. Fixes: 317a671 ("iptables: Populate CILIUM_FORWARD chain for IPv6") Signed-off-by: Paul Chaignon <paul@cilium.io> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 22 February 2021, 23:07:58 UTC
03c1bc6 eni: Fix ForeachInterface if InstanceID is not known [ upstream commit ce0ae4288d2868cf6f1796e1384b60334daa683e ] Fix ForeachInterface to not return all ENIs if the instanceID is not known. None of the callers expect this behavior and if the instanceID is not known for some reason (for example due to the recent bug in 1.7 <-> 1.8 compatibility handling), then all ENIs are iterated over instead of just the ENI of the desired instance. Signed-off-by: Thomas Graf <thomas@cilium.io> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 22 February 2021, 23:07:58 UTC
c0b08cd eni: Fix compatibility when operator <= 1.7 is running [ upstream commit 439b142b049e6f4371d7cdac778ecc0ad15d7e85 ] In 1.8, some ENI specifics fields have been moved from spec.ENI to spec.IPAM to make them available for Azure IPAM. The old fields still need to be set to account for: * Downgrade of operator from 1.8 to 1.7 while agents remain on 1.8. * Race condition when the agents get upgraded from 1.7 to 1.8 before the operator gets upgraded to 1.8. While this version mismatch exists, the operator will assume a value of MinAllocate of 0 and a value of InstanceID of "". This leads to the following incorrect behavior: * The operator will not allocate up to MinAllocate * The InstanceID "" value will result in incorrect attachments of ENIs to the Status.ENI field, i.e., ENIs of other nodes will get reported on a node. This in turn will result in IPs being used on nodes for ENIs which are not attached to that node. Fixes: 04d253802a8 ("eni: No longer set Spec.ENI.PreAllocate") Fixes: f0dfcb4c1dc ("k8s: CiliumNode: Move generic IPAM parmeters into Spec.IPAM") Spotted-by: André Martins <andre@cilium.io> Signed-off-by: Thomas Graf <thomas@cilium.io> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 22 February 2021, 23:07:58 UTC
ba6d5c6 Revert kernel-check CLI [ upstream commit fc6736955e9807ebe84e2bd74332a19f39a59f21 ] This CLI is currently broken (Issue #14314). Let's remove it until we have it working properly. Signed-off-by: Joe Stringer <joe@cilium.io> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 22 February 2021, 23:07:58 UTC
6171bf2 add GH action to push hot fix images into -dev repositories Signed-off-by: André Martins <andre@cilium.io> 22 February 2021, 19:56:39 UTC
7bc80cd Update Go to 1.15.8 Signed-off-by: Tobias Klauser <tklauser@distanz.ch> 22 February 2021, 10:48:52 UTC
4f62ee0 policy: Do not detach if still using old policy [ upstream commit 0359854a08eb8634faaa5b34e048ce114503e32f ] Signed-off-by: Jarno Rajahalme <jarno@covalent.io> 22 February 2021, 09:48:46 UTC
16203cc policy: Clear references to old EndpointPolicies [ upstream commit a631f790f0e2a2b4ed77b94317bb0eae811af850 ] Clear references to old EndpointPolicies from the shared policy structures both on endpoint policy recalculations and when an endpoint is removed. Signed-off-by: Jarno Rajahalme <jarno@covalent.io> 22 February 2021, 09:48:46 UTC
17f2b2f nodediscovery: ensure instanceID is not empty [ upstream commit 91e68c2073089cdf207f09a4a5a9473c2482a9a8 ] An empty instanceID will cause issues. Add a check to ensure that instanceID is not empty. If it is empty, retry. We also increase the number of retries from 5 to 10. An option I considered was to also avoid the `Get()` operation if there is a conflict. I did not do this since it would go against the explicit intention of the original code: https://github.com/cilium/cilium/pull/11673. Related: #14991 Suggested-by: Chris Tarazi <chris@isovalent.com> Signed-off-by: Kornilios Kourtis <kornilios@isovalent.com> Signed-off-by: Jarno Rajahalme <jarno@covalent.io> 22 February 2021, 09:48:46 UTC
103be1c pkg/ipam: specify status flag when logging error [ upstream commit 7075fcdbddc0eeaba1dbd2b36638cbbbc9c8a44f ] update() is used both to update the status or everything else. When logging an error, add this information as well. Signed-off-by: Kornilios Kourtis <kornilios@isovalent.com> Signed-off-by: Jarno Rajahalme <jarno@covalent.io> 22 February 2021, 09:48:46 UTC
6f2fd64 contrib/k8s: use provided image when installing external workload [ upstream commit f5216e1e6ddd633cdfbaea0037c24f097f8c8596 ] When installing external workloads, launch Cilium agent from the provided, versioned image instead of hardcoding cilium/cilium:latest. The following command will now use Cilium 1.9.4 instead of latest: CLUSTER_ADDR=<ip> CILIUM_IMAGE=cilium/cilium:v1.9.4 ./install-external-workload.sh` Fixes: a1fac6aa2b56 ("contrib/k8s: Add scripts for provisioning VMs") Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Jarno Rajahalme <jarno@covalent.io> 22 February 2021, 09:48:46 UTC
23c9a2e k8s: update k8s libraries to 1.19.8 also update tested versions to 1.17.17 and 1.18.16 Signed-off-by: André Martins <andre@cilium.io> 22 February 2021, 09:41:39 UTC
cc325bd .github: publish into official repo for next release Signed-off-by: André Martins <andre@cilium.io> 19 February 2021, 11:31:00 UTC
6b96fa9 ci(smoketest): Pin promtool version in GHA [ upstream commit 3c630d80ef57b7f1cfdf74cf0551cb48e714d3f5 ] This commit is to pin the promtool, also avoid using -u in go get command. Closes #14950 Signed-off-by: Tam Mach <sayboras@yahoo.com> Signed-off-by: Paul Chaignon <paul@cilium.io> 15 February 2021, 23:41:20 UTC
6b53c6f labelsfilter: Tests for default filters and documented example [ upstream commit 3b0f6e8666dec1d22c230964ace62417c7b062d1 ] Signed-off-by: Paul Chaignon <paul@cilium.io> 15 February 2021, 23:41:20 UTC
71af959 docs: Clarify and update documentation on label filters [ upstream commit 1e80ec0b326f5d333e0257252df73eb9a602b176 ] This commit updates the list of default label filters and clarifies the default behavior, as well as how it changes when a first inclusive label is added. The example is also completed based on the new unit test added in the previous commit. Signed-off-by: Paul Chaignon <paul@cilium.io> 15 February 2021, 23:41:20 UTC
6f0927d encryption/loader: Attach bpf_network program to correct interface for ENI mode [ upstream commit 2c5e1926767e3ff115849eebdc5dca401b884ea1 ] Problem: Auto detection of encryption.interface leads to bpf_network program that does decryption to get attached to a wrong network interface. As a result, packets were not decrypted on the destination remote node. If users don't specify the cilium `encryption.interface` configuration, the interface can be auto detected based on main routing table. This breaks in ENI IPAM mode, where cilium_host is allocated an IP address from the pool of secondary IP addresses of a primary ENI interface. The IP allocation is influenced by the specified `first-interface-index` configuration. Hence, retrieve the correct primary interface for cilium_host for bpf_network program to be attached. Fix is verified based on the xfrm stats - Packet stats on source node : src 192.168.117.26 dst 192.168.142.218 proto esp spi 0x00000003(3) reqid 1(0x00000001) mode tunnel replay-window 0 seq 0x00000000 flag (0x00000000) mark 0x3e00/0xff00 output-mark 0xe00 aead rfc4106(gcm(aes)) 0xea5799388f441ba52b8c60c4f11c084bcdf5373e (160 bits) 128 anti-replay context: seq 0x0, oseq 0x9, bitmap 0x00000000 sel src 0.0.0.0/0 dst 0.0.0.0/0 uid 0 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 540(bytes), 9(packets) add 2021-02-05 18:12:08 use 2021-02-05 18:13:01 stats: replay-window 0 replay 0 failed 0 Packet stats on dest node : ip -s xfrm s src 192.168.142.218 dst 192.168.117.26 proto esp spi 0x00000003(3) reqid 1(0x00000001) mode tunnel replay-window 0 seq 0x00000000 flag (0x00000000) mark 0x3e00/0xff00 output-mark 0xe00 aead rfc4106(gcm(aes)) 0xea5799388f441ba52b8c60c4f11c084bcdf5373e (160 bits) 128 anti-replay context: seq 0x0, oseq 0x6, bitmap 0x00000000 sel src 0.0.0.0/0 dst 0.0.0.0/0 uid 0 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 360(bytes), 6(packets) add 2021-02-05 18:12:08 use 2021-02-05 23:19:07 stats: replay-window 0 replay 0 failed 0 Signed-off-by: Aditi Ghag <aditi@cilium.io> Signed-off-by: Paul Chaignon <paul@cilium.io> 15 February 2021, 23:41:20 UTC
461077a ipam: Add routes for cilium_host ENI address [ upstream commit f34371ce8f27387ecb06434a0aec26dbb3622144 ] Previously, we weren't adding policy based routing rules for cilium_host secondary IP address. These rules ensure that traffic from source node's cilium_host interface destined to the remote node in the cluster VPC is routed through the primary ENI interface for cilium_host. From there on, the traffic is routed to the AWS infrastructure router, which in turn routes it to the destination node. Fix involves setting up ip rules to the per ENI routing table. Verified that the correct rule is added, and encrypted traffic is reaching the destination node. root@ip-192-168-38-245:/home/cilium# ip addr show cilium_host 5: cilium_host@cilium_net: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 9001 qdisc noqueue state UP group default qlen 1000 link/ether da:61:19:32:0b:37 brd ff:ff:ff:ff:ff:ff inet 192.168.148.108/32 scope link cilium_host valid_lft forever preferred_lft forever inet6 fe80::d861:19ff:fe32:b37/64 scope link valid_lft forever preferred_lft forever root@ip-192-168-38-245:/home/cilium# ip rule show | grep 192.168.148.108 111: from 192.168.148.108 to 192.168.0.0/16 lookup 11 Tcpdump on the remote node shows encrypted packets getting received - tcpdump -eni eth1 dst 192.168.142.218 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes 17:32:52.216989 02:93:9c:00:a2:eb > 02:72:ef:86:3e:17, ethertype IPv4 (0x0800), length 130: 192.168.117.26 > 192.168.142.218: ESP(spi=0x00000003,seq=0x64), length 96 17:32:52.217694 02:93:9c:00:a2:eb > 02:72:ef:86:3e:17, ethertype IPv4 (0x0800), length 122: 192.168.117.26 > 192.168.142.218: ESP(spi=0x00000003,seq=0x65), length 88 17:32:52.217896 02:93:9c:00:a2:eb > 02:72:ef:86:3e:17, ethertype IPv4 (0x0800), length 206: 192.168.117.26 > 192.168.142.218: ESP(spi=0x00000003,seq=0x66), length 172 Signed-off-by: Aditi Ghag <aditi@cilium.io> Signed-off-by: Paul Chaignon <paul@cilium.io> 15 February 2021, 23:41:20 UTC
4d441a9 ipam/node: Introduce ENI info for cilium_host [ upstream commit 3ce38c9788ba7769030523c410cbc1277ed5d257 ] This is a preparatory commit that introduces ENI related information for cilium_host (aka router). Specifically, the information includes primary ENI interface that the secondary cilium_host IP is associated with, primary ENI MAC address and VPC CIDRs. Also, refactor the current IPAM internal IP allocating methods so that the ENI information can be retrieved for cilium_host (aka router). This information can be useful for setting up encryption related state such as ip rules and interface to attach BPF programs to. Signed-off-by: Aditi Ghag <aditi@cilium.io> Signed-off-by: Paul Chaignon <paul@cilium.io> 15 February 2021, 23:41:20 UTC
326d8ad ipam: Rename ENI Master field to PrimaryMAC [ upstream commit 773b1d2f5a08b3979ff07c016e13b56efcce47cf ] Signed-off-by: Aditi Ghag <aditi@cilium.io> Signed-off-by: Paul Chaignon <paul@cilium.io> 15 February 2021, 23:41:20 UTC
cbfa6f9 docker: Set GOPS_CONFIG_DIR in scratch images [ upstream commit 5440f9f5c2530de57e9fa1609f7184fb44eb0f74 ] This sets the `GOPS_CONFIG_DIR` environment variable in all images which use gops and are based on a scratch image. This fixes an issue with crun where due to missing environment variables, cilium-operator and hubble-relay would error out when starting the gops agent with the following error: ``` Error: failed to start gops agent: unable to get current user home directory: os/user lookup failed; $HOME is empty ``` This only seems to occur on `crun`, which sets `HOME` to an empty variable in scratch images. In non-scratch images, it sets HOME according to `/etc/passwd`, so this currently only affects the cilium-operator and hubble-relay images. Most other container runtimes seem to set `HOME` to `/` in scratch images, which works for gops. Fixes: #14301 Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> Signed-off-by: Paul Chaignon <paul@cilium.io> 15 February 2021, 23:41:20 UTC
90f91c8 test: Test of externalTrafficPolicy=Local in hostfw+vxlan mode [ upstream commit 1db771f25895ca8c830bd16336dc7f87df4d222a ] This test validates a potential regression on the path node1 -> pod@node2 via service with externalTrafficPolicy=Local when kube-proxy, tunneling and the host firewall are enabled. This commit also removes the explicit disabling of the host firewall in externalTrafficPolicy=Local tests. Signed-off-by: Paul Chaignon <paul@cilium.io> 15 February 2021, 23:41:20 UTC
back to top