#kubernetes - February 2022

Is it possible to trigger a job when another job completes? Or would you need something like argo workflows to orchestrate the jobs?

@Leo Przybylski has joined the channel

@Lucky has joined the channel

hi there. please has anyone seen this error after adding datadog as a sidecar to eks fargate

Your pod's cpu/memory requirements exceed the max Fargate configuration

WTH? you can’t delete messages anymore????????

Hi folks, currently I'm having issues deploying metrics-server on EKS. I've installed the latest version via terraform using the resource helm_release however, I'm getting the following error:

$ kubectl top nodes
Error from server (ServiceUnavailable): the server is currently unable to handle the request (get <http://nodes.metrics.k8s.io|nodes.metrics.k8s.io>)

$ kubectl describe apiservice <http://v1beta1.metrics.k8s.io|v1beta1.metrics.k8s.io>
Message: failing or missing response from <https://10.0.5.36:4443/apis/metrics.k8s.io/v1beta1>: Get "<https://10.0.5.36:4443/apis/metrics.k8s.io/v1beta1>": context deadline exceeded
Reason: FailedDiscoveryCheck

$ kubectl logs -n kube-system deploy/metrics-server
1 round_trippers.go:454] GET <https://10.0.4.76:10250/stats/summary?only_cpu_and_memory=true> 200 OK in 6 milliseconds
1 round_trippers.go:454] GET <https://10.0.5.211:10250/stats/summary?only_cpu_and_memory=true> 200 OK in 6 milliseconds
1 scraper.go:157] "Scrape finished" duration="20.409888ms" nodeCount=3 podCount=9
1 server.go:139] "Storing metrics"
1 server.go:144] "Scraping cycle complete"
1 handler.go:153] metrics-server: GET "/readyz" satisfied by nonGoRestful

EKS Cluster version: 1.21
Metrics Server version: 3.7.0

Does anybody know what could be wrong?

💥 Check out our upcoming Webinar: Managed Kubernetes Clusters: Avoiding risky defaults, K8s threat modeling and securing EKS clusters

Click here to register
Learn how to navigate the creating of a secure by default K8s cluster, avoid risky default settings and permissions, and listen to some live threat modeling of security EKS clusters. Join Lightspin CISO Jonathan Rau and Director of Security Research Gafnit Amiga to discuss hot topics and tips for leveling up your Kubernetes security knowledge. Questions and topics covered include:

- Avoiding risky default settings in your Kubernetes clusters
- Creating a secure by default Kubernetes cluster
- Unique supply chain risks for Kubernetes

Hi there,

I have a rolling update deployment strategy with a 0 max unavailable value.
Unfortunately when I deploy many pods get terminated and I am not sure why.

Example:

Normal  ScalingReplicaSet  30m   deployment-controller Scaled down replica set deployment-xyz to 27
Normal  ScalingReplicaSet  2m20s deployment-controller Scaled down replica set deployment-xyz to 10

It went from 27 to 10

Strategy:

StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  0 max unavailable, 25% max surge

Any ideas where I could look at to maybe understand why this is happening?

brew for kubernetes --> https://github.com/kbrew-dev/kbrew

hi if anyone is using <https://github.com/terraform-aws-modules/terraform-aws-eks> i am trying to add some additional tag to the ELB which get created from this module but having a hard time locating it. If anyone can point me to the right location pls thx.

Hey 😄
For Platform Engineers over here, what do you think about this PR ?
https://github.com/kubernetes/kube-state-metrics/pull/1689

Hi All
Our Managed Kubernetes Clusters: Avoiding risky defaults, K8s threat modeling and securing EKS clusters webinar starts in less than an hour, still time to register 🔥

https://bit.ly/3LRJWwt

Hi we’re using the kubernetes provider here and I’m wondering how others are using this when they have multiply clusters/contexts being used? thx!

something simple as below would only allow a single context to be access, what if i have multiply contexts?

provider "kubernetes" {
  config_paths    = [
                    "~/.kube/config",
                    "~/.kube_another_path/config"
                    ]
  config_context = "cluster01
}

Regarding an EKS upgrade from 1.18 to 1.21, one option that was proposed was to leave kube-proxy and the AMIs at the 1.18 versions to reduce the amount of change and expedite the process, following up with these upgrades (and probably more) in the future. I'm not comfortable with that one. Anybody have any thoughts on the matter? Thanks for any input.