查看 Secret - 每天5分钟玩转 Docker 容器技术(156)

可以通过 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.《每天5分钟玩转Docker容器技术》
https://item.jd.com/16936307278.html

3.《每天5分钟玩转OpenStack》
https://item.jd.com/12086376.html

原文地址:http://blog.51cto.com/cloudman/2104670

时间: 2024-10-03 15:47:53

查看 Secret - 每天5分钟玩转 Docker 容器技术(156)的相关文章

通过案例学习 Secret - 每天5分钟玩转 Docker 容器技术(110)

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

volume 方式使用 Secret - 每天5分钟玩转 Docker 容器技术(157)

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

Secret 的使用场景 - 每天5分钟玩转 Docker 容器技术(109)

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

用 ConfigMap 管理配置 - 每天5分钟玩转 Docker 容器技术(159)

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

运行第一个 Service - 每天5分钟玩转 Docker 容器技术(96)

上一节我们创建好了 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?- 每天5分钟玩转 Docker 容器技术(99)

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

神奇的 routing mesh - 每天5分钟玩转 Docker 容器技术(100)

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

如何滚动更新 Service?- 每天5分钟玩转 Docker 容器技术(102)

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

用 Label 控制 Service 的位置 - 每天5分钟玩转 Docker 容器技术(106)

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