{"id":13451506,"url":"https://github.com/ibuildthecloud/k3v","last_synced_at":"2026-01-12T06:52:42.547Z","repository":{"id":144200636,"uuid":"196784369","full_name":"ibuildthecloud/k3v","owner":"ibuildthecloud","description":"Virtual Kubernetes","archived":false,"fork":false,"pushed_at":"2019-09-16T11:01:55.000Z","size":19712,"stargazers_count":684,"open_issues_count":4,"forks_count":28,"subscribers_count":27,"default_branch":"master","last_synced_at":"2024-10-28T18:15:41.459Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/ibuildthecloud.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null}},"created_at":"2019-07-14T02:17:04.000Z","updated_at":"2024-10-05T07:05:19.000Z","dependencies_parsed_at":"2024-01-14T09:58:39.584Z","dependency_job_id":"9aebcf68-f3a0-42e5-84c3-f39f6ea83b23","html_url":"https://github.com/ibuildthecloud/k3v","commit_stats":null,"previous_names":[],"tags_count":1,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ibuildthecloud%2Fk3v","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ibuildthecloud%2Fk3v/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ibuildthecloud%2Fk3v/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ibuildthecloud%2Fk3v/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/ibuildthecloud","download_url":"https://codeload.github.com/ibuildthecloud/k3v/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":245149795,"owners_count":20568974,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-07-31T07:00:54.939Z","updated_at":"2025-03-23T18:32:42.997Z","avatar_url":"https://github.com/ibuildthecloud.png","language":"Go","funding_links":[],"categories":["Go"],"sub_categories":[],"readme":"k3v - Virtual Kubernetes\n========\n\n**STATUS: Proof Of Concept**\n\nk3v runs as a dedicated virtual Kubernetes control plane.  When pods are\nlaunched they are launched in another cluster.  k3v uses the compute,\nstorage, and networking resources from a real Kubernetes cluster. This\nallows one to take one physical Kubernetes cluster and chop it up into\nsmaller virtual clusters. Also, it is theoretically possible that one\nvirtual cluster spans multiple physical clusters.\n\n## Quick Start\n\nPlease note, this is POC quality stuff. \n\n1. Download k3v binary from the releases page.\n    ***NOTE: While Windows and macOS binaries are available they probably won't work.***\n2. Run k3v pointing to a kubeconfig file of your physical cluster.\n    ```sh\n    ./k3v --kubeconfig someconfig.yaml\n    ```\n   If you kube config is in the standard `$HOME/.kube/config` then no\n   argument is needed.\n3. Once started k3v will create a local folder `./k3v-data` that has the\n   virtual kubernetes state.  Also `./kubeconfig.yaml` will be created.\n4. Use `./kubeconfig.yaml` to talk to k3v\n    ```sh\n   kubectl --kubeconfig ./kubeconfig.yaml --all-namespaces=true get all\n    ```\n\n## Benefits\n\nThe reasons for experimenting with virtual clusters are\n\n1. Better security/multitenancy\n2. Better separation of concerns between infra and custom controllers (operators) \n3. Ability to package complex k8s based applications\n\n### Security\n\nVirtual clusters can help create a better model for hard multi tenancy.\n\nMultitenancy in Kubernetes is hard for multiple reasons.  First you must\ntrust the security of a container.  Meaning that one bad neighbor can't\nattack another neighbor. Virtual clusters does not help with this concern.\nTo address this you need to trust containers or leverage another technology\nlike gvisor or katacontainers.  The second and more fundamental issue is\nthat the attach surface of Kubernetes is far to large for multitenancy.  Right\nnow the only way to accomplish multi tenancy is to not allow users to do the\nvast majority of Kubernetes operations.  It is far too difficult to ensure that\nall the various APIs will not expose some issue.  But limiting access means\nan end user can't leverage a lot of functionality of Kubernetes, such as\noperators.\n\nVirtual clusters allow you to separate out the problem into two distinct layers.\nFirst you need a secure and very limited physical cluster.  A virtual cluster only\nrequires very basic CRUD privileges on pods, services, endpoints, configmap,\nsecrets, and pvcs. It is far easier to secure this small set of APIs. Then\ntenants can be given access to a virtual kubernetes instance and given full\ncluster admin privileges.  They can do whatever they want with Kubernetes and\nyou can be confident they won't impact another neighbor.\n\n### Separation of Concerns\n\nKubernetes is a great architecture that allows one to write things such as\noperators or controllers to manage your infrastructure.  Unfortunately each\noperator or controller you add to a cluster could have larger impacts on the\ncluster.  Today, if you want an operator, really a cluster admin must install\nthat for you.  And more importantly, the cluster admin must have confidence\nthe operator won't do harm to the cluster.  This is not a scalable model.\n\nWith virtual clusters you can setup large, rather boring physical clusters. One\nteam can be responsible for the core uptime of this cluster.  Then each virtual\ncluster can install operators or any random component as they wish, with a high\ndegree of confidence that if something goes wrong it only impacts this one\nvirtual cluster.\n\n### Kubernetes Based App Packaging\n\nIf you write a complex Kubernetes based application (think istio or such) one\ncould package this application in a virtual cluster and deploy it in a cluster\nmuch like a normal controller, but with no CRDs. No matter what madness that\napplication does (CRDs, finalizers, webhooks, etc) it is all nicely encapsulated.\n\n## License\nCopyright (c) 2019 [Rancher Labs, Inc.](http://rancher.com)\n\nLicensed under the Apache License, Version 2.0 (the \"License\");\nyou may not use this file except in compliance with the License.\nYou may obtain a copy of the License at\n\n[http://www.apache.org/licenses/LICENSE-2.0](http://www.apache.org/licenses/LICENSE-2.0)\n\nUnless required by applicable law or agreed to in writing, software\ndistributed under the License is distributed on an \"AS IS\" BASIS,\nWITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.\nSee the License for the specific language governing permissions and\nlimitations under the License.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fibuildthecloud%2Fk3v","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fibuildthecloud%2Fk3v","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fibuildthecloud%2Fk3v/lists"}