{"id":15127506,"url":"https://github.com/tjfontaine/podspec2linuxkit","last_synced_at":"2026-02-19T06:01:57.440Z","repository":{"id":57557052,"uuid":"157476757","full_name":"tjfontaine/podspec2linuxkit","owner":"tjfontaine","description":"Create immutable machine images from Kubernetes Manifests","archived":false,"fork":false,"pushed_at":"2018-12-13T18:51:07.000Z","size":2419,"stargazers_count":2,"open_issues_count":0,"forks_count":0,"subscribers_count":2,"default_branch":"master","last_synced_at":"2025-10-22T21:53:57.037Z","etag":null,"topics":["docker-container","kubernetes","kubernetes-manifests","linuxkit","machine-image"],"latest_commit_sha":null,"homepage":"","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/tjfontaine.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}},"created_at":"2018-11-14T02:15:01.000Z","updated_at":"2022-11-21T13:39:32.000Z","dependencies_parsed_at":"2022-09-07T17:51:38.397Z","dependency_job_id":null,"html_url":"https://github.com/tjfontaine/podspec2linuxkit","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/tjfontaine/podspec2linuxkit","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tjfontaine%2Fpodspec2linuxkit","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tjfontaine%2Fpodspec2linuxkit/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tjfontaine%2Fpodspec2linuxkit/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tjfontaine%2Fpodspec2linuxkit/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/tjfontaine","download_url":"https://codeload.github.com/tjfontaine/podspec2linuxkit/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tjfontaine%2Fpodspec2linuxkit/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":29604552,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-02-19T05:11:50.834Z","status":"ssl_error","status_checked_at":"2026-02-19T05:11:38.921Z","response_time":117,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.5:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"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":["docker-container","kubernetes","kubernetes-manifests","linuxkit","machine-image"],"created_at":"2024-09-26T02:04:41.786Z","updated_at":"2026-02-19T06:01:57.410Z","avatar_url":"https://github.com/tjfontaine.png","language":"Go","funding_links":[],"categories":[],"sub_categories":[],"readme":"# PodSpec2LinuxKit\n\n`podspec2linuxkit` will translate a `Deployment`, `ReplicaSet`, `DaemonSet`,\n`Pod` or similar manifest for Kubernetes into a\n[LinuxKit](https://github.com/linuxkit/linuxkit) image manifest. The resulting\nimage manifest can be built with `linuxkit build` and run on the infrastructure\nprovider of your choosing (either supported by `linuxkit run` or by importing\nthe image or using the iso as you see fit). Raising the question, \"do you really\nneed all of Kubernetes?\" or perhaps \"do you need the kubelet?\"\n\n## Usage\n\n```bash\n$ git clone https://github.com/tjfontaine/podspec2linuxkit\n$ cd podspec2linuxkit \u0026\u0026 make\n$ ./podspec2linuxkit \u003c my-deployment.yaml \u003e my-linuxkit.yaml\n$ linuxkit build -format iso-efi -name my-image -dir ./out templates/base_image.yaml ./my-linuxkit.yaml\n$ linuxkit run hyperkit -publish 18080:80 -iso -uefi ./out/my-image\n```\n\n## Base Image\n\nThe tool itself does not produce a standalone manifest that can be used for\nbuilding a LinuxKit image. However, by leveraging how LinuxKit can merge\nmultiple yaml files to produce the build, you can use the files in `templates`\nwith the resulting manifest, or use them as a starting point.\n\n## Caveats\n\nNearly everything you can represent in a `PodSpec` has a direct translation for\nthe LinuxKit image manifest. You can have multiple containers, init containers,\nresource limits, environment variables, mount propagation, security context, and\nvolumes (see supported volume types).\n\nThat being said, there are some things that are currently not possible with this\ntool as is.\n\n### External References\n\nManifest that refer to values stored in other manifests won't work. So things\nlike `valueFrom` or `envFrom` can't work because they're not defined in the same\nmanifest.\n\nThere are at least two ways we can solve the missing values, we could evolve the\ntool to interpret multiple manifests at once such that it could attempt to\ndereference all the appropriate values. Alternatively the tool could connect to\na running Kubernetes cluster and try and dereference the values. It does neither\nfor now.\n\n### Ports\n\n`ports` definitions are currently ignored. Having a pattern to firewall the host\nnetwork namespace by default and allow communication in would be ideal, but\ndoesn't exist yet -- so make sure you're ready for traffic to all your\ncontainers.\n\n### Supported Volume Types\n\nCurrently only `hostPath` and `emptyDir` are implemented, though things like\n`nfs` and `iscsi` should be relatively straight forward to add.\n\n`persistentVolumeClaim` is *not* currently supported for the \"External\nReferences\" reason above, but is likely the most desirable option to add.\n\nAll the vendor related and external volumes are feasible, they just require some\namount of effort by those who wish to support them.\n\n### Anything Relating to Scheduling\n\nA lot of what's in the `PodSpec` is really only germane to the Kubernetes\nscheduler responsible for the type of pod in question. They don't have an analog\nin LinuxKit, so they're not included at all.\n\n## Why does this tool exist?\n\nIf you are already packaging your software in Docker/OCI compatible containers,\nand you're defining Kubernetes manifests as well, why bother with this tool at\nall?\n\nThat's a tough, but fair, question.\n\nFirst, I have a bit of a geek crush on LinuxKit, and I wanted an interesting way\nto demonstrate its value. It expands on what made `docker` the tool powerful for\ncreating container images through a declarative model and uses it to create\nimmutable machine images (by stitching together multiple container images).\n\nSpeaking of immutability, I find it slightly hypocritical that many of us\nespouse the ethos of immutable infrastructure, but we put the `kubelet` on a\nfairly stateful image. So with these images, you get something that behaves a\nbit more like a container instance (ACI/Fargate) without needing the\ninfrastructure platform to support it.\n\nBut really, often I see many teams struggling with Kubernetes as it relates to\nisolation. This isn't just about isolation for security, but about resource and\nfault isolation.\n\nIn the beginning, teams start by just deploying pods, replicasets, or\ndeployments without much care. Then failures start happening, either because of\nmemory/disk usage, or because the scheduler allowed multiple instances of the\nsame pod to be scheduled to the same node. As a result, teams then go through\nand set their affinity, or use labels and taints to limit what pods can run on\nwhich nodes.\n\nEffectively if you adopted Kubernetes because you thought it would reduce your\ncognitive or operational load by not having to think as much about\ninfrastructure, you're probably pretty disenfranchised at this point.\n\nTo be clear, this tool doesn't really solve much of that problem. But if your\nproblem ends up being infrastructure, why not just rely on an infrastructure\nprovider to be responsible for scheduling and keeping it running? This tool lets\nyou keep building your applications as containers, and defining their\nrelationships with Kubernetes manifesets, and then you can use LinuxKit to build\nimages you use with your infrastructure provider.\n\n## So what about all that life cycle management then?\n\nWell, if you mean \"how can I get Kubernetes' features with Kubernetes' manifests\nwithout using Kubernetes?\" I don't really have an answer for you.\n\nIf on the other hand, your question is, \"how can I do deployments with these\nimages, or health checking, or ...\" then I would say, you should probably check\nout [Spinnaker](https://spinnaker.io), which probably has many of the features\nyou're looking for and works with a variety of cloud providers.\n\nOne _could_ imagine however, a world where there was a frontend that \"felt\" like\nKuberentes, that when given a manifest built an image and then used Spinnaker to\nmanage the deployment ... but so far as I know it doesn't exist yet.\n\n### PS\n\nI'm not a golang expert, so go easy on my usage :)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ftjfontaine%2Fpodspec2linuxkit","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Ftjfontaine%2Fpodspec2linuxkit","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ftjfontaine%2Fpodspec2linuxkit/lists"}