这是一个创建于 142 天前的主题，其中的信息可能已经有所发展或是发生改变。
之前项目一直是 docker compose up -d 启动的，后面发现有很多权限上的问题，如何低成本切换成 k8s+podman ，最好是不用动代码
目前 docker compose 里面服务有 7 个 前端、后端、pg 、redis 、mongo 、minio 、rabbitmq
 |
1
dream4ever 142 天前
先说说你的具体需求，有时候你思考一番之后提出一个问题 X ，其实是为了解决背后的这个问题 Y ，但是很可能要解决 Y 并不一定需要解决问题 X 。
|
 |
2
ysicing 142 天前
换个运行方式貌似也不能解决权限问题吧
|
 |
3
HashV2 OP @dream4ever 第一：我们有一个接口会 run 一些 sudo 命令 给容器加了 privileged=true, 怕会有安全风险
第二：是容器之间的文件通信/传输问题，之前服务之间交互的时候有一个共享的文件夹，我是-v 映射过来的，然后另一个容器读取文件的时候没权限，我手动 chmod 后解决的，后面加了 minio 对象存储之后倒是规避了这个问题，但是看了一些文章之后总觉得 docker 的可靠性有些低，所以想切换成 podman |
 |
4
wangbin11 142 天前
崩没崩，没蹦别动，崩了再说，找个大佬入职
|
 |
5
liuzhedash 142 天前
|
|
6
HashV2 OP |
 |
7
bt7vip 142 天前 via Android
K8s 现在分离成使用接口调度容器，如果只是迁移 k8s ，有完善的文档参考。
如果是为了 podman 的非运行 root 容器，需要自己配置一番，无守护进程的好处是真的容器封装成一个 server ，就像管理 server 那样操作容器，坏处是相对成熟的 docker 配置难度提升。 |
 |
8
582033 141 天前
切 k8s 对你自己有啥积极作用么？能加薪或者保狗头那就切；不然能稳定跑着就别动它
|
 |
9
julyclyde 141 天前
@HashV2
sudo 和 priviledged 没什么关系啊，容器内 sudo 那是容器内的事 容器之间共享文件，你应该考虑一下是不是设计有错误 一般不提倡用文件系统做 IPC ，而应该用流式的通信技术，存在“顺序”和“流量控制”的概念 古代版本 docker 是直接管理容器的；后来改成 dockerd+containerd+containerd-shim 三层了，所以不存在 docker 挂了就全挂了这个问题 |
 |
10
wbuntu 141 天前
感觉没有必要，只是换了一种方式运行服务，而且 podman 也并没有 docker 可靠，你的问题不是更换成 k8s+podman 可以解决的
|
|
12
wbuntu 139 天前
@julyclyde 我们的生产环境在大量使用 podman 相关的工具链......从当前的时间点看 podman 的工具链成熟度还没有达到 docker 的水平，很多时候要换回来使用 docker
|
|
14
wbuntu 139 天前
@julyclyde 有很多一言难尽的地方，比如对操作系统支持不全，需要比较新的操作系统才能用上 4.0 ，构建出的镜像默认是 oci 格式，多架构镜像构建没有类似 docker 的 buildx ，很多时候客户预期的是 docker 的使用体验，但是 podman 没有完全满足。
|
 |
17
winson030 114 天前
如果你只是想将现有的服务在 k8s 集群上跑起来，那么你需要考虑下面的问题。
1. 数据卷如何处理？ 存在宿主机还是用 nfs ？ 2. 网络如何处理？镜像除了前端还有哪些需要暴露到公网的？ 3. 配置文件如何处理？ 4. 密码，证书之类的信息如何处理？ 5. 环境变量怎么处理？ 你可以试试使用 kcompose 将 docker compose 转换为 k8s 能用的 yaml 文件。 k8s 的操作逻辑跟 docker compose 不太一样，需要有针对性地进行修改。镜像倒是不用变。 k8s 麻烦的话，可以试试 docker swarm 集群。只需要在原有的 compose 文件里加入一些代码， 然后 docker stack up 就可以了。 |
Select Language