It's been a long time since K8S related originals, I'm too lazy to update it, mainly I don't know if it will help. Until a few days ago, a classmate discussed with me the introduction of a bunch of cloud native components, which not only did not improve efficiency, but added a lot of mental burden. I just remembered that I haven't updated the article for a long time, and I should share some of my experiences with you. I wanted to write about hard-core technologies, but then I gave up; firstly, the technical articles were nerve-wracking to read, and secondly, K8S-related technologies and best practice articles were flooded, and basically there were solutions to the problems encountered, so today I mainly talk about K8S technology Some alternative topics beyond the details.
Can you think about why K8S will become the infrastructure of various cloud manufacturers and medium and large companies? For example, Facebook's Twine, its design is the opposite of K8S, which avoids the centralized design of K8S and can accommodate more nodes , manage more machines. However, it did not enter our field of vision. The reason is that K8S is sufficiently open source and neutral, and the core components are all plug-in designs, which maintains the flexibility of software design and allows the community and cloud vendors to conduct custom development; major cloud vendors found after trying It can play a role in reducing costs and increasing efficiency, and start to customize their own technologies and standards; so that downstream large and medium-sized companies can directly use or purchase technologies or platforms opened by cloud manufacturers; upstream operating profit-makers, standard-setting developers, downstream users They promote each other, thus forming a virtuous circle of mutual benefit and win-win.
For some organizations, there are certain requirements for security. Many services do not allow the direct use of public clouds. They can only build their own private cloud platforms based on K8S. In use, there are no technical problems in theory. A colleague told me before that the cloud-native technologies centered on K8S are actually very simple, based on the containerized packaging technology of docker, define the arrangement file, publish it to the K8S platform, start the service, and support the expansion......
The core code of more than 50W is second only to an operating system; then look at the release speed of K8S and the number of bug fixes. In addition, the key point is that the number of various components, various container runtimes, various log collection components Loki, fluentd, EFK, monitoring tools, application management tools OAM, and various cluster management tools are overwhelming, how should I choose? If nothing else, at least you have to choose one of each type according to your own usage scenarios.
But the question is, I have chosen a bunch of tools that can meet the usage scenarios, how should these tools be connected together?
I had interviewed a certain tens of thousands of artificial car companies before and asked me a question, how should the various infrastructures centered on K8S be managed? For example, authentication, authorization, and even how to allow relevant personnel to easily discover and use these infrastructures ?
If the scale of use is relatively small, you can make a navigation page and list all the components on the page. You can see all the components at a glance and choose to use them. If the scale of use is relatively large, you can make a single sign-on authentication system, which is convenient for logging in to all systems with one click.
Looking back now, my thinking was naive.
There are many components in the cloud native system. If everyone shares an account, there must be a problem, and there is no way to manage the account application in each component, so single sign-on is only the most basic requirement. If the company has an ldap domain account that can be synchronized and used, if not, it is possible to enter the personnel information by other means. In a sense, if you want to make a single sign-on system by yourself, you need to connect various cloud native components in series, or you need to add your own login jump interface to various cloud native component interfaces. No one in the cloud native community can help you implement customized functions.
After logging in, the bosses must hope that different people see different menus to prevent misoperations, which is very down-to-earth. If the cloud native components do well, then you can connect to their menu permission management function. If not, you may have to implement it yourself. But anyway, you have to customize cloud native components again.
If a colleague changes department and needs the permission of adding, deleting, modifying and checking another service, what should I do? Send an email to apply, and you will find that today with the rapid development of artificial intelligence, many things have to be done by human flesh, and finally, out of frustration, You can only develop a permission application system and apply for permission by yourself. You only need the approval of colleagues in the corresponding department. In any case, there will still be a certain degree of development cost and workload.
The above are actually basic rights management. For some resource applications, service access, and even some self-service log access systems before the service goes online, a corresponding management platform is required. These platforms sound simple and not complicated, but Combined with your actual usage scenario, it is difficult to find ready-made...
Cloud native means that your upper-layer application is native, and the cloud native infrastructure itself is not native.
说到这里，有些同学可能要抬杠了，我们的几十台机器用的就非常简单，那么恭喜你，你之所以觉得简单，可能是享受到了 K8S 给我们带来的技术红利，也可能你的集群规模还不足以使用 K8S 进行管理。K8S 本身是用来管理上千个物理节点的。你非要用它来管理你的几十台物理机。虽然你的硬件资源不需要人肉管理，但是你需要专业运维人员去维护 K8S 集群，最终小规模集群可以带来的收益和付出的成本，基本上可以抵消；或者引入更多的成本、更高的学习复杂度。之前写过一篇关于小公司使用 K8S 带来的问题，有兴趣的可以参考：过早关注基础设施建设是万恶之源
人总是喜欢高估现在自己，很多事情看起来都不会太复杂，如果真的太复杂，基本当时就放弃了。当你真正入手去做的时候，你会发现各种不合适，各种需要定制化，领导期望一再降低，周期一直推迟，预算持续增长。这大概也就是很多云厂商重复造轮子的原因。洋洋洒洒扯了这么多，也没有说个解决方案，其实这种事情不用说，说了也没用，只是做的时候心里有谱就行了。
推荐
原创不易，随手关注或者”在看“，诚挚感谢！
本文分享自微信公众号 - 云原生技术爱好者社区（programmer_java）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。