可以通过 kubectl get secret 查看存在的 secret. 显示有两个数据条目,kubectl describe secret 查看条目的 Key: 如果还想查看 Value,可以用 kubectl edit secret mysecret: 然后通过 base64 将 Value 反编码: 下节学习如何在 Pod 中使用 Secret. 书籍: 1.<每天5分钟玩转Kubernetes>https://item.jd.com/26225745440.html 2.<每天…

在下面的例子中,我们会部署一个 WordPress 应用,WordPress 是流行的开源博客系统. 我们将创建一个 MySQL service,将密码保存到 secret 中.我们还会创建一个 WordPress service,它将使用 secret 连接 MySQL.这个例子将展示如何用 secret 避免在 image 中存放敏感信息,或者在命令行中直接传递敏感数据. 实验步骤如下: 创建 secret 创建 secret 存放 MySQL 的管理员密码. openssl rand -b…

Pod 可以通过 Volume 或者环境变量的方式使用 Secret,今天先学习 Volume 方式. Pod 的配置文件如下所示: ① 定义 volume foo,来源为 secret mysecret. ② 将 foo mount 到容器路径 /etc/foo,可指定读写权限为 readOnly. 创建 Pod 并在容器中读取 Secret: 可以看到,Kubernetes 会在指定的路径 /etc/foo 下为每条敏感数据创建一个文件,文件名就是数据条目的 Key,这里是 /etc/foo…

通过 Volume 使用 Secret,容器必须从文件读取数据,会稍显麻烦,Kubernetes 还支持通过环境变量使用 Secret. Pod 配置文件示例如下: 创建 Pod 并读取 Secret. 通过环境变量 SECRET_USERNAME 和 SECRET_PASSWORD 成功读取到 Secret 的数据. 需要注意的是,环境变量读取 Secret 很方便,但无法支撑 Secret 动态更新. Secret 可以为 Pod 提供密码.Token.私钥等敏感数据:对于一些非敏感数据,比…

我们可以用 secret 管理任何敏感数据.这些敏感数据是容器在运行时需要的,同时我们不又想将这些数据保存到镜像中. secret 可用于管理: 用户名和密码. TLS 证书. SSH 秘钥. 其他小于 500 KB 的数据. secret 只能在 swarm service 中使用.普通容器想使用 secret,可以将其包装成副本数为 1 的 service. 这里我们再举一个使用 secret 的典型场景. 数据中心有三套 swarm 环境,分别用于开发.测试和生产.对于同一个应用,在不同的…

我们经常要向容器传递敏感信息,最常见的莫过于密码了.比如: docker run -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql 在启动 MySQL 容器时我们通过环境变量 MYSQL_ROOT_PASSWORD 设置了 MySQL 的管理员密码.不过密码是以明文的形式写在 docker run 命令中,有潜在的安全隐患. 为了解决这个问题,docker swarm 提供了 secret 机制,允许将敏感信息加密后保存到 secret 中,用户可以指定哪…

Secret 可以为 Pod 提供密码.Token.私钥等敏感数据:对于一些非敏感数据,比如应用的配置信息,则可以用 ConfigMap. ConfigMap 的创建和使用方式与 Secret 非常类似,主要的不同是数据以明文的形式存放. 与 Secret 一样,ConfigMap 也支持四种创建方式: 1. 通过 --from-literal: kubectl create configmap myconfigmap --from-literal=config1=xxx --from-lite…

Helm 安装成功后,可执行 helm search 查看当前可安装的 chart. 这个列表很长,这里只截取了一部分.大家不禁会问,这些 chart 都是从哪里来的? 前面说过,Helm 可以像 apt 和 yum 管理软件包一样管理 chart.apt 和 yum 的软件包存放在仓库中,同样的,Helm 也有仓库. Helm 安装时已经默认配置好了两个仓库:stable 和 local.stable 是官方仓库,local 是用户存放自己开发的 chart 的本地仓库. helm searc…

前面我们安装部署了 Rex-Ray,并且成功配置 VirtualBox backend,今天演示如何创建和使用 Rex-Ray volume. 在 docker1 或 docker2 上执行如下命令创建 volume: docker volume create --driver rexray --name=mysqldata --opt=size=2 volume mysqldata 创建成功,大小为 2GB.在 VirtualBox 宿主机中也能看到 mysqldata. 因为 Virtual…

上一节我们在 docker1 上的 MySQL 容器中使用了 Rex-Ray volume mysqldata,更新了数据库.现在容器已经删除,今天将演示在 docker2 中重新使用这个卷. 在 dokcer2 上执行如下命令,启动 MySQL 容器: docker run --name mydb_on_docker2 -v mysqldata:/var/lib/mysql -d mysql 新容器也使用相同的卷 mysqldata,不过这次不需要指定环境变量 MYSQL_ROOT_PASSW…

当 Docker 部署规模逐步变大后,可视化监控容器环境的性能和健康状态将会变得越来越重要. 在本章中,我们将讨论几个目前比较常用的容器监控工具和方案,为大家构建自己的监控系统提供参考. 首先我们会讨论 Docker 自带的几个监控子命令:ps, top 和 stats.然后是几个功能更强的开源监控工具 sysdig, Weave Scope, cAdvisor 和 Prometheus.最后我们会对这些不同的工具和方案做一个比较. Docker 自带的监控子命令 ps docker conta…

Weave Scope 的最大特点是会自动生成一张 Docker 容器地图,让我们能够直观地理解.监控和控制容器.千言万语不及一张图,先感受一下. 下面开始实践 Weave Scope. 安装 执行如下脚本安装运行 Weave Scope. curl -L git.io/scope -o /usr/local/bin/scope chmod a+x /usr/local/bin/scope scope launch scope launch 将以容器方式启动 Weave Scope. 根据提示,…

除了监控容器,Weave Scope 还可以监控 Docker Host. 点击顶部 HOSTS 菜单项,地图将显示当前 host. 与容器类似,点击该 host 图标将显示详细信息. host 当前的资源使用情况和历史曲线一览无余.除此之外也能很方便地查看 host 上运行的进程和容器列表,点击容器名字还可以打开此容器的信息页面. host 页面上部有一个按钮,点击可直接打开 host 的 shell 窗口,这个远程管理功能真的很贴心. 多主机监控 前面我们已经领略了 Weave Scope…

上一节介绍了 Prometheus 的核心,多维数据模型.本节演示如何快速搭建 Prometheus 监控系统. 环境说明 我们将通过 Prometheus 监控两台 Docker Host:192.168.56.102 和 192.168.56.103,监控 host 和容器两个层次的数据. 按照架构图,我们需要运行如下组件: Prometheus Server Prometheus Server 本身也将以容器的方式运行在 host 192.168.56.103 上. Exporter Pr…

高效的监控和日志管理对保持生产系统持续稳定地运行以及排查问题至关重要. 在微服务架构中,由于容器的数量众多以及快速变化的特性使得记录日志和监控变得越来越重要.考虑到容器短暂和不固定的生命周期,当我们需要 debug 问题时有些容器可能已经不存在了.因此,一套集中式的日志管理系统是生产环境中不可或缺的组成部分. 本章我们将讨论监控容器的各种可用技术和方案,首先会介绍 Docker 自带的 logs 子命令,然后讨论 Docker 的 logging driver,接下来通过实践学习几个已经广泛应用…

将容器日志发送到 STDOUT 和 STDERR 是 Docker 的默认日志行为.实际上,Docker 提供了多种日志机制帮助用户从运行的容器中提取日志信息.这些机制被称作 logging driver. Docker 的默认 logging driver 是 json-file. # docker info |grep 'Logging Driver'Logging Driver: json-file 如果容器在启动时没有特别指明,就会使用这个默认的 logging driver. json…

本节我们将创建三节点的 swarm 集群. swarm-manager 是 manager node,swarm-worker1 和 swarm-worker2 是 worker node. 所有节点的 Docker 版本均不低于 v1.12.我们的实验环境 node 的操作系统为 Ubuntu 16.04,当然其他 Linux 也是可以的. 在 swarm-manager 上执行如下命令创建 swarm. docker swarm init --advertise-addr 192.168.5…

上一节我们创建好了 Swarm 集群, 现在部署一个运行 httpd 镜像的 service,执行如下命令: docker service create --name web_server httpd 部署 service 的命令形式与运行容器的 docker run 很相似,--name 为 service 命名,httpd 为镜像的名字. 通过 docker service ls 可以查看当前 swarm 中的 service. REPLICAS 显示当前副本信息,0/1 的意思是 web_…

上一节部署了只有一个副本的 Service,不过对于 web 服务,我们通常会运行多个实例.这样可以负载均衡,同时也能提供高可用. swarm 要实现这个目标非常简单,增加 service 的副本数就可以了.在 swarm-manager 上执行如下命令: docker service scale web_server=5 副本数增加到 5,通过 docker service ls 和 docker service ps 查看副本的详细信息. 5 个副本已经分布在 swarm 的所有三个节点上.…

前面我们已经学习了如何部署 service,也验证了 swarm 的 failover 特性.不过截止到现在,有一个重要问题还没有涉及:如何访问 service?这就是本节要讨论的问题. 为了便于分析,我们重新部署 web_server. ① docker service rm 删除 web_server,service 的所有副本(容器)都会被删除. ② 重新创建 service,这次直接用 --replicas=2 创建两个副本. ③ 每个 worker node 上运行了一个副本. 好了,…

接上一节案例,当我们访问任何节点的 8080 端口时,swarm 内部的 load balancer 会将请求转发给 web_server 其中的一个副本. 这就是 routing mesh 的作用. 所以,无论访问哪个节点,即使该节点上没有运行 service 的副本,最终都能访问到 service. 另外,我们还可以配置一个外部 load balancer,将请求路由到 swarm service.比如配置 HAProxy,将请求分发到各个节点的 8080 端口. ingress 网络 当我…

微服务架构的应用由若干 service 组成.比如有运行 httpd 的 web 前端,有提供缓存的 memcached,有存放数据的 mysql,每一层都是 swarm 的一个 service,每个 service 运行了若干容器.在这样的架构中,service 之间是必然要通信的. 服务发现 一种实现方法是将所有 service 都 publish 出去,然后通过 routing mesh 访问.但明显的缺点是把 memcached 和 mysql 也暴露到外网,增加了安全隐患. 如果不 p…

在前面的实验中,我们部署了多个副本的服务,本节将讨论如何滚动更新每一个副本. 滚动更新降低了应用更新的风险,如果某个副本更新失败,整个更新将暂停,其他副本则可以继续提供服务.同时,在更新的过程中,总是有副本在运行的,因此也保证了业务的连续性. 下面我们将部署三副本的服务,镜像使用 httpd:2.2.31,然后将其更新到 httpd:2.2.32. 创建服务: docker service create --name my_web --replicas=3 httpd:2.2.31 将 serv…

Swarm 可以在 service 创建或运行过程中灵活地通过 --replicas 调整容器副本的数量,内部调度器则会根据当前集群的资源使用状况在不同 node 上启停容器,这就是 service 默认的 replicated mode.在此模式下,node 上运行的副本数有多有少,一般情况下,资源更丰富的 node 运行的副本数更多,反之亦然. 除了 replicated mode,service 还提供了一个 globalmode,其作用是强制在每个 node 上都运行一个且最多一个副本.…

上一节我们讨论了 Service 部署的两种模式:global mode 和 replicated mode.无论采用 global mode 还是 replicated mode,副本运行在哪些节点都是由 Swarm 决定的,作为用户我们有没有可能精细控制 Service 的运行位置呢? 答案是:能,使用 label. 逻辑分两步: 为每个 node 定义 label. 设置 service 运行在指定 label 的 node 上. label 可以灵活描述 node 的属性,其形式是 ke…

容器状态是 UP 的,应用就是健康的吗? 还真不一定!Docker 只能从容器启动进程的返回代码判断其状态,而对于容器内部应用的运行情况基本没有了解. 执行 docker run 命令时,通常会根据 Dockerfile 中的 CMD 或 ENTRYPOINT 启动一个进程,这个进程的状态就是 docker ps STATUS 列显示容器的状态.   命令显示: 有的容器正在运行,状态为 UP. 有的容器已经正常停止了,状态是 Exited (0). 有的则因发生故障停止了,退出代码为非 0,例…

什么是 stack ?在回答这个问题之前我们先回忆一下前面部署 WordPress 应用的过程: 首先创建 secret. 然后创建 MySQL service,这是 WordPress 依赖的服务. 最后创建 WordPress service. 也就是说,这个应用包含了两个 service:MySQL 和 WordPress,它们之间有明确的依赖关系,必须先启动 MySQL. 为了保证这个依赖关系,我们控制了 docker secret 和 docker service 命令的执行顺序,只不…

定义好了 stack YAML 文件,就可以通过 docker stack deploy 命令部署应用. Docker 会按照 YAML 的内容来创建各种资源.为了不重名,所有资源都会加上 stack 名称作为前缀,我们这里是 wpstack_*. 部署完成后可以通过相关命令查看各种资源的状态.   如果想更新 stack 的某些属性,直接修改 YAML 文件,然后重新部署.比如将 WordPress 的端口由 8000 改为 8888. 再次执行 docker stack deploy 命令.…

stack 将应用所包含的 service,依赖的 secret.voluem 等资源,以及它们之间的关系定义在一个 YAML 文件中.相比较手工执行命令或是脚本,stack 有明显的优势. YAML 描述的是 What,是 stack 最终要达到的状态.比如 service 有几个副本?使用哪个 image?映射的端口是什么?而脚本则是描述如何执行命令来达到这个状态,也就是 How.显而易见,What 更直观,也更容易理解.至于如何将 What 翻译成 How,这就是 Docker swarm…

据说 Google 的数据中心里运行着超过 20 亿个容器,而且 Google 十年前就开始使用容器技术. 最初,Google 开发了一个叫 Borg 的系统(现在命令为 Omega)来调度如此庞大数量的容器和工作负载.在积累了这么多年的经验后,Google 决定重写这个容器管理系统,并将其贡献到开源社区,让全世界都能受益. 这个项目就是 Kubernetes.简单的讲,Kubernetes 是 Google Omega 的开源版本. 从 2014 年第一个版本发布以来,Kubernetes 迅…