前言 你可能已经听过很多遍这个不算秘密的秘密了--Kubernetes Secrets 不是加密的！Secret 的值是存储在 etcd 中的 base64 encoded（编码） 字符串。这意味着，任何可以访问你的集群的人，都可以轻松解码你的敏感数据。任何人？是的，几乎任何人都可以，尤其是在集群的
 # 背景 在做传统业务开发的时候，当我们的服务提供方有多个实例时，往往我们需要将对方的服务列表保存在本地，然后采用一定的算法进行调用；当服务提供方的列表变化时还得及时
背景 前两章中我们将应用部署到了 k8s 中，同时不同的服务之间也可以通过 service 进行调用，现在还有一个步骤就是将我们的应用暴露到公网，并提供域名的访问。 这一步类似于我们以前配置 Nginx 和绑定域名，提供这个能力的服务在 k8s 中成为 Ingress。 通过这个描述其实也能看出 I
Kubernetes （K8s）是现代云原生世界中的容器管理平台。它实现了灵活、可扩展地开发、部署和管理微服务。K8s 能够与各种云提供商、容器运行时接口、身份验证提供商和可扩展集成点一起工作。然而 K8s 的集成方法可以在任何基础设施上运行任何容器化应用程序，这使得围绕 K8s 和其上的应用程序堆
在之前的应用部署系列文章里，我们已经介绍过什么是蓝绿部署。如需回顾，点击下方文章链接即可重温。本文我们将会介绍如何使用 Kubernetes 实现蓝绿部署。 应用部署初探：3个主要阶段、4种常见模式 应用部署初探：微服务的3大部署模式 应用部署初探：6个保障安全的最佳实践 前期准备： Kuberne
Docker Image 推到阿里云仓库，可以看 SpringBoot Docker 发布到 阿里仓库 1. 阿里镜像仓库加了授权，所以 K8S 拉之前要做下授权处理 [root@k8smaster ~]# kubectl create secret docker-registry registry
创建部署详见 Kubernetes(K8S) Deployment 部署 Pod 传统应用升级，一般是V1.0的jar包，有一个应对 1.0 的 shell 启动脚本。升级时，传 2.0 的 jar包，配置 2.0 的 shell 脚本。 执行顺序为，停1.0的服务，启2.0的服务，有问题时，把2.
镜像仓库，镜像已更新，版本没更新， K8S 拉取后，还是早的服务，原因：imagePullPolicy 镜像拉取策略 默认为本地有了就不拉取，需要修改 [root@k8smaster ~]# kubectl edit deployment/javademo1 ..... spec: containe
kubectl top (metrics-server) node NotFound components.yaml 网上的各种方法都有问题，找到了一个完整版的 yaml apiVersion: v1 kind: ServiceAccount metadata: labels: k8s-app: m
原因，数据库为 MySQL 5.7 需要在yaml加上参数 mysql.db.param: "characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true&useSSL=false&serverTim
Kubernetes(K8S) 配置静态资源服务 apiVersion: v1 kind: ConfigMap metadata: name: img-config namespace: vipsoft data: img.conf: | server { charset utf-8; listen
Master Api Server 统一入口，以 Restful 方式，交给 etcd 存储 Scheduler 节点调试，选择 Node 节点，做应用部署 Controller Manager 处理集群中常规后台任务，一个资源对应一个控制器 etcd 存储系统，用于保存集群相关的数据 Node k
Docker 常用命令 Docker 常用命令 # 查看API版本 [root@k8smaster ~]# kubectl api-versions # 重启 K8S [root@k8smaster ~]# systemctl restart kubelet # 查看 kubelet 状态 [roo
使用空格做为缩进 缩进的空格数目不重要， 只要相同层级的元素左侧对齐即可 低版本缩进时不允许使用 Tab 键， 只允许使用空格 使用#标识注释， 从这个字符一直到行尾， 都会被解释器忽略 使用 三个 - 进行多项配置 | | | | | | | apiVersion | API版本 可以用 kube
Pod 是 k8s 系统中可以创建和管理的最小单元， 是资源对象模型中由用户创建或部署的最小资源对象模型， 也是在 k8s 上运行容器化应用的资源对象， 其他的资源对象都是用来支撑或者扩展 Pod 对象功能的， 比如控制器对象是用来管控 Pod 对象的， Service 或者Ingress 资源对象
定义一组 Pod 的访问规则 存在的意义 防止 Pod 失联（服务发现），Pod 重启后，IP会变 定义一组 Pod 访问策略，负载均衡 Pod 和 Service 关系 根据 label 和 selector 标签建立关联，实现 Pod 的负载均衡和服务发现，Service 或者Ingress 资
什么是controller 实际存在的，管理和运行容器的对象 Pod 和 Controller 关系 Pod 是通过 Controller 实现应用的运维，比如伸缩、滚动升级等等 Pod 和 Controller 之间通过 label 标签建立关系 Deployment 控制器应用场景 场景：Web
无状态和有状态 无状态 Deployment 认为Pod 都是一样的。javademo1-6fb64c4664-dj4dh、javademo1-6fb64c4664-dj54s 它们的内容是一样的。 没有顺序要求，先启第一个还是启第二个无所谓 不用考虑在哪个 node 上运行 随意进行伸缩和扩展 有
Secret 作用：加密数据(base64)存在 etcd 里面，让 Pod 容器以挂载 Volume 方式进行访问 场景：凭证 [root@k8smaster ~]# echo -n 'admin' | base64 # 创建 secret [root@k8smaster ~]# kubectl
作用：存储不加密数据到 etcd，让 Pod 以变量或者 Volume 挂载到容器中 场景：配置文件 创建配置文件 redis.properties redis.host=127.0.0.1 redis.port=6379 redis.password=123456 创建 ConfigMap # 根
