Repository navigation
Conversation
![kubernetes-prow[bot]](https://github.githubassets.com/images/gravatars/gravatar-user-420.png){kind=avatar}
nodeup: publish and prefer an xz-compressed binary
Signed-off-by: Moshe Vayner <moshe@vayner.me>
chore(channels): bump k8s and ubuntu ami versions in alpha channel
Adds AWSBinariesLocation and GCEBinariesLocation to CloudConfiguration in v1alpha2 and wires up conversions so that BinariesLocation does not get dropped when the cluster spec is written to the state store as v1alpha2.
Avoid client-side throttle bootstrap node lookups
Signed-off-by: Ciprian Hacman <ciprian@hakman.dev>
Remove support for Kopeio networking
…ider Signed-off-by: Moshe Vayner <moshe@vayner.me>
feat(akamai): add default network CIDR and test for Linode cloud provider
…ation Signed-off-by: Moshe Vayner <moshe@vayner.me>
…port feat(akamai): add Akamai (Linode) support to kOps controller configuration
…s length and character restrictions Right now a relatively longer cluster name such as `kops.linode.example.com` fails with: ``` W0824 13:25:09.744461 64892 executor.go:142] error running task "Volume/d.etcd-main.kops.linode.example.com" (9m58s remaining to succeed): error creating Akamai (Linode) volume "d.etcd-main.kops.linode.example.com": [400] [label] Must only use ascii letters, numbers, underscores, and dashes; [label] Length must be 1-32 characters ``` So adding a logic to limit the label length for volumes by invoking the `NormalizeLinodeLabel` function and truncating the returned result to 32 chars max. Signed-off-by: Moshe Vayner <moshe@vayner.me>
fix(akamai): normalize volume labels to comply with Akamai Cloud API's length and character restrictions
Signed-off-by: Moshe Vayner <moshe@vayner.me>
Adds file hashes for v1.34.11, v1.35.8 and v1.36.4. Signed-off-by: Ciprian Hacman <ciprian@hakman.dev>
Promotes #18738: Kubernetes 1.34.11/1.35.8/1.36.4 and the Ubuntu 22.04 AMI bump to serial 20260731. Signed-off-by: Ciprian Hacman <ciprian@hakman.dev>
chore(channels): promote alpha to stable
Neither is referenced by a Makefile target, a GitHub Actions workflow, or a Prow presubmit job. go_install_from_commit.sh additionally uses the pre-modules "go get -d", so it would fail if anything did call it. The cfn-lint Dockerfile pins an old Python base image and its .cfnlintrc.yaml has no consumer.
verify-gofumpt.sh and update-gofumpt.sh are not referenced by any Makefile target, GitHub Actions workflow, or Prow presubmit job, so gofumpt has not run in CI or in "make verify" for some time. Having gone unrun, the two scripts had also drifted apart: the verify script installed a much newer gofumpt than the update script, so applying the formatting locally would not have produced what the verify script checked. No go.mod change is needed. gofumpt remains an indirect dependency of golangci-lint in hack/go.mod.
generate_cni_hashes truncates its output file with "cat >" before appending each version, so calling it twice with the same arguments regenerated identical content. Removing the second call leaves pkg/assets/assetdata/cni-1.3.yaml unchanged.
bazel was removed from the repo; only go mod is needed to run "make gomod".
CODEGEN_VERSION pins k8s.io/code-generator, which had drifted well behind the k8s.io/* libraries in go.mod. Nothing fails when it drifts, because the generators are fetched over the network with "go run ...@$(CODEGEN_VERSION)" rather than resolved through go.mod, so make gomod cannot see it. Bump it to the version the staging libraries are on, and keep it there when they move.
The ko version was a separate literal in the Makefile, in hack/dev-push-kops-controller.sh, and in discovery/dev/tasks/deploy-to-k8s, so bumping it meant finding all three. Make the Makefile the source of truth and have the two scripts read it back out, following the existing idiom of grepping a file for a version string that the Makefile already uses for KOPS_CI_VERSION.
The run.go setting had fallen a minor behind the go directive in go.mod. It was not held back by a golangci-lint compatibility constraint: the pinned golangci-lint accepts 1.26 and reports no new issues, so this was just drift.
Both protobuf targets ran goimports@latest, so their output depended on whichever goimports happened to be current rather than the one the rest of the repo formats with. Run it out of the hack module instead, which is where goimports is already pinned for make goimports and verify-goimports.
Both scenarios installed the ginkgo CLI with @latest before cloning the upstream repo whose tests they then run. The CLI version was therefore unrelated to the ginkgo library those tests compile against, and could skew from it whenever upstream ginkgo released. Move the install after the clone and drop @latest so it resolves from the cloned repo's go.mod, which is the version its tests are built against. This also tracks automatically as the deployed driver version moves, matching how these scripts already derive the branch to clone from the running cluster.
tools/metal/storage/go.mod declared the same module path as tools/metal/dhcp, so the storage module's own packages under pkg/ were imported through a path that names the dhcp tool. tools/metal/dhcp contains only main.go and has no pkg/ of its own, so the imports resolved within the storage module and nothing broke, but the two modules would collide as soon as either imported the other. Name the module after its directory and update its internal imports to match. Verified with GOOS=linux go build ./... and go vet ./... in both modules. Building for darwin fails on an unrelated pre-existing syscall.Stat_t.Ctim reference in fsobjectstore.go; this tool targets Linux.
Test, vet, and lint nested Go modules in CI
…llback kubetest2: Give AWS e2e bastions instance-type fallbacks
scalability: capture kubelet heap profiles after the test
tests/e2e/scalability: configure watch progress notify interval for scale clusters
Bumps [actions/upload-artifact](https://github.com/actions/upload-artifact) from 7.0.1 to 7.0.2. - [Release notes](https://github.com/actions/upload-artifact/releases) - [Commits](actions/upload-artifact@043fb46...cf430e0) --- updated-dependencies: - dependency-name: actions/upload-artifact dependency-version: 7.0.2 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
…ctions/upload-artifact-7.0.2 build(deps): bump actions/upload-artifact from 7.0.1 to 7.0.2
Move olemarkus and zetaab to emeritus approvers
Signed-off-by: Ciprian Hacman <ciprian@hakman.dev>
Add moshevayner as reviewer
tests/e2e: add agent-sandbox benchmark scenario
kops update cluster --instance-group-roles and the first step of kops reconcile cluster build the model from only the instance groups being updated. The IAM builder used that list to decide whether a role needs the warm pool lifecycle hook permissions, so updating only the control plane removed them from the nodes and new warm pool instances were terminated. Use all instance groups instead. Also add a test harness that runs an update of only some instance groups of an integration test cluster and checks its terraform output against the expected output of the full update.
aws: Keep warm pool permissions when updating only the control plane
…groups Where the API load balancer was placed depended on the instance groups being updated: - On Azure, an internal load balancer goes in the subnet of the control plane, so updating only the nodes failed with "no suitable subnets found". - On Hetzner, the load balancer goes in the location of the first instance group, so updating only instance groups in another location moved it, and an update that matched no instance groups crashed. These now use all instance groups. On AWS, the same list of control plane instance groups is used to prefer their subnets for the API and bastion load balancers.
Every GCE cluster with an API load balancer also has an internal one, and it was built only from the instance groups being updated. Updating only the nodes tried to remove the control plane from its backend service, which fails because kOps can't change an existing backend service, and left out its forwarding rules and addresses. On clusters with dns: none, the boot configuration of the nodes then also lacked the address of the API server. The load balancer is now built from all instance groups. Its backend services refer to the managed instance groups of the instance groups that are not being updated, so these are added as tasks that never run, the same way that --phase keeps the tasks of the other phases. The checks for APIServer and etcd instance groups had the same problem. Updating only the control plane or only the nodes of a cluster with APIServer instance groups removed their network tag from the API firewall rules, and updating only the control plane added the control plane to the public load balancer, which should only send traffic to the APIServer instance groups.
…oups The nvidia and gVisor addons were only added to the bootstrap channel when an instance group that uses them was being updated. Updating only the control plane, for example in the first step of "kops reconcile cluster", removed them from the channel. kops-channels doesn't delete addons that are removed from the channel, so they kept running, but they weren't updated until the next full update. The new test shares the cluster setup of runChannelBuilderTest.
systemd 258 removed the CPUAccounting= directive, as CPU accounting is always enabled on cgroup v2, and newer versions warn when a unit still sets it. MemoryAccounting= is still supported and is kept.
On AWS and GCE, nodeup writes a chrony configuration with "leapsectz right/UTC" on Debian and RHEL family nodes. On Debian 13 and Ubuntu 25.10 and later the right/ timezones live in the optional tzdata-legacy package (split out in tzdata 2023c-6), and Debian's chrony package dropped its dependency on it in 4.6~pre1-1, when its default config switched to leapseclist. On nodes without tzdata-legacy, right/UTC is missing and chronyd logs: Timezone right/UTC failed leap second check, ignoring Ubuntu 24.04 does not log the warning only because its chrony 4.5 package still depends on tzdata-legacy. Replacing the directive with leapseclist is not possible everywhere: leapseclist was added in chrony 4.6 and is a fatal "Invalid directive" on Debian 11 (4.0), Ubuntu 22.04 (4.2), Debian 12 and Amazon Linux 2023 (4.3), Ubuntu 24.04 and RHEL/Rocky 8 (4.5), so chronyd would not start there. The directive is also wrong for the kOps use case. nodeup only writes a chrony configuration for AWS (169.254.169.123) and GCE (time.google.com), and both sources smear leap seconds. Google Public NTP always sets the leap indicator to 0 because the leap second is applied on the server side using the smear, and the Amazon Time Sync Service does the same over NTP. The chrony manual states for leapsectz that "clients of leap smearing servers must not use this directive", and leapseclist behaves the same way. When the source reports no leap, chrony still schedules a leap second recorded in its leap database, so with a smeared source the kernel would insert the second on top of the smear and chrony would then have to correct the clock back toward the source. On nodes where right/UTC is missing, chronyd already ignored the directive, so only the log line changes there. On nodes where it is present, chronyd no longer schedules leap seconds from tz data and no longer sets the kernel TAI-UTC offset, so CLOCK_TAI equals CLOCK_REALTIME. No use of CLOCK_TAI was found in the kOps source. Dropping the directive is the simplest configuration that is correct for these sources and works with every chrony version on every supported distribution.
"kops update cluster --instance-group" or "--instance-group-roles", and the first step of "kops reconcile cluster", build the model from only the instance groups being updated. UsesSSHBastion, the AWS GetSecurityGroups and the AWS bastion builder used that list, but the security groups and the bastion are shared by all instance groups: - Updates that left out the bastions treated the cluster as having no bastion. On AWS, GCE and OpenStack, they allowed SSH from spec.sshAccess directly to the instances, and left out the rules that allow SSH from the bastions. OpenStack removed these rules right away, and AWS removed them with --prune. - On AWS, the security groups of the roles not being updated, their rules, and the bastion load balancer were left out of the update. Updating only the APIServer instance groups failed, because their launch templates use the security group of the control plane, which was not built. These now use all instance groups.
Update Cilium to v1.18.14
…date Fix Azure and Hetzner API load balancers when updating some instance groups
Keep the nvidia and gVisor addons when updating only some instance groups
…l-update Keep the GCE API load balancer when updating only some instance groups
Fix security groups when updating only some instance groups
Initial support for Ubuntu 26.10 (Stonking Stingray)
Drop CPUAccounting from kubelet unit
Remove leapsectz directive from chrony config
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )