[00:00.000 --> 00:07.000]  Hello. Hello. Okay. So, welcome to the container's dev room for them 2023. We're all very happy
[00:16.580 --> 00:22.320]  to be back in person in completely filled room as usual for this track. And we've got
[00:22.320 --> 00:28.920]  our first speaker who's going to be talking about drawing Kubernetes cluster the right
[00:28.920 --> 00:35.920]  way. Take it away. Okay. So, yeah, you see the title of the talk. And the nature of Kubernetes
[00:49.360 --> 00:56.360]  is a little bit specific. I would say. And that's why these talks are so important.
[00:58.920 --> 01:05.920]  Talk exists and I hope can be beneficial. If we speak about the Kubernetes specific,
[01:08.640 --> 01:15.640]  the first thing we actually think about is the high-entrance threshold. First of all,
[01:17.640 --> 01:24.640]  we have tremendous amount of objects or entities, I would say, which interact with each other
[01:25.000 --> 01:32.000]  in some predictable or not always predictable manner. So, the slide just lists few of them.
[01:41.520 --> 01:48.520]  And as you know, Google likes inventing new entities with specific names, which are doing
[01:48.520 --> 01:55.520]  something non-standard from the point of view of pre-Google systems. So, you have pods
[02:04.240 --> 02:11.080]  services which are not traditional service. You have a large amount of controllers. You
[02:11.080 --> 02:18.080]  have labels, lectures. You have some objects which are really Kubernetes specific and
[02:18.800 --> 02:25.800]  such as deployments. Then you have specific tools or components or concepts to control
[02:29.000 --> 02:36.000]  all these orchestrated together set of containers. And due to this complexity, you really need
[02:39.760 --> 02:46.760]  good and simple drawing to illustrate it. Well, from the cognitive point of view, we
[02:48.520 --> 02:55.520]  divide cognitive load in several groups, actually in three groups. The one is really
[02:57.320 --> 03:02.800]  on cognitive load related to the subject you are presenting and to other groups are more
[03:02.800 --> 03:09.800]  related to the way you present the subject. And decreasing cognitive load for presentation
[03:10.800 --> 03:17.800]  actually free some mind resources of the consumer of your drawing and makes it much easier
[03:20.800 --> 03:27.800]  to understand. And that is really needed in case of Kubernetes. The specific of Kubernetes
[03:30.000 --> 03:37.000]  cluster relies on two things. The first thing is, well, we can traditionally think about
[03:38.000 --> 03:45.000]  the cluster of virtual machines as cluster of some machines connected in one network.
[03:49.320 --> 03:56.320]  But actually a traditional networking based approach in case of Kubernetes is not so beneficial.
[03:57.280 --> 04:04.280]  First of all, the network in case of the Kubernetes cluster is more about namespaces, network policies,
[04:07.000 --> 04:13.480]  granted or not granted access and so on. And actually, well, virtual machines are still
[04:13.480 --> 04:20.480]  machines. They are somehow virtually connected with each other. But that's not the problem
[04:20.480 --> 04:26.480]  of you as a cluster creator. It's actually the problem of Kubernetes itself to manage
[04:26.480 --> 04:33.480]  this. And no reasons to draw it on your diagram. Then you have to do the same. You have to
[04:37.000 --> 04:44.000]  draw objects, Kubernetes objects. You have to combine objects in groups and just connecting
[04:44.000 --> 04:51.000]  them with some network lines is not helpful. And if speaking about grouping, the other
[04:51.520 --> 04:58.520]  problem is that sometimes groups should be presented as objects and sometimes groups
[04:58.520 --> 05:05.520]  should be presented as groups. It's really Kubernetes. And it's really a Kubernetes way
[05:06.320 --> 05:11.820]  of thinking about, well, things. And you have to deal with it. We will see it a little bit later.
[05:11.820 --> 05:18.820]  So let's try to look how people are drawing Kubernetes clusters. The first thing to think
[05:20.480 --> 05:27.000]  about is using some black and white drawing a traditional way. Maybe an old school graph
[05:27.000 --> 05:33.920]  V's example would be the good starting point. Well, what's good with it? It's graph V's,
[05:33.920 --> 05:40.920]  it's recognizable. And people will say, oh, he uses graph V's. Cool. But as you remember,
[05:43.400 --> 05:50.400]  your Kubernetes cluster is not a graph. Yes. It's not actually good to use network diagram
[05:50.600 --> 05:57.600]  in traditional ways. So using graphs is nothing good as well. Well, some author, well, by
[05:57.600 --> 06:04.600]  the way, on the bottom, you have the source of the slide, of the drawing and regards to
[06:08.920 --> 06:15.920]  the author. Some are using LibreOffice diagrams with blocks and lines. You see not too much
[06:19.640 --> 06:26.640]  lines here. It's good. And it's really better than the others. It's better than the others.
[06:27.600 --> 06:34.600]  And then the previous one turns really easy to understand. Then you see that shades of
[06:35.400 --> 06:42.400]  gray are using to distinguish group of objects one from another. Actually, it's a good approach.
[06:46.480 --> 06:53.480]  So grouping should be actively used in black and white drawing as well. And you can see
[06:58.600 --> 07:05.600]  if you just draw rectangles without using color, it will be dull a little bit. And it
[07:06.840 --> 07:13.840]  will be a little bit empty. You will look at it and think, is it a diagram at all? Okay.
[07:18.560 --> 07:25.560]  If we are speaking that shades of gray are beneficial to distinguish groups of objects
[07:25.920 --> 07:32.920]  one from another, then what about colors? Colors are also beneficial. Frankly speaking,
[07:36.880 --> 07:43.880]  this diagram comes from the official Kubernetes documentation from Google. What good is it?
[07:48.000 --> 07:55.000]  It uses colors. What's bad with it? Never use black text on blue background because blue
[07:55.400 --> 08:02.400]  and black has the lowest possible value of contrast. Other examples, just a few of them
[08:06.880 --> 08:13.880]  just to notice that people are actively using colors. This one at least uses white on black.
[08:14.880 --> 08:21.880]  It would be more readable. Well, actually, if you choose colors, the good idea is to
[08:26.160 --> 08:33.160]  use color wheel, especially if you are more confident with containers than with color
[08:34.160 --> 08:41.160]  combinations. So color wheel allows you to choose colors with good contrast and which
[08:49.080 --> 08:54.560]  are complementary to the main color you choose. You can even follow the color scheme of your
[08:54.560 --> 09:01.040]  website or of your slides or anything like this. And it will give you the unique and
[09:01.040 --> 09:08.040]  recognizable diagrams. So few links to color wheel available online are on the slide, and
[09:12.040 --> 09:19.040]  I would say it's a good thing to use. So a little bit more about networking diagrams.
[09:19.120 --> 09:25.080]  They're actually second drawing from the official Kubernetes documentation. What's good? It
[09:25.120 --> 09:32.120]  has stacks. Stacks are also good in grouping. It has some UML like arrows which are actually
[09:34.120 --> 09:41.120]  not inheritance. Just used for some aesthetic reasons, I think. And it's clearly drawn in
[09:43.200 --> 09:50.200]  LibreOffice. So if Google is okay with drawing things in LibreOffice, why not? And it uses
[09:50.240 --> 09:57.240]  some traditional networking icons, but just to put something except rectangles here.
[09:59.880 --> 10:06.880]  The really good example from Red Hat, sorry. You see colors with grouping. You see few
[10:08.400 --> 10:15.400]  network icons which are just objects to make the overall drawing more interesting and not
[10:16.400 --> 10:23.400]  overloading your mind. A little bit more about networking diagrams. If you have lines and
[10:28.640 --> 10:35.640]  arrows, not to show that everything is connected with everything, but to guide viewer how to
[10:36.000 --> 10:43.000]  scan this diagram, then in this case networks are really good. Network, I mean lines, arrows.
[10:45.720 --> 10:52.720]  But if you add more icons, it will be a disaster. The diagram becomes really difficult to read.
[11:00.240 --> 11:07.240]  Tiny icons, all tiny icons are looking similar and will be lost. Sequence drawing as well.
[11:07.760 --> 11:14.760]  We were speaking that arrows are good in putting some order in which the reader should scan
[11:17.120 --> 11:24.120]  it. Sequence numbers are okay as well. But once again, don't overdo it. Also, it's popular
[11:24.480 --> 11:31.480]  to make some experiments with shape of objects. Non-rectangular blocks are rather good. You
[11:38.600 --> 11:45.600]  can use them. Official Google documentation has a portion of diagrams with something like
[11:45.600 --> 11:52.600]  this. If you are lucky, it will be a good sample of art. If you are not lucky, it will not.
[11:54.720 --> 12:01.720]  So guess whether you need it or not. Code fragments. When you create flight, it's typical
[12:01.920 --> 12:08.920]  to put code fragments inside your diagrams, some UML files or something like this. It
[12:10.400 --> 12:17.400]  works rather well. Don't forget about colors. But probably not in web documentation or something
[12:18.320 --> 12:25.320]  like this. One more point is to speak about the official Kubernetes icons. Well, blue
[12:26.000 --> 12:33.000]  haptagons specify objects. Blue haptagons specify groups. They are very similar. Is it easy
[12:39.680 --> 12:46.680]  to scan? No. It's not. It's a good example. Sorry.
[12:47.880 --> 12:54.880]  We have much worse examples. Which were officially presented as an example to follow. It was
[13:02.920 --> 13:08.920]  slides on this one, exceptionally. This one was present in slides on Google Drive. I have
[13:08.920 --> 13:15.920]  noticed it was removed from the RIDME file. But it's still pretty good. It's still pretty
[13:17.400 --> 13:22.360]  present over the Internet. It's difficult to close things when you have made them public
[13:22.360 --> 13:29.360]  once again. So what to use? The first. A lot of angled shapes increase stress level. It's
[13:37.440 --> 13:44.440]  known from psychology. So if you use official Kubernetes icons, use just a few of them,
[13:45.280 --> 13:51.880]  not too much. And probably you would like to use grouping with rectangles with rounded
[13:51.880 --> 13:58.880]  corner, just like this one, to reduce the overall level of stress caused by these angular icons.
[14:04.400 --> 14:11.400]  And what else? Few is better than more in this case.
[14:14.560 --> 14:21.560]  Well, the conclusions. The first thing to take care of is low consumption of icons, which
[14:25.080 --> 14:32.080]  saves your user from visual overload. More text, less icons. Like in Unix, you know, text
[14:34.080 --> 14:41.080]  is okay. Then color. Color runs, well, not the world, but definitely runs your presentation.
[14:44.760 --> 14:51.760]  Just use a good color combinations. It's a really good idea to follow. Then round corners
[14:54.320 --> 15:01.080]  will save your presentation as well. They are really important, especially if you use
[15:01.080 --> 15:07.600]  several official icons to let people know that you are, well, the person who knows that
[15:07.680 --> 15:14.680]  these icons exist. Then what about ideal drawing? Rectangles, just few lines as a gaze, then
[15:19.080 --> 15:24.600]  maybe some numbers if you need to show sequence of actions. Maybe some arrows if you need
[15:24.600 --> 15:31.600]  to show the sequence of actions. Then a good idea is to mix official Kubernetes icons with
[15:31.600 --> 15:38.600]  some other icons if you need more than two or three of them. It sounds strange, but it
[15:39.320 --> 15:46.320]  really works. Then the last advice. Using several simple drawings instead of one complicated
[15:49.440 --> 15:56.440]  drawing is a really good way to present your cluster. Actually, it relates not only to
[15:56.440 --> 16:03.440]  Kubernetes. Several simple drawings are almost always better than one complicated drawing,
[16:05.560 --> 16:12.560]  but in case of Kubernetes and this additional cognitive flawed, it's really important.
[16:13.240 --> 16:20.240]  Then probably that's the last slide. Thank you.
[16:26.440 --> 16:26.800]  Thank you.