docker compose 启动的项目如何切成 k8s podman

先说说你的具体需求，有时候你思考一番之后提出一个问题 X ，其实是为了解决背后的这个问题 Y ，但是很可能要解决 Y 并不一定需要解决问题 X 。

换个运行方式貌似也不能解决权限问题吧

@dream4ever 第一：我们有一个接口会 run 一些 sudo 命令 给容器加了 privileged=true, 怕会有安全风险
第二：是容器之间的文件通信/传输问题，之前服务之间交互的时候有一个共享的文件夹，我是-v 映射过来的，然后另一个容器读取文件的时候没权限，我手动 chmod 后解决的，后面加了 minio 对象存储之后倒是规避了这个问题，但是看了一些文章之后总觉得 docker 的可靠性有些低，所以想切换成 podman

崩没崩，没蹦别动，崩了再说，找个大佬入职

@HashV2
docker 可靠性低这个怎么说？
看起来，文件权限 chmod 这些都已经被 minio 解决了，现在问题就是 privileged=true 这一个了？

@liuzhedash 未雨绸缪吧，看了一些文章

一个就是上面那个问题怕有安全风险
二是守护进程的问题，docker 挂了就全挂了，podman 没有守护进程，给人感觉上 docker 的可靠性就低了

K8s 现在分离成使用接口调度容器，如果只是迁移 k8s ，有完善的文档参考。
如果是为了 podman 的非运行 root 容器，需要自己配置一番，无守护进程的好处是真的容器封装成一个 server ，就像管理 server 那样操作容器，坏处是相对成熟的 docker 配置难度提升。

切 k8s 对你自己有啥积极作用么？能加薪或者保狗头那就切；不然能稳定跑着就别动它

@HashV2

sudo 和 priviledged 没什么关系啊，容器内 sudo 那是容器内的事

容器之间共享文件，你应该考虑一下是不是设计有错误
一般不提倡用文件系统做 IPC ，而应该用流式的通信技术，存在“顺序”和“流量控制”的概念


古代版本 docker 是直接管理容器的；后来改成 dockerd+containerd+containerd-shim 三层了，所以不存在 docker 挂了就全挂了这个问题

感觉没有必要，只是换了一种方式运行服务，而且 podman 也并没有 docker 可靠，你的问题不是更换成 k8s+podman 可以解决的

@wbuntu 那么，podman 没有 docker 可靠的结论又是怎么推断出来的呢？

@julyclyde 我们的生产环境在大量使用 podman 相关的工具链......从当前的时间点看 podman 的工具链成熟度还没有达到 docker 的水平，很多时候要换回来使用 docker

@wbuntu 嗯，那你应该列举这个理由啊，这个理由连我都同意（我遇到了 podman-composer 的问题）
但如果你不说出来，感觉就是无脑黑了

@julyclyde 有很多一言难尽的地方，比如对操作系统支持不全，需要比较新的操作系统才能用上 4.0 ，构建出的镜像默认是 oci 格式，多架构镜像构建没有类似 docker 的 buildx ，很多时候客户预期的是 docker 的使用体验，但是 podman 没有完全满足。

@wbuntu 不太明白这个 4.0 的兼容问题是咋回事

OCI 格式我觉得没啥问题啊……那是客户预期的错误

podman 我用的少，还没遇到这么多糟心事呢。唉

@julyclyde 用一用 openshift container platform 就可以感受下，如果是上红帽全家桶会觉得用起来还不错

如果你只是想将现有的服务在 k8s 集群上跑起来，那么你需要考虑下面的问题。

1. 数据卷如何处理？ 存在宿主机还是用 nfs ？
2. 网络如何处理？镜像除了前端还有哪些需要暴露到公网的？
3. 配置文件如何处理？
4. 密码，证书之类的信息如何处理？
5. 环境变量怎么处理？

你可以试试使用 kcompose 将 docker compose 转换为 k8s 能用的 yaml 文件。
k8s 的操作逻辑跟 docker compose 不太一样，需要有针对性地进行修改。镜像倒是不用变。
k8s 麻烦的话，可以试试 docker swarm 集群。只需要在原有的 compose 文件里加入一些代码，
然后 docker stack up 就可以了。