kubernetes-cluster

Expected Behaviour

Change the default cron spec in --etcd-snapshot-schedule-cron (default: "0 */12 * * *"):

--k3s-extra-args '--etcd-snapshot-schedule-cron * * * * *'

I'm trying to apply node labels using the following configuration:

  - name: test
    instanceType: m5.large
    minSize: 1
    maxSize: 2
    desiredCapacity: 2
    labels:
      role: test
      node-role.kubernetes.io/test: ok

According to #580 and #582 using node-role subdomain should the way to apply labels, however I still get a domain error:

AWS::EKS::No

When figuring out which versions are supported for sonobuoy e2e you have to come to github and know where to look. It would be better to be able to dump the embedded versions via a command sonobuoy e2e versions or flag sonobuoy e2e --supported-versions.

There can be a difference between the online and offline modes so lets take that into consideration. This can allow us to store the test

At the moment of writing this issue, kubectl trace only supports X86-64 as target architecture.

The tool should be able to schedule bpftrace programs against all the architectures supported by bpftrace, that are X86-64 and arm64 (aarch64) see the Cmake definition.

To achieve that we n

What would you like to be added:
Cilium is our default CNI solution on EKS-A clusters. It would be beneficial to enable Cilium metrics so that existing Prometheus could be configured to scrape those targets.

Users that download the windows EXE will be prompted (by browser and OS) that it is not safe because the EXE isn't signed.

There is a GitHub Action for signing: https://github.com/marketplace/actions/code-sign-a-file-with-pfx-certificate

This would provide additional confidence for

Proposed change

I'd like to see our autohttps deployment be able to provide metrics that prometheus can scrape.

Who would use this feature?

Users of the helm chart that wants to ensure they don't bottleneck because low resources on this proxy pod.

(Optional): Suggest a solution

I suggest we experiment with [this Traefik configuration](https://docs.traefik.io/observability/metr

What is version of KubeKey has the issue?

latest

What is your os environment?

CentOS 7

KubeKey config file

any

A clear and concise description of what happend.

There are some ipvs policies created by kube-proxy during cluster creation, But these ipvs policies still exist after I deleting the whole cluster created by kubekey.

Relevant log output

16

Add a prometheus exporter! Example outputs:

• Layer 2
• Layer 3
• TCP LoadBalancer
• IPVS LoadBalancer (once @yastij implements it ;)
• Control Pane HA