我有几个小容器,内存占用很少,流量很小 . 我认为每个人都有一个单独的吊舱是太过分和太昂贵了 .
我目前通过简单地将Docker镜像推送到OpenShift在线容器注册表来部署容器 . 一旦新图像到达,OpenShift将重建并部署应用程序 . 它工作正常,但我找不到让OpenShift接受同一应用程序/ pod的多个图像/容器的方法 .
有谁知道如何在一个应用程序/ pod中运行多个容器?
我不知道在创建多个pod时你有什么样的缺点 . Pod与容器的开销可以忽略不计 .
但是将多个应用程序放入单个pod中显然存在缺点:
如果要重新启动单个容器,则需要重新启动所有容器
您无法单独扩展容器,因此您无法获得不同的服务数(对于HA或负载分配)
您必须按端口识别服务,因为服务发现适用于每个Pod
即 . 拥有多个HTTP服务,您可以将它们全部映射到端口80并使用 http://fooservice 和 http://barservice 而不是 http://uberpod:8001 和 http://uberpod:8002
http://fooservice
http://barservice
http://uberpod:8001
http://uberpod:8002
同样,几乎没有多个Pod的开销 .
我不知道Kubernetes在OpenShift中的集成是如何工作的,但是使用普通的Kubernetes YAML文件,你可以在容器列表中添加另一个容器:
apiVersion: v1 kind: Pod metadata: name: myapp-pod labels: app: myapp spec: containers: - name: foo image: busybox command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600'] - name: bar image: mycontainer:latest
鉴于每个pod或服务都使用IP,而在kubernetes中,每个CPU核心建议限制为10个pod,因此每个pod有多个容器用于微服务绝对是个好主意 .
在Openshift Online中,您的命名空间将限制POD的数量 .
此外,你可以为一个pod提供多种服务......但我不建议它,因为它也使用IP ....和证书,如果你需要一个,....
您可以通过对其进行请求和限制来管理容器的内存 . 我想如果你没有限制,容器配置自己的默认值 . 但是如果你设置限制,容器初始化应该考虑到这一点 . (这是Redhat提供的容器的情况) .
对于缩放:您应该根据缩放需要以智能方式将容器分组到pod中 . 在某些情况下,它可能意味着一个容器用于一个容器 . 但如果只消耗0.0001%CPU则不行 . 如果你需要扩展,它应该意味着你需要比核心的10%更多的CPU .
要重新启动容器,您可能需要重新启动POD . 并非总是如此,它可以是透明的:为什么要重新启动容器?
容器中的错误?活动检查可以为您解决这个问题...我认为它是在容器级别 .
在准备检查的帮助下升级容器's image, a trigger can restart the pod, which will be transparent for application'的用户 .因此,我认为这不足以要求1个容器/容器 .
2 回答
我不知道在创建多个pod时你有什么样的缺点 . Pod与容器的开销可以忽略不计 .
但是将多个应用程序放入单个pod中显然存在缺点:
如果要重新启动单个容器,则需要重新启动所有容器
您无法单独扩展容器,因此您无法获得不同的服务数(对于HA或负载分配)
您必须按端口识别服务,因为服务发现适用于每个Pod
即 . 拥有多个HTTP服务,您可以将它们全部映射到端口80并使用
http://fooservice
和http://barservice
而不是http://uberpod:8001
和http://uberpod:8002
同样,几乎没有多个Pod的开销 .
我不知道Kubernetes在OpenShift中的集成是如何工作的,但是使用普通的Kubernetes YAML文件,你可以在容器列表中添加另一个容器:
鉴于每个pod或服务都使用IP,而在kubernetes中,每个CPU核心建议限制为10个pod,因此每个pod有多个容器用于微服务绝对是个好主意 .
在Openshift Online中,您的命名空间将限制POD的数量 .
此外,你可以为一个pod提供多种服务......但我不建议它,因为它也使用IP ....和证书,如果你需要一个,....
您可以通过对其进行请求和限制来管理容器的内存 . 我想如果你没有限制,容器配置自己的默认值 . 但是如果你设置限制,容器初始化应该考虑到这一点 . (这是Redhat提供的容器的情况) .
对于缩放:您应该根据缩放需要以智能方式将容器分组到pod中 . 在某些情况下,它可能意味着一个容器用于一个容器 . 但如果只消耗0.0001%CPU则不行 . 如果你需要扩展,它应该意味着你需要比核心的10%更多的CPU .
要重新启动容器,您可能需要重新启动POD . 并非总是如此,它可以是透明的:为什么要重新启动容器?
容器中的错误?活动检查可以为您解决这个问题...我认为它是在容器级别 .
在准备检查的帮助下升级容器's image, a trigger can restart the pod, which will be transparent for application'的用户 .
因此,我认为这不足以要求1个容器/容器 .