Skip to main content

Browse the archive

https://github.com/cilium/cilium
12 July 2024, 03:14:21 UTC
sort by:
Revision Author Date Message Commit Date
6258a70 Chris Tarazi 28 October 2020, 00:33:38 UTC Prepare for release v1.7.11 Signed-off-by: Chris Tarazi <chris@isovalent.com> 28 October 2020, 00:43:10 UTC
97f4483 Chris Tarazi 27 October 2020, 23:27:48 UTC Dockerfile: Bump cilium-runtime image Signed-off-by: Chris Tarazi <chris@isovalent.com> 28 October 2020, 00:21:39 UTC
c5480cf Martynas Pumputis 23 October 2020, 07:35:19 UTC docs: Add a note about systemd 245 rp_filter issue [ upstream commit 61100c50b8fece5cac963c67f71c259ca1b05052 ] Signed-off-by: Martynas Pumputis <m@lambda.lt> Signed-off-by: Chris Tarazi <chris@isovalent.com> 24 October 2020, 10:26:31 UTC
709b6a8 André Martins 22 October 2020, 14:54:32 UTC pkg/endpoint: calculate Kube API-Server lag from pod events [ upstream commit 4e29130043408063d62e91d21cfcf00f9ef837ed ] Since Cilium receives CNI events when a pod is created, Cilium can calculate the lag for kube-apiserver events by checking the time an ADD event for that Pod was received and subtracting by the time the CNI event for that pod was received. Signed-off-by: André Martins <andre@cilium.io> Signed-off-by: Chris Tarazi <chris@isovalent.com> 24 October 2020, 10:26:31 UTC
792414c André Martins 22 October 2020, 12:07:47 UTC pkg/labelsfilter: add more unit test and rewrite docs [ upstream commit 5733f6af771c127ecc2777af4da3d2bcbb870154 ] This change is only adding more unit tests to better understand the behavior of the labelsfilter as well as improving the documentation for the expectation of filtering labels. Signed-off-by: André Martins <andre@cilium.io> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 23 October 2020, 18:39:23 UTC
e752015 Jianlin Lv 14 October 2020, 06:46:41 UTC lbmap: Optimize lbmap byte order related code [ upstream commit 682f6826bce735056a5e0d285ec0cdbb1e6cd9c8 ] Gets rid of ToNetwork() in DumpParser(). Signed-off-by: Jianlin Lv <Jianlin.Lv@arm.com> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 23 October 2020, 18:39:23 UTC
4819438 Jianlin Lv 22 September 2020, 08:35:29 UTC lbmap: Fixed lb cmd byte order issue [ upstream commit c5b709b22cfc0c127c7bc92d7ea2eacdc6b59179 ] The port/RevNat info is stored in the bpf map in network byte order; When displaying the given lbmap content, the port needs to be converted to host byte order. Add ToHost() function for lbmap ToHost converts fields to host byte order. Signed-off-by: Jianlin Lv <Jianlin.Lv@arm.com> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 23 October 2020, 18:39:23 UTC
e13de04 arthurchiao 28 June 2020, 06:49:20 UTC metrics: fix negative identity count [ upstream commit 9673c485a72ec93c10e2db1f4fdc8feab45d3d98 ] Identity allocation uses cache and refcnt mechanisms, if the identity info is already in remote kvstore and localkeys store, it will just increase the refcnt, then notify the caller that this identity is reused. The caller will then not bump up the identity counter. However, there is a corner case that not get handled: refcnt from 0 to 1, which will result to negative identity count in the metrics output. This patch fixes the problem by returning another flag to indicate whether the identity is first-time referenced (refcnt from 0 to 1) or not. The caller then uses this information to determine whether or not to increase the counter. Signed-off-by: arthurchiao <arthurchiao@hotmail.com> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 23 October 2020, 18:39:23 UTC
984f7bf Paul Chaignon 25 September 2020, 17:16:13 UTC test: Display BPF map content on fail [ upstream commit ec2c18a074de2446186854188c4853c5c5664ffc ] Signed-off-by: Paul Chaignon <paul@cilium.io> Signed-off-by: Nate Sweet <nathanjsweet@pm.me> 22 October 2020, 23:23:11 UTC
fda8422 André Martins 22 October 2020, 13:26:46 UTC pkg/endpoint: reduce cardinality of prometheus labels [ upstream commit ec16cab361309155d012ce12b93750fc5b876c9d ] If the controller that is used for label resolution fails, the prometheus metrics will increase its cardinality since the uniquely controller name was being used as a prometheus label. To avoid this, we will reference these warnings with a common subsystem name, 'resolve-labels'. Fixes: a31ab29f57b2 ("endpoint: Run labels controller under ep manager") Signed-off-by: André Martins <andre@cilium.io> Signed-off-by: Paul Chaignon <paul@cilium.io> 22 October 2020, 22:04:10 UTC
9494169 Paul Chaignon 22 October 2020, 14:52:10 UTC backporting: Update labels by default when submitting backport [ upstream commit a8e67f1139aa9f384d2c0365aecfacd3532bda10 ] When submitting the backport PR using submit-backport, the script proposes to update the labels (i.e., remove needs-backport/X and add backport-pending/X): Sending pull request... Everything up-to-date https://github.com/cilium/cilium/pull/13700 Updating labels for PRs 13383 13608 12975 Set labels for all PRs above? [y/N] y Setting labels for PR 13383... ✓ Setting labels for PR 13608... ✓ Setting labels for PR 12975... ✓ The choice defaults to not updating the labels. That may give the wrong impression that it is an optional step---and if you're like me, when you're unsure what an optional step does, you skip it. We should default to setting the labels because we later rely on the labels being set (e.g., when we update them after the PR is merged). This commit changes it to the following: Sending pull request... Everything up-to-date https://github.com/cilium/cilium/pull/13700 Updating labels for PRs 13383 13608 12975 Set labels for all PRs above? [Y/n] Setting labels for PR 13383... ✓ Setting labels for PR 13608... ✓ Setting labels for PR 12975... ✓ Signed-off-by: Paul Chaignon <paul@cilium.io> 22 October 2020, 22:04:10 UTC
bb49619 Paul Chaignon 21 October 2020, 13:38:24 UTC endpoint: Avoid benign error messages on restoration [ upstream commit 228a485f2a5441f506ba9c0f357321c060f93590 ] During the endpoint restoration process, when we parse the endpoints, we assign them a reserved init identity if they don't already have an identity [0]. If we later remove the endpoint (because the corresponding K8s pod or interface are missing), we attempt to remove the identity from the identity manager. That last operation results in the following error message because the init identity was never added to the manager. level=error msg="removing identity not added to the identity manager!" identity=5 subsys=identitymanager This commit fixes it by skipping the removal attempt from the manager in the case of identity init. 0 - https://github.com/cilium/cilium/blob/80a71791320df34df5b6252b9680553e38d88d20/pkg/endpoint/endpoint.go#L819 Signed-off-by: Paul Chaignon <paul@cilium.io> 22 October 2020, 22:04:10 UTC
a2c9ee2 Jarno Rajahalme 14 April 2020, 16:48:20 UTC endpoint: Avoid unnecessary warning logs [ upstream commit df6ede7fa5555984d5b60d961cf3c90a965a6cdb ] Do not log a warning when can't release the ID of a disconnected endpoint. These changes remove warning logs like: msg="Unable to restore endpoint, ignoring" endpointID=1925 error="interface lxc18d62e89ea16 could not be found" k8sPodName=default/spaceship-d5d56b59-6c582 subsys=daemon msg="Unable to release endpoint ID" error="Unable to release endpoint ID 1925" state=disconnected subsys=endpoint Signed-off-by: Jarno Rajahalme <jarno@covalent.io> Signed-off-by: Paul Chaignon <paul@cilium.io> 22 October 2020, 22:04:10 UTC
87017ae Chris Tarazi 21 October 2020, 23:49:55 UTC endpoint: Remove interval for metadata resolver [ upstream commit cb9aa3e73c72f7a9c1bf65609d9db85f2c493e5f ] This controller's run interval is actually unnecessary as this controller is intended to only run once as long as it succeeds. This is evidenced by the fact that we have a `done` channel that's closed when the controller succeeds and a goroutine waiting `done` to be closed to remove the controller, thereby stopping it. In addition, in the very unlikely case that the controller is scheduled again to run _and_ the goroutine waiting for the `done` channel to be closed has not run yet, the controller could panic because it would close the channel twice. This commit prevents that as the interval defaults to 10m if not provided. If the goroutine waiting on the channel doesn't run within 10m, then we very likely have much worse problems at hand. Signed-off-by: Chris Tarazi <chris@isovalent.com> 22 October 2020, 16:33:58 UTC
44d7996 Chris Tarazi 21 October 2020, 19:05:19 UTC endpoint: Fix goroutine leak when EP is deleted [ upstream commit 6747a845542b38015917760d9905883170b5496c ] The metadata resolver controller can be put in a scenario where it can never succeed if the Cilium K8s pod cache is out-of-sync with the current view of pods in the cluster. The cache can be out-of-sync if there's heavy load on the cluster and especially on the apiserver. This leaves the Cilium pod cache starved. When the pod cache is starved, Cilium may never have an up-to-date view of the pods running in the cluster, and therefore may never be able to resolve labels for pods because the fetch will return "pod not found". Eventually, kubelet (or maybe even the user) will give up on the pod and remove it, thereby Cilium begins removing the endpoint. The controller is stopped, but the goroutine waiting on the `done` channel will never receive, hence the leak. This commit fixes the goroutine leak when the controller never succeeds and therefore, never closes the `done` channel. The fix is to add a `select` statement to also watch the endpoint's `aliveCtx` which is cancelled (and the context's `Done` channel is closed) when the endpoint is deleted. This commit was validated by forcing the metadata resolver to never find a pod (manually hardcode the wrong pod name), and ensuring that the `gops stack` output does not contain an entry like: ``` goroutine 1244259 [chan receive, 1434 minutes]: github.com/cilium/cilium/pkg/endpoint.(*Endpoint).RunMetadataResolver.func1(0xc0055d2a20, 0xc0049ff600, 0xc0055d2ae0, 0x5d) /go/src/github.com/cilium/cilium/pkg/endpoint/endpoint.go:1531 +0x34 created by github.com/cilium/cilium/pkg/endpoint.(*Endpoint).RunMetadataResolver /go/src/github.com/cilium/cilium/pkg/endpoint/endpoint.go:1530 +0x11e ``` Fixes: https://github.com/cilium/cilium/issues/13680 Signed-off-by: Chris Tarazi <chris@isovalent.com> 22 October 2020, 16:33:58 UTC
05b5cd3 André Martins 20 October 2020, 21:14:35 UTC k8s: update k8s libraries to 1.17.13 Also update k8s test versions to 1.17.13 Signed-off-by: André Martins <andre@cilium.io> 21 October 2020, 14:33:16 UTC
8603523 Chris Tarazi 15 October 2020, 23:28:03 UTC test: Clean up etcd-deployment after test Signed-off-by: Chris Tarazi <chris@isovalent.com> 20 October 2020, 08:46:34 UTC
7fa76d0 Chris Tarazi 16 October 2020, 17:14:41 UTC test: Refactor DatapathConfiguration etcd test This commit separates out the preamble of deploying etcd and reconfiguring Cilium to use it into a BeforeEach. This improves the readability of the test. Signed-off-by: Chris Tarazi <chris@isovalent.com> 20 October 2020, 08:46:34 UTC
f7f3913 Chris Tarazi 16 October 2020, 16:44:22 UTC test: Avoid reinstalling Cilium after test suite This commit removes an unnecessary step which installs Cilium after every Context block in this test suite. It is unnecessary because each Context will install Cilium and configure it accordingly. This will also speed up the test suite execution time. Signed-off-by: Chris Tarazi <chris@isovalent.com> 20 October 2020, 08:46:34 UTC
7eef9ed Thomas Graf 15 May 2020, 10:08:34 UTC test: Remove leftover etcd operator related code [ upstream commit 43a7bba3bf543eba6deebf35c57f63856f44f819 ] Signed-off-by: Thomas Graf <thomas@cilium.io> Signed-off-by: Chris Tarazi <chris@isovalent.com> 20 October 2020, 08:46:34 UTC
070c410 Thomas Graf 25 September 2020, 16:39:13 UTC test: Replace managed etcd test with etcd test [ upstream commit bf3a6c585ce05d83fc52224c602192d547d84302 ] [ Backporter's notes: The deployment manager code doesn't exist in v1.7, so that was omitted in this backport commit. The functional changes that the deployment manager provided were translated for the current code in v1.7. Also, "synchronizeK8sNodes" is not under the "config" Helm subchart in v1.7, but rather under "operator". ] The managed etcd feature is being deprecated soon. The test has been unreliable due to etcd operator not being able to bring up etcd clusters reliably. We want to ensure test coverage for the etcd backing though. Convert the managed etcd test to a more generic test which uses stateless etcd for a reliable outcome. Fixes: #11181 Signed-off-by: Thomas Graf <thomas@cilium.io> Signed-off-by: Chris Tarazi <chris@isovalent.com> 20 October 2020, 08:46:34 UTC
e1c9152 Sebastian Wicki 12 October 2020, 15:17:23 UTC identity: Fix nil pointer panic in LookupIdentityByID [ upstream commit 005291cf60e0c48d3968093091c090349e623955 ] Because the identity allocator is initialized asychronously via `InitIdentityAllocator`, the local identitiy allocator might not have been initialized yet when the lookup functions are called. This can cause nil pointer panics, as observed in #13479. Before b194612c004c3e69289286e9a35d337b2645fc50, this nil pointer panic could not occur in `LookupIdentityByID` as the function checked for `m.IdentityAllocator != nil` which also implies `m.localIdentities != nil`. This commit adds an explict check for `m.localIdentities` and fixes a potential data race by checking the initialization channels before accessing `m.localIdentities` or `m.IdentityAllocator`. Fixes: #13479 Fixes: b194612c004c ("identity: Avoid kvstore lookup for local identities") Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> Signed-off-by: Chris Tarazi <chris@isovalent.com> 20 October 2020, 08:33:56 UTC
ee1b3e3 Han Zhou 15 October 2020, 02:50:35 UTC service: Use initNextID in acquireLocalID() [ upstream commit b34e5d80ad6929e735e9486f1f38c77df99043cc ] When rolling over, it should use initNextID instead of FirstFreeServiceID, which doesn't belong to the IDAllocator. This would create problems if FirstFreeServiceID and FirstFreeBackendID have different values although now they happen to be the same. Fixes: ab9cf4ba4206 ("service: Make local ID allocator more service agnostic") Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Chris Tarazi <chris@isovalent.com> 20 October 2020, 08:33:56 UTC
1454ca3 Jaff Cheng 13 October 2020, 08:37:17 UTC bpf: only clean up XDP from devices with XDP attached [ upstream commit 8f0e7fad3aff07cf0b00528080fb42dffe15e1af ] [ Backporter's notes: Includes update to bpf.sha. ] Currently, during agent startup, cilium removes XDP from all interfaces except for `cilium_host`, `cilium_net` and `$XDP_DEV` regardless of whether there is an XDP program attached to it. For some drivers, e.g. Mellanox mlx5, the following command will cause device reset regardless of whether there is an XDP program attached to it, which introduces node and pod network interruption: `ip link set dev $DEV xdpdrv off`. This patch adds a check of XDP program existence to avoid such network interruption. Fixes: #13526 Reported-by: ArthurChiao <arthurchiao@hotmail.com> Signed-off-by: Jaff Cheng <jaff.cheng.sh@gmail.com> Signed-off-by: Chris Tarazi <chris@isovalent.com> 20 October 2020, 08:33:56 UTC
54fdd63 Daniel Borkmann 10 April 2020, 08:56:27 UTC bpf: clean up XDP from prior devices when cilium configuration changes [ upstream commit 1afb536cd61b5a817c472f761979fd08e0611ae9 ] Avoid having to leave around stale XDP programs when the config changes. Therefore do the same as we do in tc which is to clean up prior state. Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Chris Tarazi <chris@isovalent.com> 20 October 2020, 08:33:56 UTC
98210c4 Tobias Klauser 19 October 2020, 15:43:36 UTC contrib: match commit subject exactly when searching for upstream commit [ upstream commit 6557f7557ca7ef65f8097743d4fdb935967d686e ] In generate_commit_list_for_pr, the commit subject is used to determine the upstream commit ID from $REMOTE/master. However, if in the meantime another commit with e.g. a Fixes tag that mentions this commit subject, it appears first and leads to the original commit not being found. This can be demonstrated using #13383: ``` * PR: 13383 -- daemon: Enable configuration of iptables --random-fully (@kh34) -- https://github.com/cilium/cilium/pull/13383 Merge with 2 commit(s) merged at: Wed, 14 Oct 2020 11:41:51 +0200! Branch: master (!) refs/pull/13383/head ---------- ------------------- v (start) | Warning: No commit correlation found! via dbac86cffc6d57e8c093d2821e0d794f4c13d284 ("daemon: Enable configuration of iptables --random-fully") | 350f0b36fd9b4cf23ebc11f4365c5c89591d0ff4 via 22d4554e963e2d8029ff95087ac03e55e90a7377 ("test: Test iptables masquerading with --random-fully") v (end) $ # this is the git log command (with the subject added) from $ # contrib/backporting/check-stable that should extract a single $ # upstream commit $ git log -F --since="1year" --pretty="%H %s" --no-merges --grep "daemon: Enable configuration of iptables --random-fully" origin/master 078ec543d36a8f5d6caed5c4649c74c72090ae20 install/kubernetes: consistent case spelling of iptables related values 4e39def13bca568a21087238877fbc60f8751567 daemon: Enable configuration of iptables --random-fully $ git show 078ec543d36a8f5d6caed5c4649c74c72090ae20 commit 078ec543d36a8f5d6caed5c4649c74c72090ae20 Author: Tobias Klauser <tklauser@distanz.ch> Date: Wed Oct 14 11:58:29 2020 +0200 install/kubernetes: consistent case spelling of iptables related values Make the case spelling of the newly introduced "ipTablesRandomFully" value consistent with other iptables option values which use the "iptables" spelling. Fixes: 4e39def13bca ("daemon: Enable configuration of iptables --random-fully") Signed-off-by: Tobias Klauser <tklauser@distanz.ch> ``` Note the `Fixes: ...` line in commit 078ec543d36a8f5d6caed5c4649c74c72090ae20 above. Fix this behavior by grepping for the subject line from start of line: ``` $ git log -F --since="1year" --pretty="%H %s" --no-merges --extended-regexp --grep "^daemon: Enable configuration of iptables --random-fully" origin/master 4e39def13bca568a21087238877fbc60f8751567 daemon: Enable configuration of iptables --random-fully * PR: 13383 -- daemon: Enable configuration of iptables --random-fully (@kh34) -- https://github.com/cilium/cilium/pull/13383 Merge with 2 commit(s) merged at: Wed, 14 Oct 2020 11:41:51 +0200! Branch: master (!) refs/pull/13383/head ---------- ------------------- v (start) | 4e39def13bca568a21087238877fbc60f8751567 via dbac86cffc6d57e8c093d2821e0d794f4c13d284 ("daemon: Enable configuration of iptables --random-fully") | 350f0b36fd9b4cf23ebc11f4365c5c89591d0ff4 via 22d4554e963e2d8029ff95087ac03e55e90a7377 ("test: Test iptables masquerading with --random-fully") v (end) ``` Reported-by: Robin Hahling <robin.hahling@gw-computing.net> Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Nate Sweet <nathanjsweet@pm.me> 20 October 2020, 08:26:58 UTC
2e29740 Jarno Rajahalme 07 October 2020, 21:53:07 UTC docs: Fix TLS visibility GSG [ upstream commit 837caf8a649d11d879726415fc61d872b4def62e ] - Use k8s secret key name 'ca.crt' for 'ca-certificates.crt' so that the example CNP works - Change the example monitor output from lyft.com to artii.herokuapp.com - Add deletion of the secrets to clean-up - Fix indentation and white-spacing in enumerated lists so that they are rendered properly Signed-off-by: Jarno Rajahalme <jarno@covalent.io> Signed-off-by: Quentin Monnet <quentin@isovalent.com> 13 October 2020, 07:40:53 UTC
b79349f Maciej Kwiek 26 June 2020, 16:50:17 UTC test: fix escaping in l7 tls vis policy [ upstream commit 8ed026ada6b01bf06b05b3cb392c2210eabbbb71 ] Signed-off-by: Maciej Kwiek <maciej@isovalent.com> Signed-off-by: Quentin Monnet <quentin@isovalent.com> 13 October 2020, 07:40:53 UTC
da73428 Quentin Monnet 22 April 2020, 10:47:54 UTC docs, test: replace swapi by artii.herokuapp.com for TLS visibility [ upstream commit 92aa025e90127c8fb5d00bb832882783d2cca318 ] The STAR WARS API used as an example for TLS visibility documentation and tests is no longer maintained [0], and the website is down. Let's switch to something else instead: https://artii.herokuapp.com/, which turns arguments into ASCII art snippets. [0] https://github.com/phalt/swapi Signed-off-by: Quentin Monnet <quentin@isovalent.com> 13 October 2020, 07:40:53 UTC
fbe6d7d André Martins 08 October 2020, 18:43:33 UTC cilium.io/v2: fix CNP Deep Equal function [ upstream commit bafc8813f5b044bd396deefbfe50f6426d7024a5 ] An equal function should never modify its fields, by doing it so it might cause race conditions. [ Backport note: Change applied to pkg/k8s/factory_functions.go instead of pkg/k8s/apis/cilium.io/v2/cnp_types.go where the related code is located in v1.9. Also keep the check on reflect.deepEqual(...) added to the value returned by the function, as is the case in branch v1.7 (changed in v1.9 with commit c813a15 ("k8s: Explicitly embed CRD types into CCNP"). ] Fixes: 100d83c27535 ("k8s: ignore kubectl.kubernetes.io/last-applied-configuration annotation") Signed-off-by: André Martins <andre@cilium.io> Signed-off-by: Quentin Monnet <quentin@isovalent.com> 12 October 2020, 20:00:40 UTC
ff72ce1 André Martins 08 October 2020, 18:40:21 UTC pkg/comparator: add function to compare maps ignoring keys [ upstream commit 94ddcd35946007afb7cf8e513c50b7b2afa16b61 ] MapStringEqualsIgnoreKeys will be used to compare maps while ignoring certain keys. Signed-off-by: André Martins <andre@cilium.io> Signed-off-by: Quentin Monnet <quentin@isovalent.com> 12 October 2020, 20:00:40 UTC
55f0c5a Thomas Graf 07 October 2020, 13:35:10 UTC api-limiter: Add test covering cancelation of rate limiter [ upstream commit 269aa1b69786eed0649162bf319e10ebf5f4b601 ] Test that failing requests will not impact the rate limiter. This is already working correctly so this test only adds additional coverage. Signed-off-by: Thomas Graf <thomas@cilium.io> 09 October 2020, 07:22:43 UTC
61f2aa9 Thomas Graf 08 October 2020, 07:59:18 UTC api-limiter: Add stress test [ upstream commit 75159c64565c59175cdae7c127e0394fde148f19 ] Simulate stress by feeding many parallel requests through the API rate limiter. The maximum wait duration will soon be hit for requests causing them to fail. Without the fix, this test would often fail. If it succeeded, the number of retries is in the range of 60-80K. With the fix, the test succeeds consistently and retries are in the range of 6-8K. That's a 10x reduction of retries. Signed-off-by: Thomas Graf <thomas@cilium.io> 09 October 2020, 07:22:43 UTC
8019191 Thomas Graf 07 October 2020, 14:11:02 UTC api-limiter: Enforce ParallelRequests before applying rate limiting [ upstream commit 208c69ceddb127d811c7dc011c69bd51b14896e1 ] So far, the rate limiting has been enforced before enforcing parallel requests. In theory, this is better because we can return error code 429 earlier to tell callers to slow down. In practice, many callers will retry immediately anyway which means that all the limiting will happen by the rate limiter. The rate limiter relies on reservations that need to be canceled. If too many requests happen in parallel, reservations can't be canceled quickly enough. By swapping the enforcement of parallel requests with the rate limiter, all requests will block for at least MaxWaitDuration if more than the allowed number of parallel requests are pending which will naturally pace the callers. Swapping the enforcement order requires the acquired semaphore to be released in error cases of the rate limiter. This requires to change the structure of Wait() to have a single error handling structure. By reusing finishRequest(), the metrics handler has to be adjusted slightly to account for new outcomes as it now bumps the metric for canceled requests as well. What remains unchanged is that only successful API requests are used to calculate the mean processing duration. Fixes: 3141e6581e0 ("rate: Add API rate limiting system") Signed-off-by: Thomas Graf <thomas@cilium.io> 09 October 2020, 07:22:43 UTC
09fee20 Thomas Graf 07 October 2020, 13:44:13 UTC api-limiter: Fix duplicate log message [ upstream commit ecb2369afc1660ae19406a32168f1a838aa06554 ] The following log message was duplicated and printed twice for two different meanings. Fixes: 3141e6581e0 ("rate: Add API rate limiting system") Signed-off-by: Thomas Graf <thomas@cilium.io> 09 October 2020, 07:22:43 UTC
b462f52 Martynas Pumputis 05 October 2020, 13:07:43 UTC contexthelpers: Fix deadlock when nobody recvs on success channel [ upstream commit 4a66961b5ab8857d77bf1be13d56776049b2ca5f ] It has been observed that the "sessionSuccess <- true" statement can block forever. E.g. Cilium v1.7.9: goroutine 742 [chan send, 547 minutes]: github.com/cilium/cilium/pkg/kvstore.(*etcdClient).renewLockSession(0xc000f66000, 0x2790b40, 0xc000e247c0, 0x0, 0x0) /go/src/github.com/cilium/cilium/pkg/kvstore/etcd.go:657 +0x3e2 github.com/cilium/cilium/pkg/kvstore.connectEtcdClient.func6(0x2790b40, 0xc000e247c0, 0x3aae820, 0x2) /go/src/github.com/cilium/cilium/pkg/kvstore/etcd.go:819 +0x3e github.com/cilium/cilium/pkg/controller.(*Controller).runController(0xc000f42500) /go/src/github.com/cilium/cilium/pkg/controller/controller.go:205 +0xa2a created by github.com/cilium/cilium/pkg/controller.(*Manager).updateController /go/src/github.com/cilium/cilium/pkg/controller/manager.go:120 +0xb09 This can happen when the context cancellation timer fires after a function which consumes the context has returned, but before "sessionSuccess <- true" is executed. After the timeout, the receiving goroutine is closed, making the sending block forever. Fix this by making the sessionSuccess channel buffered. Note that after sending we don't check whether the context has been cancelled, as we expect that any subsequent functions which consume the context will check for the cancellation. Fixes: 02628547 ("etcd: Fix incorrect context usage in session renewal") Signed-off-by: Martynas Pumputis <m@lambda.lt> Signed-off-by: Quentin Monnet <quentin@isovalent.com> 07 October 2020, 16:38:01 UTC
b98f285 Quentin Monnet 06 October 2020, 10:38:34 UTC doc: document option --enable-api-rate-limit and default to disabled As a backported feature, API rate limiting is disabled by default and gated behind a dedicated option. Let's document it. Fixes: #13392 Signed-off-by: Quentin Monnet <quentin@isovalent.com> 06 October 2020, 19:23:03 UTC
30b59c1 Quentin Monnet 06 October 2020, 11:06:56 UTC install: re-generate quick-install to account for "enableAPIRateLimit" Following backport PR #13392 for API rate limiting, and the addition of a specific option for the agent and to the Helm chart, re-generate the quick-install.yaml file: make -C install/kubernetes Fixes: #13392 Signed-off-by: Quentin Monnet <quentin@isovalent.com> 06 October 2020, 19:23:03 UTC
58c92a0 Jarno Rajahalme 21 April 2020, 21:05:35 UTC vagrant: Only set K8S_NODE_NAME if K8S=1 [ upstream commit fff6d6c6b02d0d2aaa2d45edb1d370ce70f8cba1 ] Fixes: #11021 Signed-off-by: Jarno Rajahalme <jarno@covalent.io> Signed-off-by: Paul Chaignon <paul@cilium.io> 06 October 2020, 08:58:44 UTC
7e1c9a8 Alexandre Perrin 29 September 2020, 14:41:23 UTC fsnotify: correctly check for event operation [ upstream commit 28b4c96871df76c84c9afd2f91058b78d87f7c03 ] fsnotify Event.Op is a bit mask and testing for strict equality might not detect the event operation correctly. This patch make it so we check for fsnotify event operation consistently as documented at https://github.com/fsnotify/fsnotify. Signed-off-by: Alexandre Perrin <alex@kaworu.ch> Signed-off-by: Paul Chaignon <paul@cilium.io> 06 October 2020, 08:58:44 UTC
7d3c3a7 Joe Stringer 30 September 2020, 22:13:35 UTC contrib: Improve start-release.sh script [ upstream commit b71cf0d0fff4d17f788a01c55affd79715731d46 ] Due to an extra `v` in the branch name, this script would fail with: $ ~/git/cilium/contrib/release/start-release.sh v1.6.12 128 fatal: 'origin/vv1.6' is not a commit and a branch 'pr/prepare-v1.6.12' cannot be created from it Signal ERR caught! Traceback (line function script): 62 main /home/joe/git/cilium/contrib/release/start-release.sh Fix it. While we're at it, update the instructions at the end for next steps, since there's also now a `submit-backport.sh` script to send the PR from the CLI. Signed-off-by: Joe Stringer <joe@cilium.io> Signed-off-by: Paul Chaignon <paul@cilium.io> 06 October 2020, 08:58:44 UTC
fbf7d4a Gilberto Bertin 30 September 2020, 13:52:57 UTC bugtool: get bpffs mountpoint from /proc/self/mounts [ upstream commit 57d3473e7b8dff3181dd7b4394c6bd452ec60399 ] Rather then hardcoding the /sys/fs/bpf value in bugtool, use the `mountinfo` package (which exposes the information in /proc/self/mounts) to determine the correct mountpoint for the BPF filesystem. Fixes: #13218 Signed-off-by: Gilberto Bertin <gilberto@isovalent.com> Signed-off-by: Paul Chaignon <paul@cilium.io> 06 October 2020, 08:58:44 UTC
b976923 Thomas Graf 29 September 2020, 10:59:26 UTC doc: Document API rate limiting [ upstream commit d315ec3a4b26cd77d2edb4e2f4b79a148d42d246 ] [ Backporter's notes: `operations/metrics.rst doesn't exist in v1.7, it's `configuration/metrics.rst. Moved the upstream changes there to resolve conflicts. ] Signed-off-by: Thomas Graf <thomas@cilium.io> Signed-off-by: Chris Tarazi <chris@isovalent.com> 03 October 2020, 00:33:39 UTC
6bf7090 Chris Tarazi 02 October 2020, 21:34:01 UTC install: Add enableAPIRateLimit option Following the commit to add the flag to the agent, this commit adds it to the Helm chart. Note, that the api rate limiting itself is not configurable through the Helm chart. It must be done directly on the agent. Signed-off-by: Chris Tarazi <chris@isovalent.com> 03 October 2020, 00:33:39 UTC
550f925 Chris Tarazi 02 October 2020, 19:50:01 UTC agent, rate: Add option to control api rate limit This commit introduces `--enable-api-rate-limit` to enable the use of api rate limiting. Signed-off-by: Chris Tarazi <chris@isovalent.com> 03 October 2020, 00:33:39 UTC
8eb90e6 Thomas Graf 29 September 2020, 08:41:29 UTC agent: Add rate limiting to endpoint API calls [ upstream commit 6333eaac4d602cb65dc6a7544767399d40e81714 ] [ Backporter's notes: * v1.7 tree doesn't have `daemon/cmd`, so renamed upstream `daemon/cmd/api_limits.go` -> `daemon/api_limits.go`. This includes changing the file's package from cmd -> main. * Small conflict with parameters to `createEndpoint()` ] Add default rate limiting for all endpoint related API calls with automatic adjustment based on estimated processing duration. Metrics are provided to monitor the rate limiting system: ``` cilium_api_limiter_adjustment_factor api_call="endpoint-create" 0.695787 cilium_api_limiter_processed_requests_total api_call="endpoint-create" outcome="success" 7.000000 cilium_api_limiter_processing_duration_seconds api_call="endpoint-create" value="estimated" 2.000000 cilium_api_limiter_processing_duration_seconds api_call="endpoint-create" value="mean" 2.874443 cilium_api_limiter_rate_limit api_call="endpoint-create" value="burst" 4.000000 cilium_api_limiter_rate_limit api_call="endpoint-create" value="limit" 0.347894 cilium_api_limiter_requests_in_flight api_call="endpoint-create" value="in-flight" 0.000000 cilium_api_limiter_requests_in_flight api_call="endpoint-create" value="limit" 0.000000 cilium_api_limiter_wait_duration_seconds api_call="endpoint-create" value="max" 15.000000 cilium_api_limiter_wait_duration_seconds api_call="endpoint-create" value="mean" 0.000000 cilium_api_limiter_wait_duration_seconds api_call="endpoint-create" value="min" 0.000000 ``` Signed-off-by: Thomas Graf <thomas@cilium.io> Signed-off-by: Chris Tarazi <chris@isovalent.com> 03 October 2020, 00:33:39 UTC
489a24d Thomas Graf 29 September 2020, 08:22:20 UTC rate: Add API rate limiting system [ upstream commit 3141e6581e02a895d9f7ed93f77850cbc48b9b9d ] The API rate limiting system is capable to enforce both rate limiting and maximum parallel requests. Instead of enforcing static limits, the system is capable to automatically adjust rate limits and allowed parallel requests by comparing the provided estimated processing duration with the mean processing duration observed. Usage: ``` var requestLimiter = rate.NewAPILimiter("myRequest", rate.APILimiterParameters{ rate.SkipInitial: 5, rate.RateLimit: 1.0, // 1 request/s rate.ParallelRequests: 2, }, nil) func myRequestHandler() error { req, err := requestLimiter.Wait(context.Background()) if err != nil { // request timed out whie waiting return err } defer req.Done() // Signal that request has been processed // process request .... return nil } ``` Configuration parameters: - EstimatedProcessingDuration time.Duration EstimatedProcessingDuration is the estimated duration an API call will take. This value is used if AutoAdjust is enabled to automatically adjust rate limits to stay as close as possible to the estimated processing duration. - AutoAdjust bool AutoAdjust enables automatic adjustment of the values ParallelRequests, RateLimit, and RateBurst in order to keep the mean processing duration close to EstimatedProcessingDuration - MeanOver int MeanOver is the number of entries to keep in order to calculate the mean processing and wait duration - ParallelRequests int ParallelRequests is the parallel requests allowed. If AutoAdjust is enabled, the value will adjust automatically. - MaxParallelRequests int MaxParallelRequests is the maximum parallel requests allowed. If AutoAdjust is enabled, then the ParalelRequests will never grow above MaxParallelRequests. - MinParallelRequests int MinParallelRequests is the minimum parallel requests allowed. If AutoAdjust is enabled, then the ParallelRequests will never fall below MinParallelRequests. - RateLimit rate.Limit RateLimit is the initial number of API requests allowed per second. If AutoAdjust is enabled, the value will adjust automatically. - RateBurst int RateBurst is the initial allowed burst of API requests allowed. If AutoAdjust is enabled, the value will adjust automatically. - MinWaitDuration time.Duration MinWaitDuration is the minimum time an API request always has to wait before the Wait() function returns an error. - MaxWaitDuration time.Duration MaxWaitDuration is the maximum time an API request is allowed to wait before the Wait() function returns an error. - Log bool Log enables info logging of processed API requests. This should only be used for low frequency API calls. Example: ``` level="info" msg="Processing API request with rate limiter" maxWaitDuration=10ms name=foo parallelRequests=2 subsys=rate uuid=933267c5-01db-11eb-93bb-08002720ea43 level="info" msg="API call has been processed" name=foo processingDuration=10.020573ms subsys=rate totalDuration=10.047051ms uuid=933265c7-01db-11eb-93bb-08002720ea43 waitDurationTotal="18.665µs" level=warning msg="Not processing API request. Wait duration for maximum parallel requests exceeds maximum" maxWaitDuration=10ms maxWaitDurationParallel=10ms name=foo parallelRequests=2 subsys=rate uuid=933269d2-01db-11eb-93bb-08002720ea43 ``` - DelayedAdjustmentFactor float64 DelayedAdjustmentFactor is percentage of the AdjustmentFactor to be applied to RateBurst and MaxWaitDuration defined as a value between 0.0..1.0. This is used to steer a slower reaction of the RateBurst and ParallelRequests compared to RateLimit. - SkipInitial int SkipInitial is the number of API calls to skip before applying rate limiting. This is useful to define a learning phase in the beginning to allow for auto adjustment before imposing wait durations on API calls. - MaxAdjustmentFactor float64 MaxAdjustmentFactor is the maximum adjustment factor when AutoAdjust is enabled. Base values will not adjust more than by this factor. The configuration of API rate limiters is typically provided as-code to establish defaults. A string based configuration option can then be used to adjust defaults. This allows to expose configuration of rate limiting using a single option flag: ``` go l, err = NewAPILimiterSet(map[string]string{ "foo": "rate-limit:2/m,rate-burst:2", }, map[string]APILimiterParameters{ "foo": { RateLimit: rate.Limit(1.0 / 60.0), AutoAdjust: true, }, }, nil) ``` Signed-off-by: Thomas Graf <thomas@cilium.io> Signed-off-by: Chris Tarazi <chris@isovalent.com> 03 October 2020, 00:33:39 UTC
549868e Chris Tarazi 02 October 2020, 19:11:50 UTC vendor: Bump golang.org/x/time This commit bumps the package to v0.0.0-20191024005414-555d28b269f0, which brings in support for setting bursts. This is required for an upcoming commit for api rate limiting. Signed-off-by: Chris Tarazi <chris@isovalent.com> 03 October 2020, 00:33:39 UTC
faa658a Joe Stringer 30 September 2020, 22:37:33 UTC Prepare for release v1.7.10 Signed-off-by: Joe Stringer <joe@cilium.io> 30 September 2020, 23:05:17 UTC
2c3f4d7 Jarno Rajahalme 30 September 2020, 12:03:45 UTC envoy: Stop using deprecated filter names Stop using deprecated Envoy filter names in order to get rid of deprecation warning logs. Signed-off-by: Jarno Rajahalme <jarno@covalent.io> 30 September 2020, 17:38:45 UTC
863a98f Jarno Rajahalme 29 September 2020, 12:45:54 UTC Envoy: Update to release 1.14.5 [ upstream commit 3cf224e99523273d01835fb83876d92765c90b6b ] Signed-off-by: Jarno Rajahalme <jarno@covalent.io> Signed-off-by: Joe Stringer <joe@cilium.io> 30 September 2020, 17:38:45 UTC
0e9b244 Jarno Rajahalme 30 September 2020, 12:21:08 UTC envoy: Require Node only on the first request of a stream [ upstream commit 89f654d44351aa3fad671ee298f5beaadd2e5704 ] xDS request's Node field has grown huge and Envoy optionally only sends it in the first request. Use this option an adapt xDS stream processing accordingly. Partially also: [ upstream commit df0c9bbb1f3d25c1c1a534f66d28083e741354aa ] Signed-off-by: Jarno Rajahalme <jarno@covalent.io> 30 September 2020, 17:38:45 UTC
cd5c6c5 Chris Tarazi 23 September 2020, 22:44:08 UTC k8s: Remove CRD deleting functionality [ upstream commit 5c6aad6d5c78d80283c8d5b0238c180576ae1416 ] This commit removes the ability to delete CRDs from Cilium because that would delete all the CRs in the cluster. Follow-up from: https://github.com/cilium/cilium/pull/11477#discussion_r487816729 Updates: https://github.com/cilium/cilium/issues/12737 Signed-off-by: Chris Tarazi <chris@isovalent.com> Signed-off-by: Michal Rostecki <mrostecki@opensuse.org> 29 September 2020, 21:54:19 UTC
aa927f9 Quentin Monnet 10 September 2020, 15:43:14 UTC iptables: comment on xt_connmark requirement for EKS rules [ upstream commit 815be6aa8d1660b37fd33c492ec8db39b07f5d78 ] EKS requires some specific rules for asymmetric routing with multi-node NodePort traffic. These rules relies on the xt_connmark kernel module, which is usually loaded by iptables when necessary. The rules are installed when the selected IPAM is ENI, meaning they are installed on AWS (but not only EKS). The xt_connmark module should be loaded in a similar way, unless loading modules after boot has been disabled, in which case the setup fails and the agent crashes. Add a comment to at least help debug the issue. Longer term, we may want to add more explicit hints to the logs if too many users hit the issue, but that would require parsing iptables' output for the specific error, so let's see how it goes with a simple comment in the code for now. Signed-off-by: Quentin Monnet <quentin@isovalent.com> Signed-off-by: Michal Rostecki <mrostecki@opensuse.org> 29 September 2020, 21:54:19 UTC
a0d754b Quentin Monnet 10 September 2020, 20:37:43 UTC iptables, loader: use interface with default route for EKS rules [ upstream commit a301853023ef79b36649dc985e0e4b0d9db0edbe ] Multi-node NodePort traffic on EKS needs specific rules regarding asymmetric routing. These rules were implemented for the eth0 interface (namely), because this is what EKS uses. With the default Amazon Linux 2 distribution. But EKS can also run with Ubuntu for example, and the name of the interface is not the same in that case. Instead of "eth0", use the interface with the dafault route. This is a quick fix, and longer term we want to add the rules to all relevant interfaces, as discussed in #12770. Fixes: #12770 Fixes: #13143 Signed-off-by: Quentin Monnet <quentin@isovalent.com> Signed-off-by: Michal Rostecki <mrostecki@opensuse.org> 29 September 2020, 21:54:19 UTC
2a0308c Quentin Monnet 09 September 2020, 10:56:15 UTC iptables, loader: skip rules for EKS asymmetric routing if !IPv4 [ upstream commit 09e9a469f667b877bdcedbe4137d8919c7420aa5 ] EKS needs some specific rules for asymmetric routing with multi-node NodePort traffic. These rules are implemented only for IPv4, so we can avoid installing them when IPv4 is disabled. This is what this commit does. Note that this check is, in fact, not necessary at the moment, because as the config package says: "IPv6 cannot be enabled in ENI IPAM mode". So we always run with IPv4. But let's have it for good measure, to avoid issues if IPv6 support comes in the future. For the same reason, we also do not have to implement equivalent rules for IPv6 at the moment. Signed-off-by: Quentin Monnet <quentin@isovalent.com> Signed-off-by: Michal Rostecki <mrostecki@opensuse.org> 29 September 2020, 21:54:19 UTC
1c4c3c1 Quentin Monnet 09 September 2020, 09:24:34 UTC loader: move ENI rules for asymmetric routing to dedicated function [ upstream commit 01f8dcc51c84e1cab269f84e782e09d8261ac495 ] EKS needs some specific rules for NodePort traffic (see PR #12770, or comments in the code, for details). The addition of part of these rules were added to the body of the Reinitialize() function in the loader. To make them easier to maintain or extend, let's move them to a dedicated function called by Reinitialize(). No functional change. Signed-off-by: Quentin Monnet <quentin@isovalent.com> Signed-off-by: Michal Rostecki <mrostecki@opensuse.org> 29 September 2020, 21:54:19 UTC
de660c3 John Fastabend 21 September 2020, 01:45:19 UTC cilium: encrypt-node creates two IPsec tunnels but only uses one [ upstream commit 86858947d0e52d48c0b31fd496467b07bbed3c79 ] When we enable encrypt-node to encrypt all host traffic instead of just the pod traffic we setup two tunnels. The first tunnel is the typical one used in the case where encrypt-node is not set. This tunnel uses the cilium_host ip address range. The second tunnel uses the nodes IP per the encrypt-interface parameter or in the auto-discovered case the IP found after inspecting the route tables. On new kernels having duplicate entires in the 'ip xfrm policy' table that matches to multiple sates appears to be causing packets to be dropped. This was working on 4.19 kernels, but broke on upgrade to 5.4 kernels. We have not found the exact patch or fixed the regression. But, it is actually better/simpler to only have a single tunnel running in the encrypt-node case. This means fewer xfrm rules and is much easier to understand when only one rule can match a packet. Before this patch the xfrm policy/state looked like this with states and policies for both the 44.* xfrm tunnel and the 10.* xfrm tunnel. # ip x s src 0.0.0.0 dst 44.0.0.20 proto esp spi 0x00000003 reqid 1 mode tunnel replay-window 0 mark 0xd00/0xf00 output-mark 0xd00 aead rfc4106(gcm(aes)) 0xd0561beea6ab84e073edf1e76c49e9c0c6531d52 128 anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000 sel src 0.0.0.0/0 dst 0.0.0.0/0 src 0.0.0.0 dst 10.0.0.200 proto esp spi 0x00000003 reqid 1 mode tunnel replay-window 0 mark 0xd00/0xf00 output-mark 0xd00 aead rfc4106(gcm(aes)) 0xd0561beea6ab84e073edf1e76c49e9c0c6531d52 128 anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000 sel src 0.0.0.0/0 dst 0.0.0.0/0 src 44.0.0.20 dst 44.0.0.10 proto esp spi 0x00000003 reqid 1 mode tunnel replay-window 0 mark 0x3e00/0xff00 output-mark 0xe00 aead rfc4106(gcm(aes)) 0xd0561beea6ab84e073edf1e76c49e9c0c6531d52 128 anti-replay context: seq 0x0, oseq 0x25d, bitmap 0x00000000 sel src 0.0.0.0/0 dst 0.0.0.0/0 src 10.0.0.200 dst 10.0.1.135 proto esp spi 0x00000003 reqid 1 mode tunnel replay-window 0 mark 0x3e00/0xff00 output-mark 0xe00 aead rfc4106(gcm(aes)) 0xd0561beea6ab84e073edf1e76c49e9c0c6531d52 128 anti-replay context: seq 0x0, oseq 0x589, bitmap 0x00000000 sel src 0.0.0.0/0 dst 0.0.0.0/0 # ip x p src 0.0.0.0/0 dst 44.0.0.20/32 dir fwd priority 0 mark 0xd00/0xf00 tmpl src 0.0.0.0 dst 44.0.0.20 proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 44.0.0.20/32 dir in priority 0 mark 0xd00/0xf00 tmpl src 0.0.0.0 dst 44.0.0.20 proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 10.0.0.0/24 dir fwd priority 0 mark 0xd00/0xf00 tmpl src 0.0.0.0 dst 10.0.0.200 proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 10.0.0.0/24 dir in priority 0 mark 0xd00/0xf00 tmpl src 0.0.0.0 dst 10.0.0.200 proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 10.0.1.0/24 dir out priority 0 mark 0x3e00/0xff00 tmpl src 44.0.0.20 dst 44.0.0.10 proto esp spi 0x00000003 reqid 1 mode tunnel src 0.0.0.0/0 dst 44.0.0.10/32 dir out priority 0 mark 0x3e00/0xff00 tmpl src 44.0.0.20 dst 44.0.0.10 proto esp spi 0x00000003 reqid 1 mode tunnel src 10.0.0.0/24 dst 10.0.1.0/24 dir out priority 0 mark 0x3e00/0xff00 tmpl src 10.0.0.200 dst 10.0.1.135 proto esp spi 0x00000003 reqid 1 mode tunnel Now we get only the single 44* xfrm tunnel, # ip x s src 0.0.0.0 dst 44.0.0.20 proto esp spi 0x00000003 reqid 1 mode tunnel replay-window 0 mark 0xd00/0xf00 output-mark 0xd00 aead rfc4106(gcm(aes)) 0xd0561beea6ab84e073edf1e76c49e9c0c6531d52 128 anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000 sel src 0.0.0.0/0 dst 0.0.0.0/0 src 44.0.0.20 dst 44.0.0.10 proto esp spi 0x00000003 reqid 1 mode tunnel replay-window 0 mark 0x3e00/0xff00 output-mark 0xe00 aead rfc4106(gcm(aes)) 0xd0561beea6ab84e073edf1e76c49e9c0c6531d52 128 anti-replay context: seq 0x0, oseq 0x4423, bitmap 0x00000000 sel src 0.0.0.0/0 dst 0.0.0.0/0 # ip x p src 0.0.0.0/0 dst 44.0.0.20/32 dir fwd priority 0 mark 0xd00/0xf00 tmpl src 0.0.0.0 dst 44.0.0.20 proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 44.0.0.20/32 dir in priority 0 mark 0xd00/0xf00 tmpl src 0.0.0.0 dst 44.0.0.20 proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 10.0.1.0/24 dir out priority 0 mark 0x3e00/0xff00 tmpl src 44.0.0.20 dst 44.0.0.10 proto esp spi 0x00000003 reqid 1 mode tunnel src 0.0.0.0/0 dst 44.0.0.10/32 dir out priority 0 mark 0x3e00/0xff00 tmpl src 44.0.0.20 dst 44.0.0.10 proto esp spi 0x00000003 reqid 1 mode tunnel There are two key pieces here. First, pod traffic is encrypted by the policy with dst 10.0.1.0/24 which is the peer nodes pod IP ranges. If we had multiple nodes we would have multiple entries here. And then second, because we now encrypt always with the 44.* IP tunnel we can eliminate a set of state rules. Considering this is both cleaner and will work on all kernels regardless of fix for kernel regression lets use this for encrypt-node use cases instead. Signed-off-by: John Fastabend <john.fastabend@gmail.com> Signed-off-by: Michal Rostecki <mrostecki@opensuse.org> 29 September 2020, 21:54:19 UTC
fb10a31 Sebastian Wicki 21 September 2020, 08:44:32 UTC identity: Avoid kvstore lookup for local identities [ upstream commit f3424a3690b4aca315a7b5e9c40b5fa8ed270e36 ] Reserved and CIDR identities are local to the agent and not stored in the kvstore. This commit changes the identity cache to avoid performing a kvstore lookup for CIDR entries (which is currently done when a CIDR identity is released). This is a follow-up to https://github.com/cilium/cilium/pull/13205#discussion_r490306171 Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 29 September 2020, 21:31:11 UTC
4bae20d Deepesh Pathak 18 September 2020, 13:33:06 UTC operator: fix operator behaviour when kube-apiserver is down [ upstream commit 30835c7a69dc863076d24708ad004d8ccd1f9f7f ] * This commit fixes an issue in Cilium dev environment wherein if kube-apiserver is stopped then cilium-operator does not restarts after loosing leader election. This was happening because we were returning exit code 0 on loosing leader election. This was causing systemd to not restart cilium-operator as the case is not regarded as failure. This was working fine with Kubernetes deployment of operator as we have restart policy set to always for operator deployment. * One edge case is fixed where now we do an exit if an error is returned when updating K8s capabilities. Earlier this could lead to an inconsistent behaviour in the cluster as we can misinterpret capabilities if kube-apiserver was down. Fixes: df90c99905ad "operator: support HA mode for operator using k8s leaderelection library" Fixes #13185 Signed-off-by: Deepesh Pathak <deepshpathak@gmail.com> Signed-off-by: Michal Rostecki <mrostecki@opensuse.org> 24 September 2020, 09:28:31 UTC
b8d50d9 Alexandre Perrin 18 September 2020, 14:01:16 UTC doc: typo fix in gettingstarted clustermesh [ upstream commit e2a935d06fb0883e42d09bcbb0c65b9b8306771a ] Signed-off-by: Alexandre Perrin <alex@kaworu.ch> Signed-off-by: Michal Rostecki <mrostecki@opensuse.org> 24 September 2020, 09:28:31 UTC
153dccd Joe Stringer 17 September 2020, 20:09:29 UTC docs: Fix cilium-operator cmdref This was missed during an earlier backport, fix it up. Fixes: 8c23646845d1 ("operator: Encase CNP status handover in CLI option") Signed-off-by: Joe Stringer <joe@cilium.io> 18 September 2020, 08:43:05 UTC
3b91443 Sebastian Wicki 17 September 2020, 13:39:47 UTC identity: Perform identity lookup in remote kvstore caches too [ upstream commit 72f6685ddb0b69b312cca9652147c16484229f11 ] When looking up a security identity (either by its numeric id or by labels) in user-space (e.g. in Hubble or the API), we want to ensure to also include identities owned by remote clusters in cluster mesh too. Before this commit, `GetIdentities` function of the identity allocator (e.g. used for `cilium identity list`) would return all global identities (i.e. including the ones from remote clusters as well), while `LookupIdentity{,ByID}` would only return identities found the main kvstore, ignoring any indentities cached from remote kvstores. This fixes multiple missed annotations which can occur in cluster-mesh setups: - Hubble failed to annotate identities from remote clusters (#13076). - While the API would list remote identities in `/v1/identities`, performing a lookup on identities from remote clusters via API would fail with a "not found error". This 404 could be observed in `cilium identity get <remote-id>` or in `cilium bpf policy get`. - DNS proxy logrecords would not have the destination endpoint labels populated. - The `CiliumEndpoint.Status.Policy` CRD field would not contain labels for identities for remote clusters (if CEP status updates were enabled). Fixes: #13076 Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> Signed-off-by: Joe Stringer <joe@cilium.io> 18 September 2020, 08:43:05 UTC
2d56d0b Jarno Rajahalme 19 August 2020, 11:06:52 UTC endpoint: Update proxy policy after adding redirects [ upstream commit 407c4157e0eafd95316b1ba9b1f7ca2bf40bade5 ] Proxy policy must be updated after redirects have been added, as waiting for ACKs for the current version from the proxy is disabled when there are no redirects (yet). This leads to the Cilium API updating the realized policy too soon, and may lead to test flakes due to traffic being denied because policy has not been initialized yet. Found in local testing with dev VM proxy smoke test. Signed-off-by: Jarno Rajahalme <jarno@covalent.io> Signed-off-by: Joe Stringer <joe@cilium.io> 18 September 2020, 08:43:05 UTC
8fd63f5 Sebastian Wicki 16 September 2020, 13:25:46 UTC service: Add unit test for HealthCheckNodePort=false [ upstream commit 584318fb77ecb8d09137dcb2891a772cb970c1e2 ] [ Backporter's notes: pkg/service/service_test.go had a few conflicts: * v1.7 UpsertService() takes all parameters directly * GetServiceNameByAddr() doesn't exist * TestHealthCheckNodePort doesn't create a service with id2 Resolve by reworking the code against the v1.7 version to avoid backporting large refactoring commits. ] When HealthCheckNodePort is false, then the service health server will be nil. This commit adds a unit test to ensure that the code does not crash if the service health server is nil. Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> Signed-off-by: Joe Stringer <joe@cilium.io> 18 September 2020, 08:43:05 UTC
f8d9a68 Sebastian Wicki 16 September 2020, 13:21:30 UTC service: Fix panic when restoring services with enable-health-check-nodeport: false [ upstream commit ac2d4525c66785e55fa9b3fc5c142b680e494761 ] [ Backporter's notes: Minor conflict due to lack of backend filter. Dropped the backend filter check. ] We do not instanciate the service health server if HealthCheckNodePort support is disabled in our kube-proxy replacement. This means that we need to check the `EnableHealthCheckNodePort` flag before accessing the service health server to avoid a nil pointer panic. Fixes: edff374340cb ("agent: Add an option to cilium-agent for disabling 'HealthCheckNodePort'") Fixes: #13178 Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> Signed-off-by: Joe Stringer <joe@cilium.io> 18 September 2020, 08:43:05 UTC
b13324e Joe Stringer 01 July 2020, 23:06:05 UTC contrib: Add release helper scripts [ upstream commit 5388518ca5495d685ea5202694d2b7614f6063e8 ] [ Backporter's notes: Dropped docs, gh templates from commit ] Signed-off-by: Joe Stringer <joe@cilium.io> 18 September 2020, 08:43:05 UTC
42d51b9 Tobias Klauser 10 September 2020, 11:23:12 UTC operator: initialize gops in RootCmd Run func [ upstream commit 619294fef138d4b2e0071dbff088656b28724aaa ] [ Backporter's notes: Minor conflict due to no cmdref call in v1.7 version. ] This fixes an issue that `cilium-operator --help` exits with an error "unable to start gops..." instead of displaying the help message. This is similar to what commit 241c069d3f95 ("daemon/cmd: initialize gops in RootCmd execution function") did for the same problem in cilium-agent. Reported-by: André Martins <andre@cilium.io> Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Joe Stringer <joe@cilium.io> 18 September 2020, 08:43:05 UTC
b90af91 Tobias Klauser 10 September 2020, 11:20:12 UTC daemon, operator, test: log gops start failure to stderr instead of stdout [ upstream commit d570daaf06075d1d599bdbd061d22a3be7a08bbc ] Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Joe Stringer <joe@cilium.io> 18 September 2020, 08:43:05 UTC
c9a3abc chowmean 09 September 2020, 10:11:19 UTC changing operator ID and identity [ upstream commit 3d6cf1b1be6bfc1736ba5b09cedf82fd1765193e ] Signed-off-by: Gaurav Yadav <gaurav.dev.iiitm@gmail.com> Signed-off-by: Joe Stringer <joe@cilium.io> 18 September 2020, 08:43:05 UTC
bb0cd89 chowmean 08 September 2020, 20:30:28 UTC adding info message in log [ upstream commit 4c68f8adc22b71fb1869629c0d541ee097a058f4 ] Signed-off-by: Gaurav Yadav <gaurav.dev.iiitm@gmail.com> Signed-off-by: Joe Stringer <joe@cilium.io> 18 September 2020, 08:43:05 UTC
0fbbfd9 chowmean 08 September 2020, 19:25:44 UTC adding logs in strcutured way [ upstream commit b10fd49501a88cf197907989cfd579863417bd75 ] Signed-off-by: Gaurav Yadav <gaurav.dev.iiitm@gmail.com> Signed-off-by: Joe Stringer <joe@cilium.io> 18 September 2020, 08:43:05 UTC
558a01b Deepesh Pathak 26 July 2020, 09:10:46 UTC daemon/cmd: initialize gops in RootCmd execution function [ upstream commit 241c069d3f951bd52c29ec85ebeedd49ce3203b7 ] [ Backporter's notes: Minor conflict due to cmdref generation not being present in daemon on v1.7.x. ] This commit fixes a bug introduced in 299629d932d8 wherein `cilium-agent --help` exits with an error(unable to start gops..). This happens because the user started the cilium-agent process with root privileges which created the directory `/home/vagrant/.config/gops` with the user root. Any further attempt to run cilium-agent without root privileges will print out this error. The commit fixes running commands like `cilium-agent --help` `cilium-agent --cmdref <dir>` without root priviliges by moving gops initialization to a later stage in the agent. Fixes: 299629d932d8 "daemon: open socket in agent for gops stack traces" Signed-off-by: Deepesh Pathak <deepshpathak@gmail.com> Signed-off-by: Joe Stringer <joe@cilium.io> 18 September 2020, 08:43:05 UTC
c22283b André Martins 17 September 2020, 09:19:59 UTC test: update k8s test versions to 1.16.15 and 1.17.12 Also update Kubernetes libraries to 1.17.12 Signed-off-by: André Martins <andre@cilium.io> 17 September 2020, 20:01:15 UTC
8c23646 André Martins 10 September 2020, 02:29:38 UTC operator: Encase CNP status handover in CLI option [ upstream commit d1c6a750dabe799fad6bbdc70218d8ab4351c083 ] The code for handling CNP status updates from other nodes via the kvstore was previously not covered by the same option that enables this functionality in the cilium-agent daemon. As such, this could cause the logic to run, including goroutines for each CNP, in scenarios where this logic is not in use. Improve memory usage by disabling this functionality when it is disabled. Co-authored-by: Joe Stringer <joe@cilium.io> Signed-off-by: Joe Stringer <joe@cilium.io> Signed-off-by: André Martins <andre@cilium.io> 10 September 2020, 21:30:45 UTC
84b9b2d Deepesh Pathak 03 September 2020, 11:04:50 UTC docs: add wildcard from endpoints clusterwide policy example [ upstream commit 2231af01774bdf0399f6a409d8d466c4339df87f ] Signed-off-by: Deepesh Pathak <deepshpathak@gmail.com> 10 September 2020, 05:58:12 UTC
0534d97 Deepesh Pathak 20 August 2020, 10:06:26 UTC cilium/preflight: add check for empty to/fromEndpoint in CCNP validation [ upstream commit 91a6fc482e9b1e815de1ebe4bbb995de87de0078 ] * This commit extends the cilium preflight validate-cnp check. When validating CCNP it checks if there is an empty to/from endpoint selector in the rules and warns about the problem and a possible fix. * This is to help users with upgrade scenarios when using Cilium. For a more detailed discussion on the probelm see issue - https://github.com/cilium/cilium/issues/12844 Signed-off-by: Deepesh Pathak <deepshpathak@gmail.com> 10 September 2020, 05:58:12 UTC
c5afae6 Deepesh Pathak 20 August 2020, 06:49:31 UTC pkg/k8s: add unit tests for empty to/fromEndpoint with ccnp [ upstream commit abe5e24849a9a81767ee675a7a179f12e10d3793 ] Signed-off-by: Deepesh Pathak <deepshpathak@gmail.com> 10 September 2020, 05:58:12 UTC
7d9905c Deepesh Pathak 18 August 2020, 11:40:57 UTC pkg/policy: fix endpoint selection for wildcard to/fromEndpoint in CCNP [ upstream commit 905b8d41d09caa387e8a54f041d02d2b47ade968 ] * This commit fixes an issue in endpoint selection when we provide wildcard for to/fromEndpoint in CCNP. When a wildcard is provided in CCNP fromEndpoint selector we end up with a truly empty endpoint selector. This results in allowing all traffic. The commit restricts this to only include endpoints that are managed by cilium by checking the presence of namespace label in endpoint. * For a more detailed explaination of the approach and the issue take a look at discussion following this github comment - https://github.com/cilium/cilium/pull/12890#issuecomment-674358012 Signed-off-by: Deepesh Pathak <deepshpathak@gmail.com> 10 September 2020, 05:58:12 UTC
3236442 Paul Chaignon 04 September 2020, 20:31:36 UTC test: Detect missed tail calls on upgrade/downgrade test [ upstream commit e9b3844f57fc13a870d113a568153867d4c4c464 ] Connectivity disruptions caused by missed tail calls were recently reported at #13015. It was caused by an incorrect handling of a call map rename. We didn't detect it because we don't have code to specifically detect missed tail calls during the upgrade/downgrade test; the test only fails if the connectivity is broken during a long enough period. This commit adds a new function to retrieve the sum of 'Missed tail calls' metrics across all Cilium pods. It is then used in the test after both the upgrade and the subsequent downgrade to check that no drops due to missed tail calls happened. This new test was tested by: - backporting to v1.8 and checking that missed tail calls are indeed detected. - backporting the fixes on the v1.7 (#13052) and v1.8 (#13051) branches and checking that no more tail calls were detected. We need to wait for both #13052 and #13051 to be merged and backported before we can backport this test to v1.7 and v1.8, as it will otherwise fail. Related: #13015, #13051, #13052 Signed-off-by: Paul Chaignon <paul@cilium.io> Signed-off-by: Deepesh Pathak <deepshpathak@gmail.com> 10 September 2020, 05:58:12 UTC
b513e35 Deepesh Pathak 20 August 2020, 11:54:53 UTC policy/api: update toServices docs to include current support status [ upstream commit 09b3df13a5f3e7232075bff6b33fd3b885726301 ] Signed-off-by: Deepesh Pathak <deepshpathak@gmail.com> 10 September 2020, 05:58:12 UTC
e43cf00 Deepesh Pathak 20 August 2020, 11:41:26 UTC policy/groups: add unit tests for CCNP toGroups derivative policies [ upstream commit ff997740c46443bd6a6cc17365878ce42554c6cd ] Signed-off-by: Deepesh Pathak <deepshpathak@gmail.com> 10 September 2020, 05:58:12 UTC
9dfa1b1 Deepesh Pathak 17 August 2020, 11:22:16 UTC pkg/policy: fix toGroups derivative policy for clusterwide policies [ upstream commit 5519f2bab286143670cf985aa7046c492d77be94 ] * This commit fixes an inherent issue with CCNP where if toGroups is specified in the Clusterwide policies it has no effect in creating a derived policy. The reason being we handle CCNP similar to CNP as they both are converted into SlimCNPs and processed in a similar way. For CCNP, creation of derived policy fails as we try to update status as CNP which is not possible. * This commit introduces a fix by checking the namespace field in the converted SlimCNP and handling cases of CCNP in a different manner suited for the required type. Signed-off-by: Deepesh Pathak <deepshpathak@gmail.com> 10 September 2020, 05:58:12 UTC
08a4294 Paul Chaignon 02 September 2020, 20:33:46 UTC daemon: Fix handling of policy call map on downgrades The name of the policy call map on the bpffs was changed between 1.7 and 1.8 by commit 5d6b669. Commit 6bada02 then added code to delete the old map name on initialization of the agent. We cannot simply delete the old policy call map because it might still be used by endpoints (until they are regenerated) and the base programs (until they are reloaded). However, if we rename the map in the bpffs, it shouldn't affect BPF programs that are using it and they will then pick up the new name on reload. The reverse renaming operation is needed in 1.7 to allow for downgrades from 1.8. Fixes: 5d6b669 ("maps/policymap: Rename policy call map to clarify intent") Fixes: 6bada02 ("daemon: Remove old policy call map") Signed-off-by: Paul Chaignon <paul@cilium.io> 07 September 2020, 17:56:36 UTC
8c62494 Ole Markus With 14 August 2020, 08:05:22 UTC Update kops installation documentation [ upstream commit 06dbc52d6edb6a0d2f24b150e96c513f5815ae0e ] Removes references to things like CoreOS and old etcd versions. Also added some further reading links for those who want to configure cilium on kops further. Signed-off-by: Ole Markus With <o.with@sportradar.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> 04 September 2020, 21:31:46 UTC
ea83d37 Ilya Dmitrichenko 16 March 2020, 13:22:10 UTC docs: Cosmetic format fix [ upstream commit beb401bf019839f6aba0d6abfdfab6bb22320d7d ] Signed-off-by: Ilya Dmitrichenko <errordeveloper@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> 04 September 2020, 21:31:46 UTC
20b1ced Ilya Dmitrichenko 16 March 2020, 13:20:07 UTC docs: Fix inconsisten title formats [ upstream commit 5d9139f014ff5230df726e7044c2c12fffe189e6 ] Signed-off-by: Ilya Dmitrichenko <errordeveloper@gmail.com> Signed-off-by: Paul Chaignon <paul@cilium.io> 04 September 2020, 21:31:46 UTC
9a3bd9c Ilya Dmitrichenko 13 March 2020, 15:57:24 UTC docs: Replace references to old demo app [ upstream commit e166ae0d417fcfd01c2df01ad3f501ea0dfa5f84 ] Signed-off-by: Ilya Dmitrichenko <errordeveloper@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> 04 September 2020, 21:31:46 UTC
3ece8b8 Paul Chaignon 28 August 2020, 06:47:27 UTC test: Fix GuestBook test [ upstream commit 8aba1c195ec96f8696ef354c65874be8e6b7d088 ] ae9e4be updated the GuestBook images and labels, but failed to make the same label update in the test itself. Thus, since then, we have not been running any connectivity check in the GuestBook test. That went unnoticed because we didn't check that the set of pods returned (from which we run connectivity checks) was not empty. This commit fixes it by: 1. Updating the label in the test itself to app=guestbook. 2. Adding a check that the set of pods selected isn't empty. However, the nc utility we were using to check connectivity from the frontend pods to the Redis backend isn't available in the new images. Therefore, we also need to: 3. Use curl instead inside the frontend pods to check that the PHP frontend works as expected and is able to contact the Redis backend. That's it? No. Turns out some of the pod labels and names have also been hardcoded in the Docker images and have been updated (mostly to use more neutral terms). 4. Update the YAML file to better match [1]. We however can't update the 'redis-master' name because our v6 frontend image has it hardcoded. The v5 frontend image at [1] has 'redis-leader' as the name, but somehow not the v6. We want to use the v6 image because it is a lot bigger (cf. dffb450fe7). 5. And finally, Bob's our uncle! 1 - https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook Fixes: #12994 Fixes: ae9e4be ("test: replace guestbook test docker image") Signed-off-by: Paul Chaignon <paul@cilium.io> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> 04 September 2020, 21:31:46 UTC
e7ae390 Joe Stringer 02 September 2020, 01:39:45 UTC Prepare for release v1.7.9 Signed-off-by: Joe Stringer <joe@cilium.io> 02 September 2020, 03:24:30 UTC
957c4c5 André Martins 20 August 2020, 16:27:07 UTC pkg/kvstore: set endpoint shuffle in etcd client connectivity [ upstream commit 642a2e1f516bb2ba423cde4c083668c89b757533 ] The endpoint shuffle was happening before loading the etcd configuration. To have the endpoints shuffled we should do it after loading the configuration from disk. Fixes: b95650b30b46 ("etcd: Shuffle list of etcd endpoints") Signed-off-by: André Martins <andre@cilium.io> Signed-off-by: Joe Stringer <joe@cilium.io> 02 September 2020, 01:33:44 UTC
5e82934 Paul Chaignon 28 August 2020, 13:11:10 UTC docs: Mention L7 limitation in Calico chaining GSG [ upstream commit 40a30cfc928833d5227f7c2097503999ce58b612 ] Several users have reported issues with L7 policies when running Cilium in chaining configuration on top of Calico. The long-term solution to this issue is well known (BPF TPROXY), but we should add a note to the documentation in the meantime to warn users. Signed-off-by: Paul Chaignon <paul@cilium.io> Signed-off-by: Joe Stringer <joe@cilium.io> 02 September 2020, 01:33:44 UTC
9ee7668 Joe Stringer 01 September 2020, 18:11:30 UTC daemon: Add --transmit-host-src option By default to facilitate smooth upgrade from v1.7.x to v1.7.y with --enable-remote-node-identity=false, this option ensures that v1.7.9 or later will transmit traffic from the local node towards other nodes with the "remote-node" identity, as v1.7.7 or earlier did. This flag is the third in a trifecta of flags used to control how traffic is transmitted and received between Cilium nodes: * --allow-host-src: Allows traffic from nodes that report the traffic as from the host identity, such as v1.6.x or earlier. * --transmit-host-src: Sends traffic towards other nodes with the source identity host, to ensure that 1.6.x nodes will accept traffic from this node during transition. * --enable-remote-node-identity: Treat network policy that allows from host identity to also allow from remote-node identity. When performing an upgrade from v1.6.x to v1.7.x, the following steps should be taken to prevent datapath outage: * Upgrade to Cilium v1.7.x with --transmit-host-src=true, --allow-host-src=true and --enable-remote-node-identity=false. This ensures that traffic from v1.6.x with source identity host will be accepted by v1.7.x nodes; v1.7.x nodes will transmit with source identity host so that v1.6.x nodes will accept the traffic; and that no network policy change is required to support this transition. * Reconfigure Cilium v1.7.x to disable --transmit-host-src. Traffic will still be accepted from other v1.7.x nodes if sent from the host identity, but after this configuration step all nodes will transmit the remote-node identity. * Reconfigure Cilium v1.7.x to disable --allow-host-src. After the previous step, no node should be transmitting the source identity so there is no need to accept traffic from remote nodes with this src. * Adapt network policy to ensure that traffic from remote nodes is explicitly allowed in the policy, eg via "fromEntities" policy that matches on the remote-node identity. * Finally, configure --enable-remote-node-identity=true. This will mean that traffic from remote nodes is not automatically allowed unless explicitly declared in the policy from the previous step. Signed-off-by: Joe Stringer <joe@cilium.io> 02 September 2020, 01:32:05 UTC
1749f6c Joe Stringer 01 September 2020, 18:03:57 UTC daemon: Default --allow-host-src to false If the user specifies --enable-remote-node-identity=false, previously we would default --allow-host-src to true, which had the side effect of also transmitting using the source identity "host". In this mode, during upgrade from v1.7.7 to v1.7.8, as new v1.7.8 nodes came online and began to packets to v1.7.7 nodes with source identity "host", the v1.7.7 nodes would drop the traffic. Remove this behaviour to fix v1.7.7 upgrades to v1.7.9. Signed-off-by: Joe Stringer <joe@cilium.io> 02 September 2020, 01:32:05 UTC
d7ca75c Thomas Graf 01 September 2020, 22:12:23 UTC doc: Document seamless upgrade process for remote-node identity change The upgrade instructions have been incomplete and did not allow for a seamless upgrade from 1.6.x to 1.7.0. Signed-off-by: Thomas Graf <thomas@cilium.io> 02 September 2020, 00:36:08 UTC
b5bc930 Joe Stringer 28 August 2020, 20:24:16 UTC Prepare for release v1.7.8 Signed-off-by: Joe Stringer <joe@cilium.io> 28 August 2020, 20:34:55 UTC
8d9e532 Joe Stringer 28 August 2020, 00:29:55 UTC daemon: Add hidden allow-remote-src flag This flag allows to override the default setting for whether to accept traffic into a node if the source node reports the source identity as "host". Default is "auto" - to allow if enableRemoteNodeIdentity is disabled; deny if enableRemoteNodeIdentity is enabled. If specified directly, it will take on the configured behaviour (allow such traffic if true, otherwise drop it). Signed-off-by: Joe Stringer <joe@cilium.io> 28 August 2020, 20:10:47 UTC
830f9cd Joe Stringer 28 August 2020, 00:22:39 UTC bpf: Allow from host with remote-node-identity=false According to the documentation: One can set enable-remote-node-identity=false in the ConfigMap to retain the Cilium 1.6.x behavior. The above is true when evaluating policy, but not true from the DROP_INVALID_IDENTITY perspective as during an upgrade from v1.6 to v1.7, v1.6 nodes may send traffic to v1.7 nodes with the "host" identity and the v1.7 nodes will drop such traffic with this error code. Mitigate this by also covering this datapath case with the `EnableRemoteNodeIdentity` flag check. Signed-off-by: Joe Stringer <joe@cilium.io> 28 August 2020, 20:10:47 UTC
f3e57e4 Quentin Monnet 04 August 2020, 14:52:25 UTC iptables, loader: add rules to ensure symmetric routing for AWS ENI traffic [ upstream commit 132088c996a59e64d8f848c88f3c0c93a654290c ] Multi-node NodePort traffic with AWS ENI needs a set of specific rules that are usually set by the AWS DaemonSet: # sysctl -w net.ipv4.conf.eth0.rp_filter=2 # iptables -t mangle -A PREROUTING -i eth0 -m comment --comment "AWS, primary ENI" -m addrtype --dst-type LOCAL --limit-iface-in -j CONNMARK --set-xmark 0x80/0x80 # iptables -t mangle -A PREROUTING -i eni+ -m comment --comment "AWS, primary ENI" -j CONNMARK --restore-mark --nfmask 0x80 --ctmask 0x80 # ip rule add fwmark 0x80/0x80 lookup main These rules mark packets coming from another node through eth0, and restore the mark on the return path to force a lookup into the main routing table. Without them, the "ip rules" set by the cilium-cni plugin tell the host to lookup into the table related to the VPC for which the CIDR used by the endpoint has been configured. We want to reproduce equivalent rules to ensure correct routing, or multi-node NodePort traffic will not be routed correctly. This could be observed with the pod-to-b-multi-node-nodeport pod from connectivity check never getting ready. This commit makes the loader and iptables module create the relevant rules when ENI is in use. The rules are nearly identical to those from the aws daemonset (different comments, different interface prefix for conntrack return path, explicit preference for ip rule): # sysctl -w net.ipv4.conf.<egressMasqueradeInterfaces>.rp_filter=2 # iptables -t mangle -A PREROUTING -i <egressMasqueradeInterfaces> -m comment --comment "cilium: primary ENI" -m addrtype --dst-type LOCAL --limit-iface-in -j CONNMARK --set-xmark 0x80/0x80 # iptables -t mangle -A PREROUTING -i lxc+ -m comment --comment "cilium: primary ENI" -j CONNMARK --restore-mark --nfmask 0x80 --ctmask 0x80 # ip rule add fwmark 0x80/0x80 lookup main pref 109 Fixes: #12098 Signed-off-by: Quentin Monnet <quentin@isovalent.com> Signed-off-by: Thomas Graf <thomas@cilium.io> Signed-off-by: John Fastabend <john.fastabend@gmail.com> 28 August 2020, 20:09:06 UTC
1819921 Kornilios Kourtis 27 August 2020, 14:06:53 UTC daemon: properly maintain node lists on updates [ upstream commit 5550c0f3f2206d05f3ef3af569ab756cbba94fae ] NodeAdd and NodeUpdate update the node state for clients so that they can return the changes when client requests so. If a node was added and then updated, its old and new version would be on the added list and its old on the removed list. Instead, we can just update the node on the added list. Note that the setNodes() function on pkg/health/server/prober.go first deletes the removed nodes and then adds the new ones, which means that the old version of the node would be added and remain as stale on the health server. This was found during investigation of issues with inconsistent health reports when nodes are added/removed from the cluster (e.g., #11532), and it seems to fix inconsistencies observed a small-scale test I did to reproduce the issue. Signed-off-by: Kornilios Kourtis <kornilios@isovalent.com> Signed-off-by: Alexandre Perrin <alex@kaworu.ch> 28 August 2020, 18:26:15 UTC
back to top