The forgotten FAQ entry - limitations of k3d vs k3s?

[hholst80]

Hi guys!
Last time around when I tried k3d it had a few important feature limitations. For instance it would not generate events for when configs where changed nor was resource limits supported. Is there any up to date list of such feature differences between k3s and k3d somewhere?
Kind regards,
Henrik Holst

[iwilltry42]

Hey @hholst80 , thanks for starting this discussion!
Can you elaborate on that?

generate events for when configs where changed

I have no idea what you're referring to here 🤔

resource limits supported

Is this about docker resource limits or Kubernetes resource limits? 🤔
-> Docker resource limits: true, k3d can't do that, as K3s containers have to run in privileged mode.
--> k3d has "artificial" memory limits for nodes, where we fake meminfo files, so that K3s thinks that the node has less resources available.
-> Kubernetes resource limits: Always worked.

[hholst80]

The resources field under containers would be the specific resource object I am referring to. I want to remember that it had no effect trying to limit the CPU usage for a particular deployment on k3d and I put k3d in the "nice for local development, less useful for production" box. This is the conclusion that I want to update myself on.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        resources:
            limits:
              memory: 200Mi
              cpu: 1
            requests:
              memory: 100Mi
              cpu: 100m
        ports:
        - containerPort: 80

[hholst80]

generate events for when configs where changed

I have no idea what you're referring to here 🤔

I want to remember (I cannot find my notes on k3d unfortunately, it probably got lost in a migration from Quip to Notion..) that the Kubernetes API did not trigger an event for a listener if a ConfigMap was changed due to a re-deployment.

[iwilltry42]

"nice for local development, less useful for production"
This is true in any case and also the main purpose of k3d actually, already because of the limitations introduced by the extra docker layer.

Regarding the Kubernetes specific things you've mentioned: Those should only be related to K3s itself, not k3d, as k3d does not interfere with Kubernetes/K3s directly in any way 🤔