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