小楼一夜听春雨，深巷明朝卖杏花

apiVersion: v1kind: ConfigMapmetadata: name: java-demo-configdata: application.yml: | server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/test?characterEncoding=utf-8 .

ConfigMaps 和 Secret 资源的创建和使用； Pod 身份认证的实现和原理； 容器资源、安全、前置校验等配置和使用。一、需求来源背景问题首先一起来看一下需求来源。大家应该都有过这样的经验，就是用一个容器镜像来启动一个 container。要启动这个容器，其实有很多需要配套的问题待解决：第一，比如说一些可变的配置。因为我们不可能把一些可变的配置写到镜像里面，当这个配置需要变化的时候，可能需要我们重新编译一次镜像，这个肯定是不能接受的； 第二就是一些敏感信息的存储和使.

模拟证书过期由kubeadm部署的集群，所生成的证书证书有效期为一年，过期之后集群就不能再次使用了，我们可以对证书进行续期，这样集群就可以继续使用。可以通过如下命令查看具体过期时间：kubeadm alpha certs check-expiration这里显示证书在2021年7月5日过期，然后把所有节点的系统时间调整到 2022年10月1日：所有节点的时间都要调整。然后在master（vms71上）执行kubectl命令：[root@vms71 ~]# kubectl

将 Pod 部署运行在 Kubernetes 内，前几个步骤你可能很熟悉(1) kubectl 将 YAML 发送到 API(2) Pod 存储在 etcd 中(3) 调度程序分配一个节点(此时Pod配置清单文件存储在 etcd 中，节点内并没有该 pod(4)kubelet 开始创建 Pod(5) kubelet 将创建容器的委托委派给 CRI(6) CNI 分配一个 IP 地址(7) 检查探针(8) ku...

无状态与有状态Deployment控制器设计原则：管理的所有Pod一模一样，提供同一个服务，也不考虑在哪台Node运行，可随意扩容和缩容。这种应用称为“无状态”，例如Web服务在实际的场景中，并不能满足所有应用，尤其是分布式应用，会部署多个实例，这些实例之间往往有依赖关系，例如主从关系、主备关系，这种应用称为“有状态”，例如MySQL主从、Etcd集群StatefulSet 控制器概述StatefulSet控制器用于部署有状态应用，满足一些有状态应用的需求：• Pod有序的部署.

云原生存储的两个关键领域： Docker 存储卷：容器服务在单节点的存储组织形式，关注数据存储、容器运行时的相关技术； K8s 存储卷：关注容器集群的存储编排，从应用使用存储的角度关注存储服务。 Docker 存储容器服务之所以如此流行，一大优势即来自于运行容器时容器镜像的组织形式。容器通过复用容器镜像的技术，实现在相同节点上多个容器共享一个镜像资源（更细一点说是共享某一个镜像层），避免了每次启动容器时都拷贝、加载镜像文件，这种方式既节省了主机的存储空间，又提高了容器启动效率。.

Kubernetes 的组件（Master）Kubernetes 的控制面包含着 kube-apiserver、kube-scheduler、kube-controller-manager 这三大组件，我们也称为 Kubernetes 的三大件。下面我们逐一来讲一下它们的功能及作用。首先来看 kube-apiserver它是整个 Kubernetes 集群的“灵魂”，是信息的汇聚中枢，提供了所有内部和外部的 API 请求操作的唯一入口。 同时也负责整个集群的认证、授权、访问控制、服务发现等能力

在使用过程中，我们常常需要对 Pod 进行一些配置管理，比如参数配置文件怎么使用，敏感数据怎么保存传递，等等。有些人可能会觉得，为什么不把这些配置（不限于参数、配置文件、密钥等）打包到镜像中去啊？乍一听，好像有点可行，但是这种做法“硬伤”太多。有些不变的配置是可以打包到镜像中的，那可变的配置呢？ 信息泄漏，很容易引发安全风险，尤其是一些敏感信息，比如密码、密钥等。 每次配置更新后，都要重新打包一次，升级应用。镜像版本过多，也给镜像管理和镜像中心存储带来很大的负担。 定制化太严重，可扩展能力差，且不

一、调度简介在开始前，先来看看Kubernetes的架构示意图，其中控制平面包含以下三大组件：kube-scheduler、kube-apiserver、kube-controller-manager。kubelet及kube-proxy组件的分析我们后续单独成章进行讲解，现在我们可以简单给理解上述组件的难易程度排个序，kube-apiserver、kubelet、kube-scheduler、kube-controller-manager、kube-proxy。如上所述，kube-sc...

对于新安装的 Kubernetes，经常出现的一个问题是Service没有正常工作。如果您已经运行了Deployment并创建了一个Service，但是当您尝试访问它时没有得到响应，希望这份文档能帮助您找出问题所在。先来熟悉下Service工作逻辑：为了完成本次演练的目的，我们先运行几个Pod。$ kubectl run hostnames --image=k8s.gcr.io/serve_hostname \ --labels=a...

Secret与ConfigMap类似，区别在于Secret主要存储敏感数据，所有的数据要经过base64编码。 应用场景：凭据 kubectl create secret 支持三种数据类型： docker-registry（kubernetes.io/dockerconfigjson）：存储镜像仓库认证信息 generic（Opaque）：存储密码、密钥等 tls（kubernetes.io/tls）：存储TLS证书[root@k8s-master ~]# kubectl cr.

管理应用程序配置(configmap)创建ConfigMap后，数据实际会存储在K8s中Etcd，然后通过创建Pod时引用该数据。 应用场景：应用程序配置 Pod使用configmap数据有两种方式： • 变量注入 • 数据卷挂载[root@k8s-master ~]# cat configmap.yml apiVersion: v1kind: ConfigMapmetadata: name: app-configdata: abc: "123" cde:

Ingress：个性化配置[root@k8s-master ~]# cat ingress-annotations.yaml apiVersion: networking.k8s.io/v1kind: Ingressmetadata: name: annotation-test annotations: kubernetes.io/ingress.class: "nginx" nginx.ingress.kubernetes.io/proxy-connec.

上一篇博客讨论了Health Check 在 Scale Up 中的应用，Health Check 另一个重要的应用场景是 Rolling Update。试想一下下面的情况：现有一个正常运行的多副本应用，接下来对应用进行更新（比如使用更高版本的 image），Kubernetes 会启动新副本，然后发生了如下事件： 正常情况下新副本需要 10 秒钟完成准备工作，在此之前无法响应业务请求。 但由于人为配置错误，副本始终无法完成准备工作（比如无法连接后端数据库）。 先别继续往下看，现在请

Deployment：介绍管理Pod和ReplicaSet 具有上线部署、副本设定、滚动升级、回滚等功能 提供声明式更新，例如只更新一个新的Image 应用场景：网站、API、微服务Deployment：使用流程 ...

Services 和 PodsKubernetesPods是有生命周期的。他们可以被创建，而且销毁不会再启动。如果您使用Deployment来运行您的应用程序，则它可以动态创建和销毁 Pod。一个Kubernetes的Service是一种抽象，它定义了一组Pods的逻辑集合和一个用于访问它们的策略 - 有的时候被称之为微服务。一个Service的目标Pod集合通常是由Label Selector 来决定的（下面有讲一个没有选择器的Service 有什么用处）。举个例子，想象一个处理图片的后端运行

一个 Pod 被创建出来，不管是由你直接创建，还是由其他工作负载控制器（Workload Controller）自动创建，经过调度器调度以后，就永久地“长”在某个节点上了，直到该 Pod 被删除，或者因为资源不够被驱逐，抑或由于对应的节点故障导致宕机等。因此单独地用一个 Pod 来承载业务，是没办法保证高可用、可伸缩、负载均衡等要求，而且 Pod 也无法“自愈”。这时我们就需要在 Pod 之上做一层抽象，通过多个副本（Replica）来保证可用 Pod 的数量，避免业务不可用。在介绍 Kuberne..

Kubernetes Scheduler 是 Kubernetes 控制平面的核心组件之一。它在控制平面上运行，将 Pod 分配给节点，同时平衡节点之间的资源利用率。将 Pod 分配给新节点后，在该节点上运行的 kubelet 会在 Kubernetes API 中检索 Pod 定义，根据节点上的 Pod 规范创建资源和容器。换句话说，Scheduler 在控制平面内运行，并将工作负载分配给 Kubernetes 集群。本文将对 Kubernetes Scheduler 进行深入研究，首先概述一般的调度

本文通过记录kubelet连接apiserver超时问题的原因及修复办法。背景kubernetes是master-slave结构，master node是集群的大脑，当master node发生故障时整个集群都"out of control"。master node中最重要的当属apiserver组件，它负责处理所有请求，并持久化状态到etcd。一般我们会部署多份apiserver实现高可用。官方建议在多个apiserver前面部署一个LB进行负载均衡，当其中一台apiserver发生故障之后.

为容器管理资源当你定义 Pod时可以选择性地为每个容器设定所需要的资源数量。 最常见的可设定资源是 CPU 和内存（RAM）大小；此外还有其他类型的资源。当你为 Pod 中的 Container 指定了资源请求时，调度器就利用该信息决定将 Pod 调度到哪个节点上。 当你还为 Container 指定了资源约束时，kubelet 就可以确保运行的容器不会使用超出所设约束的资源。 kubelet 还会为容器预留所请求数量的系统资源，供其使用。请求和约束如果 Pod 运行所在...

Pod基本概念Pod是Kubernetes创建和管理的最小单元，一个Pod由一个容器或多个容器组成，这些容器共享存储、网络。Pod特点• 一个Pod可以理解为是一个应用实例，提供服务• Pod中容器始终部署在一个Node上 • Pod中容器共享网络、存储资源• Kubernetes直接管理Pod，而不是容器Pod就是豌豆荚，里面的豆子可以理解为容器，一个pod可以理解为一个应用提供具体的某个服务。Pod主要用法：• 运行单个容器：最常见的用法，在这种情况下，可以将Pod.

kubectl 是 Kubernetes 的一个命令行管理工具，可用于 Kubernetes 上的应用部署和日常管理。本文列举了 9 个常见的 kubectl 命令，并总结了一些使用技巧，希望可以帮助系统管理员简化管理工作。kubectl 查询，创建，编辑，删除资源查看master组件状态：kubectl get cs[root@k8s-master ~]# kubectl get csWarning: v1 ComponentStatus is deprecated in ...

前面的例子中，我们提前创建了 PV，然后通过 PVC 申请 PV 并在 Pod 中使用，这种方式叫做静态供给（Static Provision）。与之对应的是动态供给（Dynamical Provision），即如果没有满足 PVC 条件的 PV，会动态创建 PV。相比静态供给，动态供给有明显的优势：不需要提前创建 PV，减少了管理员的工作量，效率高。动态供给是通过 StorageClass 实现的，StorageClass 定义了如何创建 PV，下面是两个例子。StorageClasssta.

Calico网络两台Docker主机如何实现容器互通？ Docker跨主机会分配相同的的IP，这样肯定是无法通信的，在本地ping 172.17.0.2肯定是找的该主机上面的172.0.02不会去找另外一台主机上面的容器Q：1、统一管理这些k8s node网段，保障每个容器分配不一样的ip2、要知道转发哪个docker主机？3、怎么实现这个转发（从docker主机1上容器发送到另一台docker主机上容器）A：1、给每个docker主机分配唯一的网段2、做好记录，每.

CronJobLinux 中有 cron 程序定时执行任务，Kubernetes 的 CronJob 提供了类似的功能，可以定时执行 Job。CronJob 配置文件示例如下：spec.template格式同Pod RestartPolicy仅支持Never或OnFailure 单个Pod时，默认Pod成功运行后Job即结束 spec.completions标志Job结束需要成功运行的Pod个数，默认为1 spec.parallelism标志并行运行的Pod的个数，默认为1 spec...

一、什么是KubernetesKubernetes，从官方网站上可以看到，它是一个工业级的容器编排平台。Kubernetes 这个单词是希腊语，它的中文翻译是“舵手”或者“飞行员”。在一些常见的资料中也会看到“ks”这个词，也就是“k8s”，它是通过将8个字母“ubernete ”替换为“8”而导致的一个缩写。Kubernetes 为什么要用“舵手”来命名呢？大家可以看一下这张图：这是一艘载着一堆集装箱的轮船，轮船在大海上运着集装箱奔波，把集装箱送到它们该去的地方。我们之前其实介绍过一个概.

DaemonSet 确保全部（或者一些）Node 上运行一个 Pod 的副本。当有 Node 加入集群时，也会为他们新增一个 Pod 。当有 Node 从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 PodDaemonSet 的典型应用场景有： 在集群的每个节点上运行存储 Daemon，比如 glusterd 或 ceph。 在每个节点上运行日志收集 Daemon，比如 flunentd 或 logstash。 在每个节点上运行监控 ..

前面已经说了调度的亲和性，其实都比较含蓄，比如软硬亲和性，污点和容忍。固定节点就比较粗暴了，可以通过节点名称去选择，也可以通过节点的标签去选择，固定在某个节点上运行。这就是所谓固定节点的调度。固定节点调度有两种方式，一种是使用Pod.spec.nodeName节点名称去选择，或者使用节点的标签去选择。通过这两种方式将pod固定在节点上运行。指定调度节点I、Pod.spec.nodeName 将 Pod 直接调度到指定的 Node 节点上，会跳过 Scheduler 的调度策略，该匹配..

云原生技术发展简史首先从第一个问题进行分享，那就是“为什么要开设云原生技术公开课？”云原生、CNCF都是目前非常热门的关键词，但是这些技术并不是非常新鲜的内容。2004年— 2007年，Google 已在内部大规模地使用像 Cgroups这样的容器技术； 2008年，Google将 Cgroups合并进入了Linux内核主干； 2013年，Docker项目正式发布。 2014年，Kubernetes项目也正式发布。这样的原因也非常容易理解，因为有了容器和D...

在开启了 TLS 的集群中，每当与集群交互的时候少不了的是身份认证，使用 kubeconfig（即证书） 和 token 两种认证方式是最简单也最通用的认证方式。以kubectl为例介绍kubeconfig的配置。kubectl只是个go编写的可执行程序，只要为kubectl配置合适的kubeconfig，就可以在集群中的任意节点使用。kubectl默认会从$HOME/.kube目录下查找文件名为config的文件，也可以通过设置环境变量KUBECONFIG或者通过设置--kubeconfig...

创建用户[root@k8s-master ~]# useradd devuser[root@k8s-master ~]# passwd devuserChanging password for user devuser.New password: BAD PASSWORD: The password is shorter than 8 charactersRetype new password: passwd: all authentication tokens updated succ.

当认证通过以后，并不意味着你有访问资源可能。因为需要鉴权，这样才有访问具体对象的权限。Authorization上面认证过程，只是确认通信的双方都确认了对方是可信的，可以相互通信。而鉴权是确定请求方有哪些资源的权限（具体对资源有哪些资源的权限就需要鉴权）。API Server 目前支持以下几种授权策略（通过 API Server 的启动参数 “--authorization-mode” 设置）AlwaysDeny：表示拒绝所有的请求，一般用于测试 AlwaysAllow：允许接收所有请求.

建议将Pod的数据放入某个持久卷中，以便即使Pod终止后也可以使用这些数据。在Kubernetes（k8s）中，可以在Pod中使用基于NFS的持久卷。在本文中，我们将学习如配置持久卷和持久卷声明，然后我们将讨论如何通过k8s pod中的声明名称使用持久卷。我假设我们有一个功能正常的k8s集群和NFS Server。以下是设置的详细信息: NFS服务器IP = 192.168.179.102 NFS共享目录 = /opt/k8s-pods/data K8s群集 = 一个主节...

如果 Kubernetes 部署在诸如 AWS、GCE、Azure 等公有云上，可以直接使用云硬盘作为 Volume，下面是 AWS Elastic Block Store 的例子：要在 Pod 中使用 ESB volume，必须先在 AWS 中创建，然后通过 volume-id 引用。其他云硬盘的使用方法可参考各公有云厂商的官方文档。Kubernetes Volume 也可以使用主流的分布式存，比如 Ceph、GlusterFS 等，下面是 Ceph 的例子：...

Service概念　Kubernetes Service 定义了这样一种抽象：一个 Pod 的逻辑分组，一种可以访问它们的策略 —— 通常称为微服务。这一组 Pod 能够被 Service 访问到，通常是通过 Label Selector对 Kubernetes 集群中的应用，Kubernetes 提供了简单的 Endpoints API，只要 Service 中的一组 Pod发生变更，应用程序就会被更新。对非 Kubernetes 集群中的应用，Kubernetes 提供了基于 VIP 的网桥的方..

在 Cluster 中，除了可以通过 Cluster IP 访问 Service，Kubernetes 还提供了更为方便的 DNS 访问。[root@k8s-master ~]# kubectl get deployment -n kube-systemNAME READY UP-TO-DATE AVAILABLE AGEcoredns 1/1 1 1 25hcoredns 是一个 DNS 服务器。每当有新的 Ser

StatefulSetsKubernetes通过控制器维护所需的配置状态。Deployment、ReplicaSet、DaemonSet和StatefulSet就是一些常用的控制器。StatefulSet是一种特殊类型的控制器，它可以使Kubernetes中运行集群工作负载变得很容易。集群工作负载通常有一个或多个主服务器（Masters）和多个从服务器（Slaves）。大多数数据库都以集群模式设计的，这样可以提供高可用性和容错能力。有状态集群工作负载持续地在Masters和Slaves之间复制数

对于多副本应用，当执行 Scale Up 操作时，新副本会作为 backend 被添加到 Service 的负责均衡中，与已有副本一起处理客户的请求。考虑到应用启动通常都需要一个准备阶段，比如加载缓存数据，连接数据库等，从容器启动到正真能够提供服务是需要一段时间的。我们可以通过 Readiness 探测判断容器是否就绪，避免将请求发送到还没有 ready 的 backend。下面是示例应用的配置文件。重点关注readinessProbe部分。这里我们使用了不同于exec的另一种探测方法 ...

Kubernetes三种探针k8s支持存活livenessProbe和就绪readinessProbe两种探针，两种探针都支持以下三种方式一、exec通过执行shell命令的方式，判断退出状态码是否是0，示例： exec: command: - cat - /tmp/healthy二、tcp通过TCP请求的方式，是否能建立tcp连接，示例： tcpSocket: port: 808...

Kubernetes存活探针和就绪探针的最佳实践【编者的话】Kubernetes提供了两种探针来检查容器的状态，Liveliness和Readiness，根据官方文档，Liveliness探针是为了查看容器是否正在运行，翻译为存活探针，Readiness探针是为了查看容器是否准备好接受HTTP请求，翻译为就绪探针。这篇文章主要阐述了作者在使用这两种探针时总结的一些最佳实践。在Kubernetes中，Pod是Kubernetes创建及管理的最小的可部署的计算单元，一个Pod由一个或者多个容器（Doc..