Estom的博客

配置应用程序 使用Docker部署应用程序时，一般常用的配置方式有： 配置内嵌 启动传参配置 环境变量 经过前面容器持久化存储的介绍，我们很容易能想到是以挂载卷的形式，比如： gitRepo hostPath NFS 再结合边车模式来进行配置文件的管控是可行的，然而有一种更加简便的方法能将配置数据置于Kubernetes的顶级资源对象中，那就是ConfigMap。 传递命令行参数在上一节容器持久化存储的emptyDir概念介绍部分，我们引入了一个fortune-pod的例子，再回顾一下之前的配置文件吧，如下： 1234567891011121314151617181920212223apiVersion: v1kind: Podmetadata: name: fortunespec: containers: - image: luksa/fortune name: html-generator volumeMounts: - name: html mountPath: /var/htdocs - image: nginx:alpine ...

容器持久化存储 容器的本质是进程，对于进程，Linux系统有进程组的概念来将其组织在一起。在k8s里面，使用Pod这个逻辑概念来维护容器间的关系。 有了Pod后，我们的应用程序需要被创建和管理，这就引出了ReplicaSet和Deployment；然后需要将部署好的应用暴露给外部进行访问，Service可以提供一个固定的ip和端口让外部访问。 对于有状态的应用，可以使用StatefulSet来进行状态的恢复，在上一节概念介绍里面有提到，有状态的应用是离不开持久化存储的。 引子在Docker中，如果一个容器在运行过程中会产生数据并写入到文件系统，当关闭这个容器，用镜像再启动一个容器的时候，你就会意识到新容器并不会识别前一个容器写入文件系统内的任何内容。 对于有状态的应用，我们希望下次启动的应用可以保持住上次的状态；在k8s里面可以通过定义存储卷来满足这个需求，它们不像Pod这样的顶级资源，而是被定义为Pod的一部分，并和Pod共享相同的生命周期。因此在Pod里面容器重新启动期间，卷的内容是不变的， 卷emptyDir在Pod中如何定义卷？让我们从emptyDir开始。设想一个这样的...

1 概述概念探针:是由 kubelet 对容器执行的定期诊断。kubelet 调用由容器实现 Handler执行诊断。探针有三种类型的处理程序: ExecAction：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。 CPSocketAction：对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开，则诊断被认为是成功的。 HTTPGetAction：对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于 400，则诊断被认为是成功的。和微服务的心跳检测类似，每隔一段时间，检测这个容器是否还正常工作，检测状态分为三种,每次检测，都会得到其中一种，k8s会根据检测到的不同状态，对容器进行不同的处理： 成功：容器通过了诊断。 失败：容器未通过诊断。 未知：诊断失败，因此不会采取任何行动。 分类探针主要有以下三种类型： livenessProbereadinessProbestartupProbe 容器重启策略容器重启策略PodSpec 中有一个 restartPolicy 字段，其值可以设置为...

kubectl port-forward 允许使用资源名称 （例如 Pod 名称）来选择匹配的 Pod 来进行端口转发 将 mongo-75f59d57f4-4nd6q 改为 Pod 的名称kubectl port-forward mongo-75f59d57f4-4nd6q 28015:27017 这相当于 kubectl port-forward pods/mongo-75f59d57f4-4nd6q 28015:27017或者 kubectl port-forward deployment/mongo 28015:27017或者 kubectl port-forward replicaset/mongo-75f59d57f4 28015:27017或者 kubectl port-forward service/mongo 28015:27017 以上所有命令都有效。输出类似于： Forwarding from 127.0.0.1:28015 -> 27017Forwarding from [::1]:28015 -> 27...

设计模式——基于容器的分布式系统 20世纪80年代末至90年代初，面向对象编程思想给软件开发带来了一轮技术革新，就像润物细无声的春雨那般，向全世界的程序员们快速普及了模块化构建应用程序的方法，一直流行至今。 当下，我们可以看到类似的革新出现在了分布式系统开发，具体特点如下： 基于容器的微服务架构体系日益流行 容器天然隔离的属性非常适合作为分布式系统中的基本对象 基于面向对象，四人帮基于经验提出和总结了对于一些常见软件设计问题的标准解决方案，其描述了一系列基于接口的模式，可以在各种环境中重用，这被称之为软件设计模式。历史一定程度上来说是重复的，随着这种架构模式的成熟，基于容器的分布式系统的设计模式也就自然而然地浮现了。 本篇主要阐述的是Brendan Burns在基于容器的分布式系统中发现的三种设计模式： single-container patterns for container management：容器管理之单容器模式 single-node patterns of closely cooperating containers：容器协调之单节点（多容器）模式 mult...

1 有无状态服务对比无状态服务 数据方面：无状态服务不会在本地存储持久化数据.多个实例可以共享相同的持久化数据 结果方面：多个服务实例对于同一个用户请求的响应结果是完全一致的 关系方面：这种多服务实例之间是没有依赖关系 影响方面：在k8s控制器 中动态启停无状态服务的pod并不会对其它的pod产生影响 示例方面：nginx实例，tomcat实例，web应用 资源方面：相关的k8s资源有：ReplicaSet、ReplicationController、Deployment 创建方式：Deployment被设计用来管理无状态服务的pod。每个pod完全一致，原因如下： 无状态服务内的多个Pod创建的顺序是没有顺序的 无状态服务内的多个Pod的名称是随机的.pod被重新启动调度后,它的名称与IP都会发生变化 无状态服务内的多个Pod背后是共享存储的 缩容方式：随机缩容。由于是无状态服务，所以这些控制器创建的pod序号都是随机值。并且在缩容也是随机，并不会明确缩容某一个pod。因为所有实例得到的返回值都是一样，所以缩容任何一个pod都可以 有状态服务 数据方面：有状态服务需要在本...

容器网络网络类型 Node Network: 外部网络接口。集群节点所在的网络，这个网络就是你的主机所在的网络，通常情况下是你的网络基础设施提供。如果node处于不同的网段，那么你需要保证路由可达。如上图中的 192.168.10.0/24和10.0.0.0/8这两个网络 Service Network：K8S服务网络,ipvs规则当中的网络，由特定组件提供路由和调度。 service_cluster_ip_range（如图，默认的配置是的10.0.0.1/24)。在上图中，扩充的节点（基础网络是10.0.0.0/8)和 服务网络（10.0.0.1/24)冲突，会造网络问题。 Pod Network： 节点当中pod的内部网络无法与外界通信。第三个网络是Pod的网络， K8s中一个Pod由多个容器组成，但是一个pod只有一个IP地址，Pod中所有的容器共享同一个IP。这个IP启动pod时从一个IP池中分配的， 叫做 pod CIDR, 或者叫network_cidr（如图，默认配置是10.1.0.0/16)。 可以在...

之前的部分按照操作内容，介绍操作的流程和原理。 这一部分主要对命令进行汇总 1 命令基础命令格式123kubectl [command] [type] [name] [flags]kubectl get pod pod_name -n asa-ms command：子命令，用于操作Kubernetes集群资源对象的命 令，例如create、delete、describe、get、apply等。 TYPE：资源对象的类型，区分大小写，能以单数、复数或者 简写形式表示。例如以下3种TYPE是等价的。 kubectl get pod kubectl get pods kubectl get po NAME：资源对象的名称，区分大小写。如果不指定名称， 系统则将返回属于TYPE的全部对象的列表，也可以指定多个资源对象。 kubectl get pods将返 回所有Pod的列表 kubectl get pods pod1 pod2 pod3 flags：kubectl子命令的可选参数，例如使用“-s”指定API Server的URL地址而不用默认值。 输出格式-o -...

原理容器终止在 Kubernetes 中，Pod 停止时 kubelet 会先给容器中的主进程发 SIGTERM 信号来通知进程进行 shutdown 以实现优雅停止，如果超时进程还未完全停止则会使用 SIGKILL 来强行终止。 容器的终止流程 Pod 被删除，状态置为 Terminating。 kube-proxy 更新转发规则，将 Pod 从 service 的 endpoint 列表中摘除掉，新的流量不再转发到该 Pod。 如果 Pod 配置了 preStop Hook ，将会执行。 kubelet 对 Pod 中各个 container 发送 SIGTERM 信号以通知容器进程开始优雅停止。 等待容器进程完全停止，如果在 terminationGracePeriodSeconds 内 (默认 30s) 还未完全停止，就发送 SIGKILL 信号强制杀死进程。 所有容器进程终止，清理 Pod 资源。 优雅退出处理实现prestop逻辑123456lifecycle: preStop: exec: command: - sleep ...