Record of the webinar "Do you need Kubernetes"
Pavel Selivanov - the main speaker at the intensives of Kuburnethes ( Slurm-2 for those who are just getting acquainted with the technology and MegaSlerm for those who are already working with Kuburnethes).
October 25–27 - Slurm-2
October 29–31 - Megaslarme
If you register before October 18, tell the manager “I am from a webinar” and you will be given a 10% discount.
Slurm 3 is scheduled for June '19.
TL; DR webinar:
1. If you are counting on a magic pill that alone solves your problems, then you do not need Kubernetes. This can finish viewing / reading.
2. My first experience with k8s.
There were 50 microservices, chaos in operation, Docker, lack of orchestration, rollout of services in the spirit of "today release, downtime 2 hours".
Implemented Kubernetes (Docker Swarm and Nomad were implemented in parallel, Docker Swarm did not catch on):
We built the infrastructure, not Kuburnetes.
3. Pros and cons of Kuburnetes are relative: that for one is a plus, for another - a minus. Therefore, holivar about them never subsides.
4. "Cons" Kuburnetes
- For today, Kuburnetes is not a complete and ready-made solution, rather a designer. There you can finish any functionality for yourself, but someone has to cut it, and if the necessary functionality is not created, the cluster will be incomplete. Therefore, the escort team will spend a lot of time on escorting Curnertes.
- Cuburnetes covers a huge number of aspects of infrastructure. We'll have to learn how they work and how to repair them. A narrow specialist (networker, SRE engineer) is forced to turn into a specialist in Couberntes.
- Kuburnetes due to internal mobility requires special treatment of monitoring and storage of logs.
5. Applications should be developed under Kubernetes or at least under Docker. Kuburnetes is designed for microservices. Running monoliths in a cluster is problematic.
6. Cubernethes allows you to control a huge number of aspects of the life cycle of applications. My opinion: it would be good to transfer this control to the development. The worst thing I heard from the developer: "Why should I think about resources, I just want to write code."
7. You do not need Kuburnetes if you think:
- Kuburnetes will change my business (or at least the IT department) and everything will work.
- I read about Kuburnetes on Habré, an interesting topic.
- I want like Google ...
8. There are pessimists Kuburnetes, which they used, said "shit" and threw out.
There are optimists at Cubernétes, ready to fight with anything, as long as they have Cuberntes.
And there are realists Kuburnetes, ready for the fact that a huge number of things will need to be controlled through Kuburnetes, you will need to study it deeply and finish it. Realists get:
- embedded solutions for many tasks;
- uniformity (for example, there is no longer a problem that staging has diverted from production);
- self-healing and as a result 99.9% SLA.
9. About sore: about expectations from courses
I constantly encounter the fact that people expect to get a specialist from the courses. So it does not work.
Courses (in particular Slurm) are a good start in technology. I myself do not like courses, I was at them twice in my life, but it was after the courses that Docker became interested and began to deal with him. After the courses you have questions on which you are engaged in self-development.
Courses are the experience of lecturers who have already made their mistakes and collected their bumps.
Courses are an opportunity to ask questions and receive answers. Unlike the community, I, as a lecturer, have to answer questions and be responsible for my words.
A nice bonus is communication with colleagues.
10. 3 days of training at Slurm replace 3 days of reading documentation + 1 month of practical experiments + six months of operation. That is, save time. But Slurm (as well as self-study) does not guarantee that you will become a Cuberntes specialist.
At the 37th minute the answers to the questions of the participants begin.