#kubernetes - January 2021

TIL … https://medium.com/better-programming/amazon-eks-is-eating-my-ips-e18ea057e045, was wondering where all our IP addresses were going 😆

kind of related.. i thought i'd posted this in here but i don't see it?
https://ec2throughput.info/
https://github.com/jfreeland/ec2-network-monitor <- i use datadog and these metrics from ethtool aren't being exposed by dd agent yet

I just took the CKAD certification exam! Ask me anything! (The material is under NDA, so I can't be specific, but general is okay)

Hello,
can someone share experience on ArgoCD ? or similar product ?

In an environment with high churn pods, Prometheus metrics might get bloated with lots of quite “temporarily pod-labeled” metrics... does anyone else do something to tackle this or just live with it?

I feel a per-pod metric, outside of its deduplication purpose, is of very little interest really except possibly in a very narrow “live” monitoring sense...

Meanwhile it’s not as impactful for statefulsets, can give them a not-so-dynamic number label instead...

Hi All - I am trying to setup dual stack IPv6/IPv4 setup.. I am trying to use below kubeadm config file. When try to run kubeadm init with this config file I get below error. Could anyone please help on sorting out this issue and What am I doing wrong?

Has anyone used this flag new-pod-scale-up-delay with the cluster-autoscaler?

Hi, I'm trying out EKS Fargate, to get an impression on how it behaves. I'm experiencing:

• Pending to ContainerCreating around the 60/70s mark. A bit slower than I anticipated but seems ok based on what I read online.
• ContainerCreating to Pending takes over 4 minutes. Very slow. Pod consists of 3 containers totalling ~800Mb (compressed, based on ECR data). Not 'tiny' but far from outrageous I'd say.
Nothing strange in namespace or pod events, although it looks like it's always the same container of which pull takes excessive long. It's a node.js app so number of files is a possible cause I can think of. Then again, on regular EC2 workers this doesn't seem to be a problem.

Does this very slow image download sound familiar to anyone? Has anyone got tips to diagnose or improve it?

Hey folks — Has anyone had any luck with contacting AWS support / AWS engineering asking for an EKS Platform Version bump? They seem to do it on a rolling basis and I have a production account that I cannot use Fargate Logging in since it’s on 1.18.9 eks.2 instead of eks.3

concept question
use case: the devs don't want to update 3 times the same env (and they don't have defaults (yet) in their code) (i use kustomize to manage per env changes)
lets says i add the same env variable twice

in the next example if someone sets

common_env_vars:
  FOO_VAR: 1
per_env_vars:
  FOO_VAR: 1234

######

env:
{{- range $name, $value := .Values.common_env_vars }}
{{- if not (empty $value) }}
- name: {{ $name | quote }}
    value: {{ $value | quote }}
{{- end }}
{{- end }}
{{- range $name, $value := .Values.per_env_vars }}
{{- if not (empty $value) }}
- name: {{ $name | quote }}
    value: {{ $value | quote }}
{{- end }}
{{- end }}

will the second always be the winner?  or is there a chance that every deployment change another one will be set?

Hello,
I have a question regarding the cluster-autoscaler. It is possible to tune it to not to scale too quickly? Currently with the default settings its spawns 4 nodes at the same time for just a couple of new gitlab-runner jobs...

I am wondering if anyone solved the issue of having ephemeral storage via EBS on AWS EKS. I would love to use https://kubernetes.io/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volumes - however EKS is still at 1.18.
Use case here is, that pods will handle (large file uploads - up to 10GB) - and I don't want to pollute the host storage volumes with it. Was actually hoping to leverage PVCs that get thrown away, but haven't found a good solution so far - or maybe I was looking into the wrong direction here?
Also considering to use secondary volumes on the cluster nodes - any experiences with using secondary volumes in managed nodegroups?

Hey folks — I’m investigating implementation of service meshes / advanced deployment strategies (Blue / green + Canary) for a client. I’m going to start reading heavily into this next week, but before doing so I figured I’d reach out to a couple communities for opinions before going heads down.

To give a bit of context before I dive into questions — Client is on AWS / EKS utilizing Fargate for all internal services with Flux v1 / Helm Operator as their CD tool. I’ll also be evaluating Argo vs FluxV2 in the coming weeks as well if that matters in this discussion.

On to questions —
1. Any definitive, must read resources on this topic that I should know about?
2. I see the options today being either AWS App Mesh OR Istio as it seems the service mesh tools are the best route towards implementing advanced deployment strategies in a SOA architecture. Is there any other tooling I should take into account for this decision?
3. AFAICT, App Mesh at a high level means lower complexity + less capabilities + more AWS lock in (not sure if I care about this as this point) vs Istio at a high level means OSS + higher complexity + more capabilities. Any other high level thoughts here that I should be aware of?
4. Any gotchas / catches I should watch out for in regards to implementing a service mesh?

Awesome tool - a must use
https://github.com/ahmetb/kubectx