diff --git a/docs/blog/en/2023/06/sealos-release.md b/docs/blog/en/2023/sealos-release.md similarity index 100% rename from docs/blog/en/2023/06/sealos-release.md rename to docs/blog/en/2023/sealos-release.md diff --git a/docs/blog/en/2023/what-is-sealos.md b/docs/blog/en/2023/what-is-sealos.md new file mode 100644 index 00000000000..e45fdafa791 --- /dev/null +++ b/docs/blog/en/2023/what-is-sealos.md @@ -0,0 +1,337 @@ +--- +slug: what-is-sealos +title: "Sealos vs Traditional Cloud Platforms: A Comparative Analysis of Efficiency and Cost" +description: "Explore the innovative Sealos cloud operating system: a Kubernetes-based platform revolutionizing cloud computing. Dive into its design, unique features, and competitive advantages over traditional cloud services. Learn how Sealos optimizes user experience, reduces costs, and simplifies cloud resource management for businesses and developers." +authors: [fanux] +tags: [Kubernetes, Sealos] +keywords: [Cloud Operating System, Sealos, K8s, Cloud Native, Cloud Computing, Cloud OS, PaaS, Rancher, KubeSphere, Cloud Service] +image: https://cdn.jsdelivr.net/gh/yangchuansheng/imghosting5@main/uPic/2023-08-31-09-52-gLmSek.jpg +date: 2023-07-10T10:00 +--- + +With the rapid development and widespread application of cloud computing, businesses and developers are increasingly seeking flexible and efficient ways to manage and deploy cloud resources. In this context, Sealos emerges as not only a [cloud operating system](https://sealos.io) with Kubernetes at its core, but also as an innovative solution aimed at simplifying and optimizing the cloud computing experience. + +This article delves into the core functions, technical features, design philosophy of Sealos, and how it revolutionizes the [cloud operating system](https://sealos.io) domain. We will also explore Sealos' applications in various usage scenarios and compare it with other cloud service platforms in the market to demonstrate its unique competitive advantages and potential. + + + +## What is Sealos? + +Conceptually, Sealos is similar to operating systems like Windows, but with two key differences. First, Sealos does not operate on a single server; its core concept is to **treat the entire data center or resources across multiple servers as a unified whole**. This approach breaks the limitation of traditional operating systems that operate on a single machine, extending resource and application management to a larger scale, **enabling the operation and management of applications across the entire data center**, significantly enhancing the utilization efficiency of cloud resources and operational capabilities. + +![](https://cdn.jsdelivr.net/gh/yangchuansheng/imghosting-test@main/uPic/2023-11-17-13-46-9Nel1a.png) + +Unlike ordinary operating systems that support daily applications like QQ and WeChat, Sealos focuses on providing developers with the environment they need for distributed applications. In the world of Sealos, **complex cloud computing tasks become as simple and intuitive as using a personal computer**. Whether running common web services like Nginx or deploying and managing distributed applications written in various programming languages, Sealos can do it all with one click, greatly reducing the complexity of configuration and management. Its design philosophy emphasizes user-friendliness and simplicity, striving to eliminate technical barriers in using cloud services, making cloud computing's powerful capabilities easily accessible to every user. + +## Core Problems Solved by Sealos + +Sealos primarily addresses the following core issues: + +### Optimizing Cloud Experience + +#### User Interface + +The significance of the User Interface (UI) is self-evident. Traditional standalone operating systems have provided us with a standardized user experience paradigm. However, many of today’s cloud platforms have evolved into vast and complex systems, causing users to lose their way in the product. This has even led to the creation of specialized training positions for cloud services, reflecting a failure in product design to some extent. For example, few people need training to use an iPhone, as its product design is already excellent and very easy to understand and operate. + +In product design philosophy, we first need to recognize that different user roles have varying focal points. The user base of cloud services includes developers, database administrators (DBAs), operations personnel, Kubernetes (k8s) experts, technical novices, and industry experts. Trying to satisfy all these roles with one product is nearly impossible. For instance, even with the same CI/CD (Continuous Integration/Continuous Deployment) tool, some prefer Jenkins, while others favor Drone. + +Many PaaS platforms take CI/CD as an example and often integrate specific tools like Jenkins, leading to a need to rebuild core functions when the tool becomes less popular or better alternatives emerge. Also, this design fails to meet the preferences of different users. + +The approach of standalone operating systems is worth learning from. The operating system itself does not interfere too much but is responsible for managing applications well. This allows users to freely choose their preferred applications, such as office software DingTalk or Feishu, which are independent of the Windows operating system. This method grants users a great degree of freedom. Although many PaaS platforms also offer app markets, they do not consider applications as the primary element. Instead, most platforms focus on Kubernetes as the core, which is not wrong per se, but **this approach only targets the cloud-native user group and fails to achieve a high level of abstraction**. + +The Sealos platform fully follows the operating system philosophy. It focuses on the specific functions users need. For example, a DBA creating a database does not need to worry about the details of Kubernetes; users of Function Compute services do not need to be concerned about whether they run in containers; and Kubernetes experts can operate through the Lens application or command-line tools. This design philosophy allows various types of users to find suitable tools and services on its platform, thereby optimizing the overall user experience. + +#### API > CLI > GUI + +Many people's understanding of a product is limited to its GUI, but in reality, a cloud service product without an API is almost useless to businesses. To improve efficiency, businesses need to connect and integrate various systems, highlighting the importance of APIs. Cloud services are often designed not just for human users but also for other programs or systems, to achieve a high degree of automation in enterprise operations. + +![](https://cdn.jsdelivr.net/gh/yangchuansheng/imghosting-test@main/uPic/2023-11-17-14-36-qnQmDa.jpg) + +Sealos provides APIs that are fully compatible with Kubernetes' CRD (Custom Resource Definitions) design. Users can manage and control their cloud resources through Sealos' APIs in the same way as operating in a Kubernetes environment. For security, Sealos assigns a permission-limited kubeconfig authentication file to each tenant. These files allow tenants to flexibly connect, manage, and secure different systems and resources. + +This design not only makes Sealos' cloud services more powerful and flexible but also provides enterprises with an efficient, automated way to manage their cloud infrastructure. With the extensive application of APIs, businesses can easily integrate Sealos cloud services into their existing workflows, thus enhancing operational efficiency and flexibility. + +#### Fast and Efficient Operation Experience + +Our goal is to ensure that most operations can be completed within 30 seconds, and at most not exceed 3 minutes. If the operation time of a feature exceeds this standard, there must be a problem, necessitating reevaluation and redesign. + +#### Catering to All Users + +Although Sealos is primarily aimed at developers, in the process of functional design, we also pay attention to the experience of non-technical background users. For this purpose, we specifically invite administrative staff without technical backgrounds to experience our services firsthand. This helps us validate the ease of use of our product. If they can smoothly complete the operation process, it proves that our product is easy to operate and user-friendly. The ease of use of the product is our core pursuit. If users need guidance from others to use the service, it indicates that our design still has room for improvement. + +#### Focus on High-Quality Applications + +In the field of application development, Sealos always prioritizes quality over quantity. For the vast majority of applications, a stable operating environment and backend database support are indispensable. We focus on refining these basic applications first, and then expand to other application fields, integrating cutting-edge applications from various directions and domains, to provide users with comprehensive and efficient solutions. + +#### Ensuring Scalability and Security + +Sealos does not set standards on its own but strictly follows mature systems and de facto standards, ensuring high compatibility with the entire cloud-native ecosystem. All cloud-native applications can run safely on Sealos, and even some non-productized applications can be run through Sealos' terminal. Our compatibility is built on full support for Kubernetes, with enhanced security measures. + +![](https://cdn.jsdelivr.net/gh/yangchuansheng/imghosting-test@main/uPic/2023-11-17-14-48-vbJezM.png) + +In Sealos, to prevent improper operations or inappropriate image downloads from causing catastrophic effects on the entire system, each user's permissions are restricted within their own namespace. This permission management mechanism strengthens the security and stability of enterprise-level [cloud operating system](https://sealos.io)s. + +### Reducing Cloud Costs + +Our goal is not just to help you cut costs by 30%—such a target lacks challenge and is too mundane. We aim to minimize the marginal cost of cloud services, ideally to one-tenth of the original cost. How to achieve this? This is the direction we are pursuing. So, how can we achieve this goal? + +#### Redefining Cloud Architecture: Abandoning Traditional Models + +**First, we must abandon the traditional three-tier architecture model of IaaS, PaaS, and SaaS.** + +Why give up this classic architecture? The reason is that the traditional layered model no longer meets the current technological developments and market demands. Take IaaS as an example; it simulates hardware like routers, switches, and virtual machines in data centers through software. While this improves scheduling flexibility, it also leads to a sharp increase in software costs. For instance, OpenStack requires a team of dozens of people to maintain its stability, directly resulting in high software costs. In the past, this approach seemed necessary to improve resource utilization, but now, from an application perspective, many applications don't care if they run in a separate VPC during operation. + +![](https://jsd.onmicrosoft.cn/gh/yangchuansheng/imghosting-test@main/uPic/2023-11-17-15-00-2jC2C8.png) + +The above is a diagram I drew five years ago, which is gradually becoming a reality. This is similar to the development history of single-machine operating systems: initially layered, later evolving into a more efficient kernel architecture. The layered architecture of cloud computing also carries historical baggage. Once enterprises abandon IaaS, they can save substantial costs and enjoy higher performance. + +From this new perspective, we find that IaaS is actually unnecessary. Technically speaking, PaaS and SaaS are essentially the same; they are both application-level services and thus do not need to be overly differentiated. In the new cloud kernel architecture, we only need to effectively implement isolation between tenants. This does not require complex and heavyweight solutions. For example, Sealos offers a way to share a Kubernetes cluster among multiple tenants in an untrusted public network environment. We achieve this goal using strong isolation containers (like Firecracker), network policies (like Cilium), and block device isolation for storage (like OpenEBS), not only reducing costs but also achieving better results. + +![](https://jsd.onmicrosoft.cn/gh/yangchuansheng/imghosting-test@main/uPic/2023-11-17-15-02-6N4ygp.png) + +#### Increasing Application Density and Scheduling Efficiency + +Unless it's a very heavy compute-intensive application, it's almost embarrassing to not run over 100 applications on a server. On Sealos, we run 800 applications on one server while ensuring application stability. + +This is very important for enterprises, as it significantly reduces the need for hardware resources. If you are a corporate executive, you might want to re-examine your company's overall resource utilization rate, which is often below 20%. Through our method, there is much more room for improvement. + +With Sealos, enterprises can save up to half the cost in a simpler way. + +#### Full Elasticity + +Inactive applications at night should rest and leave resources for offline computing or training tasks. This is actually more advantageous with public clouds, as resources can be directly released, saving a lot of costs. + +Sealos directly incorporates this key feature. If all enterprise applications operate in this way, huge cost savings can be achieved. + +#### Eliminating Zombie Applications and Servers + +There are many development and testing programs in enterprises. How do you know which ones are not being used? There are also many zombie "servers." Some companies can only maintain who used what with an Excel sheet, asking around periodically to retire servers that no one claims. Slightly more advanced ones might use an outdated CMDB. + +The radical solution to this problem is: charging money. Yes, internal enterprise applications should also be charged, and those that owe fees should be shut down directly. + +This way, each department can apply for a budget, and developers apply for a budget. Once the budget is used up, the application is shut down, ensuring no zombie applications in the long term. Sealos brings all servers under unified management, turning the entire cluster into a large resource pool, eliminating the possibility of zombie servers. It also saves enterprises a lot of operational manpower. + +To eliminate resource waste, such fine-tuned operations are needed, and Sealos achieves this purpose at a very low cost. The only thing enterprise managers need to do is allocate money to each sub-account. + +![](https://jsd.onmicrosoft.cn/gh/yangchuansheng/imghosting-test@main/uPic/2023-11-17-16-18-ijXZ4y.png) + +This way, you can precisely control how much each department and each person spends, further analyzing ROI. + +#### Operating the Entire Cloud with Half a Person + +A team of operators? An operations team for each business unit? Have you ever seen Microsoft sell a PC and then provide you with an operator? Therefore, it's still about inadequate software. If the software is sufficiently excellent and stable, there's no need for the role of an operator. Or this role will change, like writing orchestration files or operators. + +The developers of Sealos spent less than half the effort to maintain the entire cloud. Whether it's 8,000, 80,000, 800,000, or 8 million applications, it only requires half a person. This is the [cloud operating system](https://sealos.io), which doesn't increase operational complexity as the scale grows. + +I am a neutral person, but I have an extreme view: in a sufficiently mature cloud, there should be no role for operations. If your enterprise has more than 3 operators (excluding those who move servers), you should seriously reflect on this. + +Here's a clear path for current operations staff: develop [cloud operating system](https://sealos.io)s. + +#### Research and Development Human Resource Costs + +I am a developer, and I spend at least 50% of my effort on things other than development. Those miscellaneous tasks may account for 20%, but their impact is 80%. They interrupt what I'm doing, like when you finish writing code and think about selling servers, configuring certificates, packaging, and going live. I bet no developer likes doing these things unless they're masochistic. Developers are lazy, and to be lazy, they develop a bunch of tools. This is the victory of the lazy, and Sealos is also created by the lazy. So if something can be automated, never do it manually; if AI can do it, never do it manually. + +![](https://jsd.onmicrosoft.cn/gh/yangchuansheng/imghosting-test@main/uPic/2023-11-17-16-18-as6HSI.png) + +Analyzing issues yourself is tiring; AI is more professional than humans. + +The function computing capability of Laf on Sealos makes writing code as simple as writing a blog post. Just click save, shut down, and leave. To leave work early, use Laf efficiently. + +All backend dependencies, like databases, can be resolved in under 30 seconds. In the future, AI will automatically package, deploy, code, and debug. + +This intangible increase in development efficiency can save unimaginable costs. In our customer examples, there are many cases of two people doing the work of five. + +### One-Click Private Cloud Construction, Consistent Experience Between Public and Private Clouds + +Sealos has a profound understanding of cloud computing: + +**Public and private clouds are the same thing, the same abstraction, the same set of codes, and the same experience, just with different applications installed.** + +You will find that Linux, whether running in your own data center or in a public cloud, is the same product form. This is the characteristic of excellent software: achieving a high degree of abstraction. + +Sealos was designed with this in mind. In fact, public and private clouds are essentially the same; they both link computing resources. Many people might think they are different, but public clouds also have recharge and billing. These functions just need to be placed in a separate application, which can be left uninstalled in scenarios where they are not needed. + +![](https://jsd.onmicrosoft.cn/gh/yangchuansheng/imghosting-test@main/uPic/2023-11-17-16-18-vMGZyu.png) + +However, even if a larger enterprise builds a private cloud, it should be similar to a public cloud in form. Metering and billing are very important features. Enterprises with more than 10 people need to finely operate cloud resources, let alone enterprises with thousands of employees using private clouds. The cost allocation among departments is essential. + +Some minor differences, like WeChat payment or third-party login, may indeed be unnecessary, which are just small configurations. + +## An In-Depth Look into Sealos Technology + +Sealos takes on a challenging scenario: allowing multiple tenants to share a Kubernetes cluster in an untrustworthy public network environment. + +The benefits of this approach are significant: +- Users can start directly without building a cluster and only pay for containers, significantly reducing costs. +- As the scale increases, a flywheel effect occurs, drastically reducing marginal costs. (Sealos's Moore's Law: Every doubling of the Sealos cluster size reduces cloud costs for users by 30%) + +However, this approach also presents a significant technical challenge: ensuring isolation, security, and scalability. + +By overcoming these technical challenges, we not only provide great value to customers in the public cloud but also easily handle private cloud scenarios. + +![Sealos Technology Analysis](https://jsd.onmicrosoft.cn/gh/yangchuansheng/imghosting-test@main/uPic/2023-11-17-16-19-sJYA9X.png) + +Decomposing Sealos's technology system: + +### Ubiquitous Operation +A well-known open-source project in this area might be Terraform. Unfortunately, it's slow to start when interfacing with certain clouds (due to poorly written drivers; not Terraform's fault) and can easily hit API call limits of cloud providers (also due to erratic driver requests), failing to meet our needs. + +Moreover, we prefer Kubernetes CRD standards over Terraform. Consequently, we developed our own infrastructure controller. What normally took 10 minutes to launch, we optimized to 30 seconds, which is nearly the limit barring faster server startups by cloud providers. The optimization mainly involved parallel processing and algorithmic adjustments, rather than simple 10-second delays. Additionally, launching a Sealos cluster on these VMs takes only 3 minutes, already outperforming many similar products (which generally take 15 minutes). + +Running on bare metal also requires considering extensive compatibility issues. Thus, Sealos almost entirely abandons RPM, Apt, and other OS-tied installation tools, achieving compatibility with all major Linux distributions. We don't support Windows, simply because we don't prefer it. + +Our cluster imaging capability also effectively supports mainstream hardware architectures like ARM and x86. + +### Cloud Driver Layer +This component faces massive challenges. Without considering isolation and security, installing containerd, Calico, and OpenEBS might suffice. However, in a public, untrusted environment, such weak isolation is unacceptable. Therefore, we've innovated with new technologies, such as Firecracker, for strong container isolation. The challenges of running VMs within VMs in cloud providers' infrastructure will be addressed in a separate article. + +Our network needs require high measurement and isolation standards. Traditional solutions like Calico rely heavily on iptables rules, becoming unusable at scale. We tested and found a 30% failure rate under stress with just 5000 rules. For networking, we introduced Cilium, using eBPF to address these issues and multi-tenant network metering. + +![Cloud Driver Layer](https://jsd.onmicrosoft.cn/gh/yangchuansheng/imghosting-test@main/uPic/2023-11-17-16-19-REW9Fy.png) + +For storage, we use OpenEBS plus LVM, mounting isolated volumes for each user, allowing them to enjoy local disk performance. File storage, however, becomes a significant issue. NFS and similar solutions are nearly toys, unsuitable for production. Thus, we developed Sealfs, a high-performance filesystem, from scratch in Rust, emphasizing simplicity and support for RDMA. + +### Lifecycle Management and Cluster Imaging +For cluster installation and scaling, Sealos users know the process is nearly perfected, with complex clusters managed with a single command! + +Cluster imaging capability, likely unmatched globally, is supported by Sealos and Sealer, both of which I led in development. This capability is king in delivery! Entire clusters can be packaged in a fully Docker-compatible format, enabling one-click deployment in customer environments. + +In the face of our cluster imaging capability, other delivery tools pale in comparison. + +### Tenant Management +Multi-tenancy is a critical need for any enterprise-level user. Designing tenant permissions requires flexibility without complexity, ensuring isolation and collaboration among departments or developers. Native Kubernetes doesn't address these needs, offering only rudimentary namespace management. + +Sealos assigns each user an independent kubeconfig, limiting their permissions to their namespace. Users can share their namespaces but are prohibited from risky actions like piercing through to the host, using privileges, or sharing host filesystem ports. + +### Application Management +Applications are first-class citizens in Sealos, with everything above the cloud kernel being an application. The challenge here is finding a unified application management approach in a multi-tenant environment. + +- Some applications need admin rights to run a controller. +- Others need to run a separate instance. +- Some, like a ChatGPT API, are shared by multiple users. +- Certain applications, like terminal apps, auto-release when unused. + +The system also needs to control and meter these applications, further complicating matters. + +Sealos abstracts these capabilities into applications, similar to running apps on macOS. + +### Proprietary Function Compute Application Laf + +Laf revolutionizes code writing, akin to blogging. + +- Cloud-based development with immediate results. +- Efficient use of Laf means early finishes. +- Even administrative staff can easily use cloud development. +- Function computes come in two types: those that deploy in 30 seconds, and those that discourage use in 30 seconds. + +Laf's millisecond-level publishing outperforms others, where a typical deployment takes 3 to 5 seconds. Laf achieves faster than blogging speeds. + +Laf integrates GPT-4, reducing the need for manual coding. We trained thousands of Laf codes, enhancing AI writing capabilities. + +Databases and object storage are built-in. Except for some AI coding, almost no other concerns are needed. + +It uniquely supports WebSocket, outmatching others (where function compute charges by duration). + +Unlike other function computes that are not persistent, Laf utilizes always-on, auto-scaling containers. + +### Proprietary AI Knowledge Base Application FastGPT + +Laf's AI codes, Sealos's automatic fault diagnosis, AI auto-deployment of applications, and Docker image building rely on FastGPT for knowledge base construction. + +![FastGPT Application](https://jsd.onmicrosoft.cn/gh/yangchuansheng/imghosting-test@main/uPic/2023-11-17-16-19-cCinq3.png) + +### Databases/Message Queues Applications +We focus on the operating system and some built-in apps. For highly specialized areas like databases and message queues, we collaborate with top teams. For databases, we partner with Kubeblocks, led by PolarDB founder Cao Wei (conveniently next door, with great coffee and reliable databases). Kubeblocks orchestrates MySQL, PostgreSQL, MongoDB, Redis, etc., ensuring data security and recovery. + +For message queues, we collaborate with RocketMQ founder Wang Xiaorui, addressing RocketMQ and Kafka services. + +In DevOps, we work with Gitea, 90% compatible with GitHub Actions, led by the Gitea creator. The near-perfect compatibility with GitHub Actions is a wise choice. + +### Metering and Billing + +Metering is complex, requiring a monitoring-like collection mechanism. Beyond measuring container CPU, memory, and disk usage, it must associate data with namespaces and ultimately accounts. More challenging measurements include database access counts in function computes and storage used by each tenant. The most difficult is measuring network bandwidth without impacting performance. + +The metering system's challenge is its sensitivity. Any error affects customer billing, necessitating a reconciliation system to verify measurements and ensure billing accuracy. + +With this capability, enterprises can finely operate internal departments and developers, automatically shutting down applications with overdue payments, virtually eliminating idle processes. + +We've also unified the abstraction for metering in both public and private cloud modes. + +## Sealos Design Philosophy and Principles + +The essence of remarkable technology is its simplicity from the user's perspective, similar to the Apple iPhone and the Android operating system. Cloud computing can achieve this too, but simplicity without powerful functionality is merely rudimentary. A brilliant architecture doesn't sacrifice complexity for functionality. + +If Sealos deviates from these principles, it becomes cumbersome and heads towards obsolescence. + +### The Principle of Simplicity + +Sealos embodies simplicity in two aspects: product design and system architecture. + +In terms of product design, we are committed to not burdening users. We want users to use the cloud as easily as they use personal computers, focusing on applications relevant to their roles without being disturbed by unnecessary features. This does not imply weak functionalities; Sealos can enhance system capabilities by extending any application and provides native APIs for flexible expansion. + +At the system architecture level, abandoning the traditional IaaS, PaaS, SaaS three-tier architecture is wise. From an application perspective, there's no need for such complex support structures. With cloud kernel and cloud drivers, **everything above the system is an application.** + +### Fragmentation + +Sealos can be simplified to just a bare Kubernetes, or expand to thousands of applications. It can run on a TV box or in data centers with tens of thousands of servers. Think of Linux, which can operate on embedded devices and in the largest data centers. This represents a fragmented architecture, meeting your exact needs without overwhelming you with unnecessary capabilities. + +Only this architecture can achieve limitless expansion. + +### Modular Assembly + +A cohesive and streamlined architecture allows for customization according to individual needs. Your cloud should be just right – neither too much nor too little. This is possible thanks to a high level of abstraction. Specific functionalities are implemented by applications themselves, while the cloud OS only needs to pool resources and manage applications. Thus, even if there are tens of thousands of applications in the ecosystem, the complexity of your cloud doesn't increase. Think about how you use a smartphone; the cloud can be used in the same way. + +## Use Cases + +### Using Sealos Cloud Services Directly + +- Any business component that can be built into a Docker image can easily run on Sealos (with future AI assistance for image building). This includes projects written in various programming languages within a company. +- One-click launch for highly available clusters of the four major databases: pgsql, mysql, mongo, and redis. Complete with backup, recovery, monitoring, and control. +- Various well-known open-source projects can run on Sealos. + +Thus, Sealos effectively supports your business systems, addressing runtime issues and all backend dependencies. + +### Building a Complete Private Cloud + +It's increasingly apparent that bare metal not only performs better than virtual machines but is also more cost-effective. However, many companies are hesitant to opt for hardware hosting due to the complexity of managing software – be it OpenStack or Kubernetes. + +The cloud service version of Sealos can be cloned exactly into your own data center. Sealos already serves tens of thousands of online users, supporting scenarios and complexities that surpass most companies. After all, companies with tens of thousands of developers are rare. + +So, with bare metal and Sealos, both hardware and software are set, and building a private cloud becomes feasible. + +The cost of self-building? + +- Purchase servers. +- Launch clusters with a single command – so simple anyone can do it, regardless of the number of servers. +- Minimal maintenance, about 0.5 person. We've nearly achieved self-maintenance. The current online cluster serves tens of thousands of applications with approximately 0.1 person's effort in maintenance. + +## Comparison with Other Platforms + +### Comparing with Other Cloud-Native PaaS Platforms + +One of the most frequently asked questions is about the biggest difference in design philosophy. Sealos does not aim to be an all-encompassing PaaS platform. The [cloud operating system](https://sealos.io) itself is highly abstracted, essentially 'nothing'. On Sealos, applications are the prime focus, meeting users' needs through various applications. For instance, when using the Database application on Sealos, you need not worry about any other concepts, not even knowing how to spell 'Kubernetes'. + +Sealos, differing from traditional PaaS platforms that aim for all-inclusiveness, regards the [cloud operating system](https://sealos.io) as a highly abstract 'nothing', emphasizing the importance of applications. On the Sealos platform, **applications are considered the top priority**, catering to a diverse range of user needs. For example, when using the database application on Sealos, users don’t need to concern themselves with any other concepts, **not even how to spell “Kubernetes”**. + +Rancher and KubeSphere are excellent PaaS platforms. However, Sealos does not consider Kubernetes as its core purpose. It focuses more on the applications running on Kubernetes than Kubernetes itself. Hence, Sealos targets a wide range of developers, intending to create a versatile operating system, not confined to serving only the cloud-native sector. Sealos even prefers not to emphasize the yet-to-be-defined concept of 'cloud-native'. + +Therefore, the core idea of Sealos is not “a better Kubernetes” but rather “**providing the applications users need through Kubernetes**”. + +> What do users really need? +> + +In the operating system domain, user needs define the system’s functionalities. The flexibility of an operating system means it does not impose extra burdens on users. For example, Windows is a gaming platform for gamers, a programming tool for programmers, and a graphic processing software for graphic artists. The identity of an operating system is determined by its users, depending on which applications are loaded. Sealos also embraces this philosophy, hence different users will have distinctly different experiences. + +### Comparing Various K8s Installation Tools + +Installation is merely a boot function of the entire operating system, but Sealos also has unique features in cluster lifecycle management and application packaging and delivery. + +Firstly, Sealos can complete installation with a single command. Secondly, using cluster images, the entire cluster can be packaged and delivered anywhere. Lastly, Sealos allows users to flexibly customize their required cluster like writing a Dockerfile, freely assembling and replacing components in the image, offering hundreds of components for user selection. + +## Conclusion + +The Sealos community now has a vast user base, developed over many years, battle-tested, with stability proven in various extreme scenarios, steady as an old dog. + +Our cloud service has seen exaggerated growth in registered users and application numbers, exceeding 6k online developers and nearly ten thousand applications within two weeks of launch. + +We will provide users with a [cloud operating system](https://sealos.io) that is consistent in both public and private cloud experiences, simple, affordable, open, and powerful. \ No newline at end of file diff --git a/docs/blog/zh-Hans/2023/06/sealos-release.md b/docs/blog/zh-Hans/2023/sealos-release.md similarity index 87% rename from docs/blog/zh-Hans/2023/06/sealos-release.md rename to docs/blog/zh-Hans/2023/sealos-release.md index bb16f193a0f..b4d96ae1a34 100644 --- a/docs/blog/zh-Hans/2023/06/sealos-release.md +++ b/docs/blog/zh-Hans/2023/sealos-release.md @@ -1,10 +1,10 @@ --- slug: sealos-release title: Sealos - 云操作系统的未来 -description: 深入探索 Sealos 的发展历程，从一个简单的 Kubernetes 安装工具到一个全面的云操作系统项目。了解创始人的故事，Sealos 的演变，以及它如何简化企业和个人的云计算操作。 +description: 深入探索 Sealos 的发展历程，从一个简单的 K8s 安装工具到一个全面的云操作系统项目。了解创始人的故事，Sealos 的演变，以及它如何简化企业和个人的云计算操作。 authors: [fanux] tags: [Kubernetes, Sealos] -keywords: [云操作系统, Sealos, Kubernetes, 云原生] +keywords: [云操作系统, Sealos, K8s, 云原生] image: https://jsd.onmicrosoft.cn/gh/yangchuansheng/imghosting5@main/uPic/2023-08-31-09-52-gLmSek.jpg date: 2023-06-13T10:00 --- @@ -13,9 +13,9 @@ date: 2023-06-13T10:00 这是一个宏伟的计划，漫长且有趣。 -在今天这个快速发展的云计算领域，Sealos 不仅是一个项目，它是对未来云操作系统概念的重新定义和实践。从一个简单的 Kubernetes 安装工具开始，Sealos 的发展已迈入了全新的领域，目标是构建一个完整、高效且易于管理的[云操作系统](https://sealos.run)。 +在今天这个快速发展的云计算领域，Sealos 不仅是一个项目，它是对未来云操作系统概念的重新定义和实践。从一个简单的 K8s 安装工具开始，Sealos 的发展已迈入了全新的领域，目标是构建一个完整、高效且易于管理的[云操作系统](https://sealos.run)。 -2018 年的某个夜晚，夜深人静，我挥舞键盘，敲下了 Sealos 的第一行代码。当时仓库命名为 “kubeinit”，后来觉得格局太小，我不可能只做一个安装 Kubernetes 的工具。安装只是更大计划的一部分，于是更名为 [Sealos](https://github.com/labring/sealos/ "Sealos")，一个宏大的[云操作系统](https://sealos.run)计划就此诞生！ +2018 年的某个夜晚，夜深人静，我挥舞键盘，敲下了 Sealos 的第一行代码。当时仓库命名为 “kubeinit”，后来觉得格局太小，我不可能只做一个安装 K8s 的工具。安装只是更大计划的一部分，于是更名为 [Sealos](https://github.com/labring/sealos/ "Sealos")，一个宏大的[云操作系统](https://sealos.run)计划就此诞生！ ![](https://jsd.onmicrosoft.cn/gh/yangchuansheng/imghosting5@main/uPic/2023-08-31-09-52-gLmSek.jpg) @@ -35,7 +35,7 @@ Sealos 的第一个版本写完后，我就把它发布到了阿里云市场出 ### 在阿里的工作 -**在阿里工作期间，我开发了 Sealer**。这里最重要的一点就是，让安装足够灵活。以前用户只能使用我创建的安装包，而集群镜像的创新可以让用户自由定义安装包，也可以自由组合任何安装包。这里有个让我感到自豪的想法 : **把整个集群视为一个整体，把 Kubernetes 看作一个操作系统，那么在这个[云操作系统](https://sealos.run)中，“云版 Docker 镜像”会是什么样子？**这无疑是一个伟大的想法，极具抽象度和灵活性。 +**在阿里工作期间，我开发了 Sealer**。这里最重要的一点就是，让安装足够灵活。以前用户只能使用我创建的安装包，而集群镜像的创新可以让用户自由定义安装包，也可以自由组合任何安装包。这里有个让我感到自豪的想法 : **把整个集群视为一个整体，把 K8s 看作一个操作系统，那么在这个[云操作系统](https://sealos.run)中，“云版 Docker 镜像”会是什么样子？**这无疑是一个伟大的想法，极具抽象度和灵活性。 ```dockerfile FROM kubernetes:v1.25.0 @@ -77,13 +77,13 @@ Sealos 能一针见血地戳中应用的痛点，比如这个应用管理器 App 为什么能这么便宜？ -- 只需要为运行的容器付费，无需虚拟机，也无需创建整个 Kubernetes 集群，打开直接用。 +- 只需要为运行的容器付费，无需虚拟机，也无需创建整个 K8s 集群，打开直接用。 - 自动伸缩，夜间用户量少时副本缩小到 1。 - 我们可以充分利用公有云的弹性，编写大量自动化代码，夜间释放计算资源，降低成本。 这对于企业来说，可以减少大量的资源使用成本。我们自己就在 10 台服务器上运行了 7000 多个应用，这意味着什么？企业部署一套 Sealos 集群后，只要服务器资源利用率低于 70% 就可以不断向集群中添加应用，直到填满为止。 -你可能会问，**为什么不能直接使用 Kubernetes？** 原因很简单，对于诸如讯飞这样的企业，应用分散在各个部门，这时多租户、隔离与协作会变成刚需，直接使用 Kubernetes 会把集群搞乱，最要命的可能是一个部门或者用户不注意搞了个安全问题会让整个集群崩溃，而 Sealos 完美解决了这个问题！ +你可能会问，**为什么不能直接使用 Kubernetes？** 原因很简单，对于诸如讯飞这样的企业，应用分散在各个部门，这时多租户、隔离与协作会变成刚需，直接使用 K8s 会把集群搞乱，最要命的可能是一个部门或者用户不注意搞了个安全问题会让整个集群崩溃，而 Sealos 完美解决了这个问题！ Sealos 可以帮助 80% 的企业降低 80% 的资源使用成本。 @@ -95,15 +95,15 @@ Sealos 可以帮助 80% 的企业降低 80% 的资源使用成本。 这样的设计有两个主要优势： -### 懂不懂 Kubernetes 都能愉快地使用 Sealos +### 懂不懂 K8s 都能愉快地使用 Sealos -许多基于 Kubernetes 的 PaaS 平台或发行版要么暴露大量 Kubernetes 原生概念，要么屏蔽这些概念。这两种做法都不理想。 +许多基于 K8s 的 PaaS 平台或发行版要么暴露大量 K8s 原生概念，要么屏蔽这些概念。这两种做法都不理想。 -暴露大量原生概念对小白和新手不友好，屏蔽 Kubernetes 则失去了灵活性和兼容性，对 Kubernetes 老司机也非常不友好。 +暴露大量原生概念对小白和新手不友好，屏蔽 K8s 则失去了灵活性和兼容性，对 K8s 老司机也非常不友好。 Sealos 采取了不同的做法。在这个平台上，不同的人可以使用不同的应用。比如你是开发者想写 CRUD，你可以直接使用 Laf 这个函数应用。如果你是 DBA，你可以直接使用数据库应用。在这种情况下，你完全不需要关心 Kubernetes，这些概念会被完全屏蔽。 -如果用户是云原生专家，他们可以在 Sealos 上安装 Lens 和各种 Kubernetes Dashboard，也可以打开终端敲各种原生命令。这就极大提高了灵活度。 +如果用户是云原生专家，他们可以在 Sealos 上安装 Lens 和各种 K8s Dashboard，也可以打开终端敲各种原生命令。这就极大提高了灵活度。 ### 自由组装 @@ -123,7 +123,7 @@ Sealos 精简而不简单，所有组件都可以卸载，这让云恰好满足 在运行自己业务上，我们针对这个场景做了很多细节优化，比如自动分配二级域名，自动横向伸缩，支持运行各种有状态服务等。 -你会发现，借助 Sealos，**无论是部署一个拨测系统，还是运行一个低代码平台，都是信手拈来。您的博客也可以轻松托管在 Sealos 上，成本低廉。使用 Sealos 终端，运行任何兼容 Kubernetes 的应用，自动化操作不再是难题。** +你会发现，借助 Sealos，**无论是部署一个拨测系统，还是运行一个低代码平台，都是信手拈来。您的博客也可以轻松托管在 Sealos 上，成本低廉。使用 Sealos 终端，运行任何兼容 K8s 的应用，自动化操作不再是难题。** 更进一步发现：原来**有个 AI 在帮你自动做故障诊断，自动上线业务，甚至帮你写代码并自动测试上线**。 diff --git "a/docs/blog/zh-Hans/2023/11/10/velero\347\232\204\344\275\277\347\224\250.md" "b/docs/blog/zh-Hans/2023/velero\347\232\204\344\275\277\347\224\250.md" similarity index 100% rename from "docs/blog/zh-Hans/2023/11/10/velero\347\232\204\344\275\277\347\224\250.md" rename to "docs/blog/zh-Hans/2023/velero\347\232\204\344\275\277\347\224\250.md" diff --git a/docs/blog/zh-Hans/2023/10/22/vm-sealos-create.md b/docs/blog/zh-Hans/2023/vm-sealos-create.md similarity index 100% rename from docs/blog/zh-Hans/2023/10/22/vm-sealos-create.md rename to docs/blog/zh-Hans/2023/vm-sealos-create.md diff --git a/docs/blog/zh-Hans/2023/what-is-sealos.md b/docs/blog/zh-Hans/2023/what-is-sealos.md new file mode 100644 index 00000000000..f0502192fe8 --- /dev/null +++ b/docs/blog/zh-Hans/2023/what-is-sealos.md @@ -0,0 +1,349 @@ +--- +slug: what-is-sealos +title: Sealos vs. 传统云服务：全方位对比分析 +description: 深入探讨 Sealos 的核心功能、技术特点、设计理念，以及它如何革新云操作系统领域。我们也将探索 Sealos 在不同使用场景下的应用，并与市场上其他云服务平台进行比较，以展现其独特的市场优势和潜力。 +authors: [fanux] +tags: [Kubernetes, Sealos] +keywords: [云操作系统, Sealos, K8s, 云原生, 云计算, 分布式, PaaS, Rancher, KubeSphere, 云服务] +image: https://jsd.onmicrosoft.cn/gh/yangchuansheng/imghosting-test@main/uPic/2023-11-17-15-50-TKK1Ol.webp +date: 2023-07-10T10:00 +--- + +随着云计算的快速发展和广泛应用，企业和开发者越来越希望能够灵活、高效地管理和部署云资源。在这个背景下，Sealos 应运而生，它不仅是一个以 K8s 为内核的[云操作系统](https://sealos.run)，更是一个创新的解决方案，旨在简化和优化云计算的使用体验。 + +本文将深入探讨 Sealos 的核心功能、技术特点、设计理念，以及它如何革新[云操作系统](https://sealos.run)领域。我们也将探索 Sealos 在不同使用场景下的应用，并与市场上其他云服务平台进行比较，以展现其独特的市场优势和潜力。 + + + +## Sealos 是什么？ + +Sealos 在概念上类似于如 Windows 这样的操作系统，但有两个关键的不同点。首先，Sealos 不是在单个服务器上运行，它的核心理念是**将整个数据中心或跨多服务器的资源视为一个统一的整体**。这种方法突破了传统操作系统只在单一机器上运行的局限，将资源和应用管理扩展到了更大规模，能够**在整个数据中心范围内运行和管理应用**，从而大幅提升云资源的利用效率和运维能力。 + +![](https://jsd.onmicrosoft.cn/gh/yangchuansheng/imghosting-test@main/uPic/2023-11-17-13-46-9Nel1a.png) + +与普通操作系统支持的 QQ、微信等日常应用不同，Sealos 专注于为开发者提供所需的分布式应用环境。在 Sealos 的世界里，**复杂的云计算任务变得像使用个人电脑一样简单直观**。无论是运行常见的 Web 服务如 Nginx，还是部署和管理各种编程语言编写的分布式应用，Sealos 都能一键完成，极大地减少了配置和管理的复杂性。它的设计哲学强调用户友好性和简洁性，致力于消除使用云服务时的技术壁垒，让每个用户都能轻松享受到云计算的强大能力。 + +## Sealos 解决的核心问题 + +Sealos 主要解决了以下几个核心问题： + +### 优化用云体验 + +#### 用户界面 + +用户界面 (User Interface) 的重要性不言而喻。传统的单机操作系统为我们提供了一个标准化的用户体验范例。然而，当今众多的云平台已经演变成庞大而复杂的系统，导致用户在产品中迷失方向。甚至催生了一些专门针对云服务的培训岗位，这在某种程度上反映了产品设计的失败。例如，很少有人需要参加苹果手机的使用培训，因为其产品设计已经足够优秀，非常易于理解和操作。 + +在产品设计理念上，我们首先需要认识到不同的用户角色关注点各异。在云服务的用户群体中，有开发者、数据库管理员 (DBA)、运维人员、熟悉 K8s (k8s) 的专家、技术新手和行业专家等。试图用一个产品满足所有这些角色的需求几乎是不可能的。例如，即使是同一个 CI/CD (持续集成/持续部署) 工具，也有人偏爱 Jenkins，而有人更喜欢 Drone。 + +许多 PaaS 平台以 CI/CD 为例，通常集成了特定工具如 Jenkins，这导致一旦该工具不再流行或有更优秀的替代品出现时，平台需重构核心功能。同时，这种设计无法满足不同用户的偏好。 + +单机操作系统的做法值得我们学习。操作系统本身并不过多干预，而是负责良好地管理应用程序。这样，用户就可以自由选择他们喜欢的应用，如办公软件钉钉或飞书，而这与 Windows 操作系统无关。这种方法赋予了用户极大的自由度。尽管许多 PaaS 平台也提供应用市场，但他们并没有将应用视为首要元素。相反，大多数平台将 K8s 视为核心，这不是说有什么大错，但**这种做法只能定位于云原生用户群体，并不能实现高度的抽象**。 + +Sealos 平台则完全遵循了操作系统的理念。它专注于用户所需的具体功能。例如，DBA 在创建数据库时无需关心 K8s 的具体细节；使用函数计算服务的用户不必关心其是否运行在容器中；而对于 K8s 技术专家，则可以通过 Lens 应用程序或命令行工具进行操作。Sealos 的这种设计理念，使得各类用户都能在其平台上找到合适的工具和服务，从而优化了整体的用户体验。 + +#### API > CLI > GUI + +许多人对产品的理解仅限于其 GUI，但实际上，一个没有 API 的云服务产品对企业而言几乎无用。企业为了提高效率，需要打通和对接各种系统，这时 API 的重要性就显现出来了。云服务的设计往往不仅仅是为了人类用户，更多的是为了其他程序或系统，以实现企业操作的高度自动化。 + +![](https://jsd.onmicrosoft.cn/gh/yangchuansheng/imghosting-test@main/uPic/2023-11-17-14-36-qnQmDa.jpg) + +具体来说，Sealos 提供的 API 与 K8s 的 CRD (Custom Resource Definitions，自定义资源定义) 设计完全兼容。用户可以通过 Sealos 的 API，以与操作 K8s 环境相同的方式来管理和控制他们的云资源。为了安全性，Sealos 为每个租户分配了权限受限的 kubeconfig 认证文件。这些文件允许租户在保证安全的前提下，灵活地对接和管理不同的系统和资源。 + +这种设计不仅使得 Sealos 的云服务更加强大和灵活，而且为企业提供了一种高效、自动化的方式来管理他们的云基础设施。通过 API 的广泛应用，企业可以轻松地整合 Sealos 云服务到他们现有的工作流程中，从而提高运营效率和灵活性。 + +#### 快速、高效的操作体验 + +我们的目标是确保大多数操作能在 30 秒内完成，最长不超过 3 分钟。如果某项功能的操作时间超过这个标准，那一定是有问题的，需要重新评估和设计。 + +#### 面向所有用户 + +尽管 Sealos 主要面向开发者，但在功能设计过程中，我们同样关注非技术背景用户的体验。为此，我们特意邀请无技术背景的行政人员亲身体验我们的服务，以此来验证产品的易用性。如果他们能够顺畅完成操作流程，便证明我们的产品操作简便、易于上手。产品的易用性是我们的核心追求，若用户需要他人指导才能使用服务，那就说明我们的设计尚有不足。 + +#### 专注于高质量应用 + +在应用开发领域，Sealos 始终将质量置于数量之上。对绝大多数应用而言，稳定的运行环境及后端数据库支持是不可或缺的。我们致力于先对这些基础应用进行精细打磨，随后才拓展至其他应用领域，融合各个方向、领域的尖端应用，以便为用户提供全面且高效的解决方案。 + +#### 保障扩展性和安全性 + +Sealos 并不自己去设定标准，而是严格遵循成熟的体系和事实标准，这一策略确保了我们的服务与整个云原生生态系统的高度兼容。所有云原生应用均可在 Sealos 上安全运行，即便没有产品化的一些应用也可以通过 Sealos 的终端来运行。我们的兼容性建立在全面支持 K8s 的基础上，同时在安全性方面进行了加强。 + +![](https://jsd.onmicrosoft.cn/gh/yangchuansheng/imghosting-test@main/uPic/2023-11-17-14-48-vbJezM.png) + +在 Sealos 中，为了避免不当操作或不适当的镜像下载对整个系统造成灾难性影响，每位用户的权限被限制在其自身的命名空间内。这种权限管理机制加强了企业级[云操作系统](https://sealos.run)的安全性与稳定性。 + +### 降低用云成本 + +我们的目标不仅是帮您降低 30% 的成本——这样的目标缺乏挑战性，过于枯燥。我们追求的是将云服务的边际成本降至极低，至少要达到原成本的十分之一。如何实现这一目标？这正是我们追求的方向。那么如何实现这个目标呢？ + +#### 重定义云架构：摒弃传统模式 + +**首先，我们要摒弃传统的 IaaS、PaaS 和 SaaS 三层架构模式。** + +为何选择放弃这一经典架构？原因在于，传统的分层模式已不再符合当前的技术发展和市场需求。以 IaaS 为例，它通过软件模拟数据中心中的路由器、交换机和虚拟机等硬件，虽然提高了调度的灵活性，但同时也导致软件成本急剧增加。以 OpenStack 为例，没有数十人的团队是难以维护其稳定性的，这直接导致了高昂的软件成本。过去，这种方式似乎是提高资源利用率的必要手段，但现在从应用的角度看，许多应用在运行时并不关心它们是否运行在独立的 VPC 中。 + +![](https://jsd.onmicrosoft.cn/gh/yangchuansheng/imghosting-test@main/uPic/2023-11-17-15-00-2jC2C8.png) + +以上是我五年前画的一张图，现在逐渐变成了现实，这与单机操作系统的发展历程类似：最初是分层的，后来逐渐发展成为更高效的内核架构。云计算的分层架构同样携带着历史的包袱。一旦企业摒弃了 IaaS，它们就可以节省大量成本，并享受到更高的性能。 + +从这个新的视角出发，我们发现，实际上并不需要 IaaS。同时，从技术角度来看，PaaS 和 SaaS 本质上是相同的，它们都是应用层面的服务，因此也无需进行过度区分。在新的云内核架构中，我们只需要有效地实现多租户之间的隔离。这并不需要复杂重量级的解决方案。例如，Sealos 提供了一种在不可信公网环境中实现多租户共享一个 K8s 集群的方式。我们利用强隔离容器 (如 Firecracker)、网络策略 (如 Cilium) 以及存储块设备隔离 (如 OpenEBS) 来实现这一目标，不仅成本更低，效果也更好。 + +![](https://jsd.onmicrosoft.cn/gh/yangchuansheng/imghosting-test@main/uPic/2023-11-17-15-02-6N4ygp.png) + +#### 提高应用密度和调度效率 + +除非是非常重型计算密集型的应用，不然一台服务器上不跑个 100 多个应用你出门都不好意思和别人打招呼，而在 Sealos 上我们一台服务器跑 800 个应用！还能保证应用的稳定。 + +这对企业来说非常重要，企业可以显著减少对硬件资源的采购需求。如果你是企业高管，可以重新审视一下公司的整体资源利用率，你会发现大部分情况下这一比率都低于 20%。通过我们的方法，还有很多倍的提升空间。 + +通过 Sealos，企业能够以更简单的方式节省高达一半的成本。 + +#### 充分弹性 + +夜间企业的不活跃应用应该都去睡觉休息，把资源留给离线计算或者训练任务，这点其实用公有云更有优势，因为可以直接释放资源，节省大量成本。 + +![](https://jsd.onmicrosoft.cn/gh/yangchuansheng/imghosting-test@main/uPic/2023-11-17-16-18-LIZ6Yt.png) + +Sealos 直接把这一重要特性内置。如果企业所有应用都以这样的方式运行，可以节省巨量的成本。 + +#### 干掉僵尸应用和僵尸服务器 + +企业里面有很多开发测试的程序，怎么知道哪些没人在用？甚至还有很多僵尸 “服务器”，有些企业只能靠一个 exel 表来维护谁用了啥，过一段时间把负责都问一遍，清退没人有的服务器，稍微高端点的会搞个老掉牙的 CMDB。。。 + +解决这个问题的釜底抽薪办法是：收钱。对，企业内部也得收钱，欠费的应用就直接干掉。 + +这样每个部门可以申请额度，开发者申请额度，额度用完就干掉应用，这样可以长期保证没有僵尸应用。而 Sealos 把所有服务器都统一纳管，整个集群变成一个大资源池，当然就不可能存在僵尸服务器了。同时还帮企业节省了一帮运维人力。 + +要想杜绝资源浪费就需要这样精细化运营，Sealos 以极低的成本达到这个目的，企业管理者唯一要做的事就是给每个子账户分钱即可。 + +![](https://jsd.onmicrosoft.cn/gh/yangchuansheng/imghosting-test@main/uPic/2023-11-17-16-18-ijXZ4y.png) + +这样你可以精细化的控制到每个部门每个人用多少钱，从而进一步分析 ROI。 + +#### 最多半个人运维整个云 + +一帮运维？每个业务都有运维组？你见过微软把 PC 卖给你再给你配个运维？所以还是软件不够优秀，足够优秀足够稳定就不需要运维这个角色。或者这个角色做的事情会改变比如写编排文件写 operator。 + +Sealos 的开发者花了不到一半精力维护整个云，8000 个应用时半个人，8w 个也是 80w 个也是 800w 个也是半个人，这就是[云操作系统](https://sealos.run)，不会因为体量变大而增加运维复杂度。 + +我是一个比较中性的人但是我有个极端观点是云足够成熟的情况下不应该有运维这个角色，如果你的企业运维超过 3 个人 (搬服务器的除外)，那应该好好反思一下。 + +在给现在的运维人员指条明路：去开发[云操作系统](https://sealos.run)。 + +#### 研发人力成本 + +我是一个研发，我至少 50% 以上的精力花在了研发之外的事上，那些杂事加起来可能有 20% 但是其影响可能是 80% 。它会割裂我正在做的事，比如你写完代码想着还要卖服务器，配置证书，打包，上线一想到这些我敢打赌没有哪个开发者喜欢做这些事，除非他是个变态。开发者是群懒人，为了偷懒开发出一大堆工具，这是偷懒者的胜利，sealos 也是一群偷懒者创造的，所以能自动绝不手动，能 AI 绝不人工。 + +![](https://jsd.onmicrosoft.cn/gh/yangchuansheng/imghosting-test@main/uPic/2023-11-17-16-18-as6HSI.png) + +自己分析问题多累，AI 比人还专业。 + +Sealos 上函数计算能力 Laf 就可以让写代码像写博客一样简单，点击保存，关机走人，要想下班早，Laf 得用好。 + +所有后端依赖如数据库这些都可以轻松 30s 之内解决。未来还有 AI 自动打包上线，自动编码调试等。 + +这无形中的研发效率提升可以节省的成本是难以想象的，我们客户例子中 2 个人干五个人活的比比皆是。 + +### 一键构建私有云，公有云私有云体验一致 + +Sealos 对云计算的理解是深刻的： + +**公有云和私有云是一回事，同一个抽象，同一套代码，同一种体验，装的应用不同尔而已** + +你会发现 linux 不管跑在你自己的数据中心还是跑在公有云上都是一种产品形态，这就是优秀软件的特点，能做到高度抽象。 + +Sealos 设计之初就考虑到这一点，其实公有云与私有云本质是一样的，都是链接计算资源。很多人可能觉得不一样啊，公有云还有充值计费什么的，其实只需要把这些功能放到一个单独的应用中即可，这样在不需要的场景直接不安装这个应用。 + +![](https://jsd.onmicrosoft.cn/gh/yangchuansheng/imghosting-test@main/uPic/2023-11-17-16-18-vMGZyu.png) + +但其实大一点的企业即便做私有云它的形态也应该和公有云一样，计量计费是非常重要的一个功能，企业超过 10 个人都需要精细化运营云资源，就更别说成千上万人的企业用私有云了，各部门的成本分摊等。 + +一些非常小的差异比如微信支付第三方登录这些可能确实不太需要，这就是一些小的配置。 + +## Sealos 技术分析 + +Sealos 选择一条非常有挑战的场景：在公网不可信的环境中让多租户共享一个 K8s 集群。 + +这样做的好处是巨大的： + +- 用户进来直接用，不需要构建集群，也只需要为容器付费，成本大大降低。 +- 随着规模增大就会产生飞轮效应，让边际成本大量降低。(Sealos 摩尔定律：Sealos 集群规模每翻一倍用户用云成本会降低 30%) + +同时带来了一个巨大的技术挑战：隔离性，安全性和超大规模。 + +我们解决了这个技术挑战，那不仅在公有云上为客户提供很大价值，在私有云场景就更轻松拿捏了。 + +![](https://jsd.onmicrosoft.cn/gh/yangchuansheng/imghosting-test@main/uPic/2023-11-17-16-19-sJYA9X.png) + +从这张图中拆解 Sealos 的技术体系： + +### 到处运行 + +这块比较著名的开源项目可能是 terraform 了，不过很遗憾在对接某个云时启动速度很慢 (某些 driver 写的不够好，不能怪 terraform)，而且很容易触发云厂商的 API 调用 limit (也是 driver 乱请求)，无法满足我们的需求。 + +而且我们希望的标准是 K8s CRD 而非 terraform，这样配合上 helm 就可以，于是我们自研了一个对接基础设施的控制器。结果是本需要 10min 启动的基础设施我们优化到了 30s，这几乎是极限了，很难在有压榨空间了，除非云厂商自己服务器启动时间能再快些。优化点主要在一些并行的处理以及退避算法调优，而不是动不动就 sleep 10s。加上在这些虚拟机上启动 Sealos 集群也只需要 3min，这已经优于很多同类产品了，大家可以自行比较 (其它一般 15min) + +同样在裸机上运行要考虑大量兼容性问题，所以 Sealos 底层几乎全部抛弃 rpm apt 这些与操作系统耦合的安装工具，这样几乎兼容了全部主流的 linux 发行版。windows 我们不支持，原因是因为单纯的讨厌不喜欢。 + +同时我们的集群镜像能力可以很好的同时支持 ARM x86 这些主流硬件体系架构。 + +### 云驱动层 + +这块挑战巨大，如果不考虑安全性隔离性，这块装一个 containerd calico openebs 可能就 OK 了，但是在公网不可信环境中这种弱隔离肯定是不行的，所以我们在一些新的技术上填坑，如 firecracker 来解决容器维度强隔离，而云厂商虚拟机里套虚拟机又是有问题的，这里后续我们会单独发一篇文章来介绍。 + +网络我们对计量和隔离的要求极高，而 calico 这些你懂的，隔离会使用大量的 iptables 规则，规模一大基本网络就不可用了，我们测试过 5000 条规则时压力测试一下就有 30% 的失败率。网络这块我们就引入了 cilium，通过 ebpf 来解决这这些问题，还有多租户的网络计量。 + +![](https://jsd.onmicrosoft.cn/gh/yangchuansheng/imghosting-test@main/uPic/2023-11-17-16-19-REW9Fy.png) + +存储我们使用 openebs + lvm，为每个用户挂载独立隔离的卷，这样用户可以享受到本地磁盘的性能。而文件存储又变成一个大问题，nfs 这些几乎只是玩具，根本无法生产。所以我们世界冠军同学带队基于 rust 完全自研 sealfs 文件系统，架构超级精简，主打高性能，支持 RDMA。 + +### 生命周期管理与集群镜像 + +对于集群安装扩容 Sealos 老用户都知道，几乎已经被做到极致了，多复杂的集群一律一条命令搞定！ + +而集群镜像能力世界上可能 (为了不触犯广告法加上可能二字) 只有两款软件支持 Sealos 和 sealer，都是我主导开发的，sealer 在阿里时捐给了 CNCF。这种能力是交付之王！可以用完全兼容 Docker 镜像的格式把整个集群打包，到了客户环境一键交付。 + +在集群镜像能力面前可能 (用词严谨) 其它所有交付工具我只能说：都是弟弟。 + +### 租户管理 + +任何一个企业级用户，多租户都是刚需，在设计租户权限的时候既要灵活又不能复杂，这些部门或者开发者之间既要相互隔离，又需要能相互协作，而原生的 K8s 是不帮你做这些的，只提供一个最粗略的 namespace 管理肯定是不够的。 + +Sealos 会为每个登录的用户分配一个独立的 kubeconfig，其权限只会被限制到用户自己的 namespace 中，用户可以把自己的 namespace 共享给别人。用户想穿透到主机，或者使用特权，或者共享主机文件系统端口号这些危险操作统统禁止，这才是企业实践云原生的 (可能) 最佳姿势。 + +### 应用管理 + +应用是 Sealos 的一等公民，在云内核之上，一切皆应用。这里最难的地方是在多租户的情况下如何寻求一个统一的应用管理方式的抽象。 + +比如有些应用是需要一个管理员权限跑一个控制器的。 + +有些应用是需要跑一个单独的实例的。 + +有些应用是一个实例多个用户共享使用的。如一个 chatGPT API。 + +有些应用是不使用时就要被自动释放的。如 terminal 应用，没人用会自动被回收。 + +而系统还需要对这些应用进行权限的管控和计量，进一步增加了复杂度。 + +Sealos 把这些能力全部抽象成了应用，就像你 macOS 上跑的应用一样。 + +### 自研函数计算应用 Laf + +真的让你体验什么是像写博客一样写代码 + +- 云端开发，码上生花 +- Laf 用的好，天天下班早 +- 行政都会用的云开发 +- 函数计算有两种 30s 上线的和 30s 劝退的 + +Laf 的毫秒级发布几乎吊打一切，一般其他方案发布一次都得等个 3 到 5s，而 laf 能做到比发博客还快。 + +Laf 直接集成 GPT4，大部分代码就不用你自己写了，我们训练了几千份 Laf 的代码，现在 AI 写起来已经很绝绝子了。 + +数据库内置，对象存储内置，除了用 AI 写点代码几乎不用关心其它任何东西。 + +对 websocket 的支持几乎天下无敌 (有些 function 按调用时长收费，我就问你一个长链接你的钱包还够不够) + +别的函数计算不是常驻模型，一个 chatGPT 的会话 ID 你都得存到数据库，而 Laf 完全不需要，用的是常驻自动伸缩容器。 + +### 自研 AI 知识库应用 fastGPT + +Laf AI 写代码，sealos 故障自动诊断，AI 自动上线应用，自动构建 Docker 镜像，这些统统靠 fastGPT 这个项目，自动帮你构建知识库。 + +![](https://jsd.onmicrosoft.cn/gh/yangchuansheng/imghosting-test@main/uPic/2023-11-17-16-19-cCinq3.png) + +### 数据库/消息队列等应用 + +我们核心聚焦在操作系统和部分内置应用上，数据库消息队列这些是个非常专业的领域，我们选择的办法是与顶级天团团队合作，数据库我们选用 kubeblocks，是 polarDB 创始人曹伟主导的项目 (刚好就在我们隔壁，他们的咖啡好喝，数据库好用)。kubeblocks 统一编排了 mysql pgsql mongo redis，各种高可用数据备份恢复等，绝对的为数据保驾护航。数据库管控我们与 bytebase 合作，google **云数据库团队担任技术负责人陈天舟带队。** + +消息队列我们选择与 rocketmq 创始人王小瑞合作，统一解决 rocketmq kafka 等消息队列服务。 + +devops 我们与 gitea 合作，90% 兼容 github actions，gitea 作者亲自带队，github actions 几乎是一个完美 devops 方案，gitea 选择与其兼容是一个非常明智的选择。 + +### 计量计费 + +计量并不容易，首先需要有类似监控系统的采集机制，容器的 CPU 内存磁盘，采集到了之后需要与其 namespace 关联，最终关联到账户。除此之外还需要采集一些比较难采集到的东西，比如函数计算里面数据库的访问次数，对象存储每个租户用的大小等。最难的是在不影响网络性能的情况下对网络带宽的计量。 + +计量系统的挑战是他不像监控系统那样对精准度要求不高，一旦计量出错用户的钱就出错，是个非常敏感操作，我们需要有个对账的系统对计量进行校验，确保没有收错钱。 + +有了这个能力，企业就要以对部门和内部开发者做精细化的运营，应用欠费自动停机就会让整个公司几乎没有僵尸进程。 + +我们还实现了公有云模式与私有云模式计量的统一抽象。 + +## Sealos 设计理念与原则 + +牛掰的东西从使用者视角来看一定是简单的，如苹果手机，安卓操作系统。云计算同样可以做到，但是如果简单功能不强，那叫简陋。牛逼的架构不会牺牲复杂度来增强功能。 + +Sealos 一旦违背这些原则，就会走向笨重，奔向死亡。 + +### 大道至简 + +Sealos 大道至简体现在两个方面：产品设计&系统架构。 + +产品上我们坚决不想给用户带来任何负担，就希望用户像用个人电脑一样用云，是什么样的角色关心什么样的应用，坚决不让额外你不需要用的功能对你产生干扰。这不意味着功能就弱，Sealos 可以通过扩展任何应用来增强系统的能力，也提供原生 API 来自由扩展。 + +系统架构层面抛弃 IaaS PaaS SaaS 三层架构是个明智之举，因为从应用视角来看其实压根就不需要复杂的三层架构去支撑，云内核+云驱动，**系统之上皆为应用。** + +### 化整为零 + +Sealos 可以精简到只剩一个裸 kubernetes，也可以装成千上万个应用，可以跑在电视盒子上，也可以运行在数万台服务器的数据中心，想想优秀的 linux 是不是也是这样，可以运行在嵌入式设备上也可以运行在最大的数据中心，这就是一种化整为零的架构，可以做到恰好满足你的需求，而不是堆了一大堆你不需要的能力。 + +只有这种架构才能做到无限扩展。 + +### 自由组装 + +内聚精简的架构就可以根据自己的需求来做组装，让你的云多一分则嫌多，少一分则嫌少。这得益于高度抽象的能力，具体功能通过应用本身去实现，而[云操作系统](https://sealos.run)本身对下只需要池化资源，对上只需要管理好应用即可，这样即便整个生态几十万应用出现也不会增加你的云的复杂度。参考你是怎么用智能手机的，云也可以这样玩。 + +## 使用场景 + +### 直接使用 Sealos 提供的云服务 + +- 任何的业务组件能 build 成 docker 镜像的就能很轻松跑在 Sealos 上 (后面当然会有 AI 帮助完成镜像构建，什么 Docker 我不懂)，比如企业内部各种编程语言写的项目。 +- 四大数据库高可用集群一键启动 pgsql/mysql/mongo/redis，备份/恢复/监控/管控应有仅有。 +- 各种知名开源项目都可运行在 Sealos 上。 + +所以可以很好的在 Sealos 上运行你的业务系统，解决了业务运行时问题和所有后端依赖。 + +### 帮助你构建完整的私有云 + +大家可能越来越发现裸硬件不仅比虚拟机性能更好，而且价格还便宜，不过还是大量公司还不会考虑托管硬件，原因就在于很难搞得定软件部分，搭 openstack？搭 kubernetes？其实都差点意思。 + +Sealos 的云服务版本可以一模一样的 clone 到你自己的机房，Sealos 目前已经服务数万在线用户了，能支持的场景和复杂度已经超过绝大多数公司了，毕竟有几万开发者的公司还是不多的。 + +所以裸机+Sealos 软硬件都有了，自建私有云这个事就成立了。 + +自建成本有多高呢？ + +- 买好服务器 +- 一条命令起集群，小白都会，管你多少台服务器都是一键 +- 最多 0.5 人维护，我们基本实现了自运维，目前在线集群服务上万应用投入的维护人力 0.1 个左右 + +## 与其他平台的比较 + +### 对比其他云原生 PaaS 平台 + +这是问的最多的，最大的区别是设计理念，Sealos 不会去做一个大而全的 PaaS 平台，[云操作系统](https://sealos.run)本身是高度抽象的，是 nothing，Sealos 上应用是一等公民，通过各种不同的应用来满足用户的需求，比如 Sealos 上 Database 应用，你在使用它时完全不用关心其他任何概念，kubernetes 单词怎么拼都不知道。 + +与追求大而全的传统 PaaS 平台不同，Sealos 把[云操作系统](https://sealos.run)视为高度抽象化的 “nothing”，强调应用程序的重要性。在 Sealos 平台上，**应用被视为第一等公民**，通过多样化的应用来满足用户的各种需求。例如，使用 Sealos 的数据库应用时，用户无需关注任何其他概念，**甚至不需要知道如何拼写 “Kubernetes”**。 + +Rancher 和 KubeSphere 是非常优秀的 PaaS 平台。但 Sealos 并不将 K8s 作为其核心目的。它更注重于 K8s 上运行的应用，而非 K8s 本身。因此，Sealos 的目标用户是广泛的开发者群体，其意图是打造一个通用性操作系统，不局限于仅服务于云原生领域。Sealos 甚至都不太想强调 “云原生” 这一尚未明确定义的概念。 + +因此，Sealos 的核心思想并非是 “更好用的 Kubernetes”，而是 “**利用 K8s 为用户提供所需的应用**”。 + +> 用户真正需要的是什么？ +> + +在操作系统领域，用户的需求定义了系统的功能。操作系统的灵活性意味着它不会给用户带来额外负担。例如，Windows 对于游戏玩家而言是游戏平台，对程序员则是编程工具，对美工来说则是图像处理软件。操作系统的形态由使用者决定，取决于装载了哪些应用。Sealos 也秉承这样的设计理念，因此不同用户的体验将截然不同。 + +### 对比各种 K8s 安装工具 + +安装只是整个操作系统的一个 boot 功能，不过 Sealos 在集群生命周期管理和应用打包交付上也有极大的特色。 + +首先，Sealos 通过一条命令即可完成安装。其次，利用集群镜像，可以将整个集群打包并随处交付。最后，Sealos 允许用户像编写 Dockerfile 一样灵活地定制所需的集群，自由组装和替换镜像中的组件，提供了上百种组件供用户选择。 + +## 总结 + +Sealos 社区现在拥有庞大的社区用户基础，发展了很多年，久经沙场，稳定性在各种极端场景下久经考验，稳如老狗。 + +我们云服务注册用户和应用数量也在夸张级别的增长，上线两周超 6k 在线开发者，近万应用数量。 + +我们会为用户提供一个公有云私有云体验完全一致，简单，便宜，开放，强大的[云操作系统](https://sealos.run)。 \ No newline at end of file