@Marc Sluiter Sorry, aber ich kann doch auch Pods ohne ein ReplicaSet oder ein Deployment laufen lassen. Und nur weil ich ein ReplicaSet habe kann und muss ich kein Deployment haben. Irgenwie macht das in meinen Augen jetzt nicht so viel Sinn. Natürlich ist es sinnvoll Pods mit einem ReplicaSet laufen zu lassen, aber man muss es nicht. Es kommt auf die Anwendung drauf an. Außerdem laufen HeathChecks nicht im ReplicaSet sondern können direkt in der Pod Konfiguration laufen. Kubernetes handelt also den Pod Fehler, nicht das ReplicaSet. Außer ich habe so ziemlich alles missverstanden, was ich in den letzten wochen gelernt habe.
Ja, man KANN Pods und/oder ReplicaSets auch ohne Deployment nutzen, aber es macht allermeistens keinen Sinn: wenn z.B. ein Pod ohne ReplicaSet gestartet wird, kann ich weder die Anzahl der Pods ändern, noch startet K8s den Pod automatisch neu, wenn z.B. die Node, auf dem der Pod, läuft ausfällt. Und wenn ich ein ReplicaSet ohne Deployment nutze, fehlen mir Features wie Rolling Updates... siehe kubernetes.io/docs/concepts/workloads/controllers/replicaset/#alternatives-to-replicaset Richtig, die Healthchecks sind Teil des Pod Spezifikation, und die werden (auch?) direkt von k8s genutzt. Ich bin mir tatsächlich gerade nicht sicher inwieweit ReplicaSets die auch nutzen, das könnte in der Tat zumindest missverständlich in meiner Präsentation sein, danke für den Hinweis!
Basically, to scale with demand. When you create a pod, you can (and should) specify some limits for it to operate under (like limit CPU usage or RAM assigned). That way, you can use the auto-scaling features more efficiently. If, for some reason, one of your pods comes under heavy load, the system will just start another copy and load balance between them. After a certain period of time where the load isn't as high, it will kill some replicas. That can save you a lot of money on cloud services or, if running locally, can extend the lifespan of your servers and reduce your electrical bill. Also, having more than one copy running at a time is just a good practice in general for redundancy's sake.
![Persistent Storage with Kubernetes in Production - Which Solution and Why? [I] - Cheryl Hung](http://i.ytimg.com/vi/hqE5c5pyfrk/mqdefault.jpg)
0 bullshit, 100% info. Thank you very much
1. Pods
2. ReplicaSets
3. Deployments
4. Services
5. Ingress
6. Namespaces
7. Clusters
8. Secrets and ConfigMaps
9. Data Volumes
10. PetSets
11. Jobs
12. DaemonSets
13. Autoscaling
14. API
15. Open Source (and Cloud Native)
I like the way he presents Kubernetes features.
Short and on point! Just what I was looking for!
Great and quick overview. Thanks
Can you share the presentation? I want to discuss Kubernetes with some people and PDF or PPT would be easier than video. Thanks!
www.slideshare.net/MarcSluiter1/marc-sluiter-15-kubernetes-features-in-15-minutes
Brilliant
@Marc Sluiter Sorry, aber ich kann doch auch Pods ohne ein ReplicaSet oder ein Deployment laufen lassen. Und nur weil ich ein ReplicaSet habe kann und muss ich kein Deployment haben. Irgenwie macht das in meinen Augen jetzt nicht so viel Sinn. Natürlich ist es sinnvoll Pods mit einem ReplicaSet laufen zu lassen, aber man muss es nicht. Es kommt auf die Anwendung drauf an. Außerdem laufen HeathChecks nicht im ReplicaSet sondern können direkt in der Pod Konfiguration laufen. Kubernetes handelt also den Pod Fehler, nicht das ReplicaSet.
Außer ich habe so ziemlich alles missverstanden, was ich in den letzten wochen gelernt habe.
Ja, man KANN Pods und/oder ReplicaSets auch ohne Deployment nutzen, aber es macht allermeistens keinen Sinn: wenn z.B. ein Pod ohne ReplicaSet gestartet wird, kann ich weder die Anzahl der Pods ändern, noch startet K8s den Pod automatisch neu, wenn z.B. die Node, auf dem der Pod, läuft ausfällt. Und wenn ich ein ReplicaSet ohne Deployment nutze, fehlen mir Features wie Rolling Updates... siehe kubernetes.io/docs/concepts/workloads/controllers/replicaset/#alternatives-to-replicaset
Richtig, die Healthchecks sind Teil des Pod Spezifikation, und die werden (auch?) direkt von k8s genutzt. Ich bin mir tatsächlich gerade nicht sicher inwieweit ReplicaSets die auch nutzen, das könnte in der Tat zumindest missverständlich in meiner Präsentation sein, danke für den Hinweis!
good overview
Good one
thanks :)
Thanks
Why are replications of a pod created or killed?. I mean why do we need to replicate a pod isn't 1 enough.
Basically, to scale with demand. When you create a pod, you can (and should) specify some limits for it to operate under (like limit CPU usage or RAM assigned). That way, you can use the auto-scaling features more efficiently. If, for some reason, one of your pods comes under heavy load, the system will just start another copy and load balance between them. After a certain period of time where the load isn't as high, it will kill some replicas. That can save you a lot of money on cloud services or, if running locally, can extend the lifespan of your servers and reduce your electrical bill. Also, having more than one copy running at a time is just a good practice in general for redundancy's sake.
Also prevents downtime if a pod goes down
Labels are missing
very good