FR13DNS的博客

Logging收集: 采集多种来源的日志数据(流式日志收集器)传输: 能够稳定的吧日志数据传输到中央系统(消息队列)存储: 可以将日志以结构化数据的形式储存起来(搜索引擎)分析: 支持方便的分析、检索方式最好有GUI管理系统(前端)告警: 能够提供错误报告、监控机制(监控工具)ELK stackElasticSeach: 通过与mysql的B-tree正向索引相反的倒排索引,利用分词器将关键词作为标签索引出所有符合条件的目标LogStash: 流式日志收集器Kibana: 前端GUI

server 有一个问题就是无论哪种类型都只能实现 4 层转发和代理,如果要建立一个 http 的服务,那么每一个 app 都要建立成一个 http 主机,因为 4 层调度本身是无法卸载 http 会话的,事实上 k8s 集群还有一种引入集群外部流量的方式:ingress,ingress 资源是一种七层调度器,但他也脱离不了 server资源 和 web 服务[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-joOEKfYz-1624628357507)(https://raw

helm 是一个类似 yum 用来简化部署 k8s 上容器的程序,虽然 helm 本身并不存放任何镜像,镜像依旧存储在各个镜像仓库如 docker hub 中.helm 仓库用来存储清单文件 charts,相对的 charts 需要在正式运行前赋予相关环境变量值以适用于不同的客制化信息,所以 helm 会从仓库中获取 charts 并存放在本地,之后创建容器时则先以本地 charts 为准,如果本地没有才会在仓库中寻找相关 charts,并且 charts 在部署以后便称之为 release.并且 helm

管理无状态应用的控制器，且作为守护进程类replicaSetDeploymentDaemonSet管理无状态应用的控制器，且任务结束即退出的进程则需要JobCronjob管理有状态应用StatefulSetreplicaSetreplicaSet 是新版本加入用来代替 ReplicationController 的控制器，代用户创建指定数量的pod副本数量，确保pod副本数量符合预期状态，并且自动扩容和缩容功能有三个组件组成管控的pod副本有几个标签选择器pod资源

Kuber-adm 安装的 k8s 集群默认启用 RBAC,Kubernetes 的授权操作由第三方插件来完成,当有一个插件完成授权后其他插件不再检查,在众多授权插件中常用的有四个Node: 有节点的认证ABAC: 基于属性的访问控制,RBAC 启用前的算法RBAC: Role-based access control,基于角色的访问控制Webhook: 基于 HTTP 的回调机制来实现RBAC基于角色分配的访问控制,角色决定权限角色 (role)许可 (permission)[外

pod 如果想对外提供访问就需要在其之上增加 server 中间层,而 server 则强依赖 k8s 自身的 dns,如 CoreDNS 或较老版本中的 kube-dns,server 通过 dns 服务来解析找到对应 pod,同时 k8s 如果需要对客户端提供网络功能则需要第三方插件并符合 CNI 也叫容器网络插件标准的接口来接入k8s 网络中存在三种 ip,其中 node 和 pod 的 ip 是实实在在配置的,而第三类地址 server network 被称为 virtual IP,这类 ip 没

应用程序存在“有状态”和“无状态”两种类别,因为无状态类应用的 Pod 资源可按需增加、减少或重构,而不会对由其提供的服务产生除了并发响应能力之外的其他严重影响。Pod 资源的常用控制器中,Deployment、ReplicaSet 和 DaemonSet 等常用于管理无状态应用.但实际情况是,应用本身就是分布式的集群,各应用实例彼此之间存在着关联关系,甚至是次序、角色方面的相关性,其中的每个实例都有其自身的独特性而无法轻易由其他实例所取代.使用 statefulset 需要提前将有状态服务的运维管理过程

自 Docker 技术诞生以来,采用容器技术用于开发、测试甚至是生产环境的企业或组织与日俱增.然而,将容器技术应用于生产环境时如何确定合适的网络方案依然是亟待解决的最大问题,这也曾是主机虚拟化时代的著名难题之一,它不仅涉及了网络中各组件的互连互通,还需要将容器与不相关的其他容器进行有效隔离以确保其安全性.本章将主要讲述容器网络模型的进化、Kubernetes 的网络模型、常用网络插件以及网络策略等相关的话题.Docker 的传统网络模型在应用至日趋复杂的实际业务场景时必将导致复杂性的几何级数上升,由此,Ku

Dashboard 是 Kubernetes 的 Web GUI,可用于在 Kubernetes 集群上部署容器化应用、应用排障、管理集群本身及其附加的资源等.它常被管理员用于集群及应用速览、创建或修改单个资源（如Deployments、Jobs和DaemonSets等）,以及扩展Deployment、启动滚动更新、重启Pod或使用部署向导部署一个新应用等.Dashboard依赖于Heapster或Metrics Server完成指标数据的采集和可视化.Dashboard 的认证和授权均可由 Kube

ConfigMap 和 Secret 是 Kubernetes 系统上两种特殊类型的存储卷,ConfigMap 对象用于为容器中的应用提供配置数据以定制程序的行为,不过敏感的配置信息,例如密钥、证书等通常由 Secret 对象来进行配置,它们将相应的配置信息保存于对象中,而后在 Pod 资源上以存储卷的形式将其挂载并获取相关的配置,以实现配置与镜像文件的解耦ConfigMap配置中心的角色,使得可以注入到 pod 中在 pod 启动或让 pod 挂载,得以实现动态修改配置,但 ConfigMap 是明文

Calico是一个开源虚拟化网络方案,用于为云原生应用实现互联及策略控制.与 Flannel 相比,Calico 的一个显著优势是对网络策略（network policy）的支持,它允许用户动态定义 ACL 规则控制进出容器的数据报文,实现为 Pod 间的通信按需施加安全策略.事实上,Calico 可以整合进大多数主流的编排系统,如 Kubernetes、Apache Mesos、Docker和 OpenStackCalico 本身是一个三层的虚拟网络方案,它将每个节点都当作路由器,将每个节点的容器都当作

代替 HeapSter 的原生资源指标metrics-server原生指标只能收集如 CPU 、内存等,而在此之上收集更多维度数据的方式成为自定义指标,如 Prometheus, Prometheus 通过 k8s-prometheus-adapter 转换成指标格式新一代监控架构核心指标流水线: 由 kubelet metrics-server 以及由 API server 提供的 api 组成,目前来讲主要包含 CPU 累计使用率,内存的实时使用率以及 Pod 的资源占用率及容器的磁盘占用

kubernetes 的 API Server 以 RESTful 风格的编程接口将所有操作对象当作资源操作，并且可通过标准的 http/https 请求如 get、put、delete，post 等方式来实现，只不过通过 kubectl 的形式来实现常用资源分类一个应用通常需要多个资源的支持，例如使用 Deployment 管理 Pod 、使用 ConfigMap 资源保存应用配置、使用 Service 或 Ingress 暴露服务，使用 Volume 提供外部存储等依据资源的主要功能作为划分，k

概念点kubectl就是apiserver的客户端工具，通过连接到apiserver对集群资源进行增删改查等基本操作资源对象：pod service replicaset deployment job node … …在众多的kubectl命令中，关于创建pod时的调度命令taint为污点功能，可以利用这个功能给节点增加污点，增加匹配难度使得该节点不易被消耗资源。master节点上就有众多的污点，使之只运行重要的核心组件而不会被抢占资源，使用 describe 命令可以查看到详尽的节点信息

对容量器来说,控制其资源的方式有两个维度:requests: 需求,最低保障limits: 限制,硬限制requests 代表节点上必须有这么多资源才能被调度其上,节点的已使用的的资源则是所有容器的 requests 总和,而 limits 则代表最大的限量,通常 requests 小于等于 limits资源计量单位CPU:1 颗逻辑CPU = 1000 个 millicoresMEM:Ei Pi Ti Gi … …定义资源需求requests 用来表示运行容器的运行最低资源

整个 k8s 集群的 APIserver 是访问控制的唯一入口,但不会限制应用程序,任何用户试图操作资源对象时,要经历三个环节认证: 访问 k8s 的账号和安全认证授权: 是否有操作资源对象的权限准入控制: 级联的其他资源是否有权限用户可以通过多种插件来选择通过何种逻辑方式完成认证和准入控制如: token、SSL 等,其中 SSL 认证客户端需要验证服务端的 CA 证书同时,服务端也要认证 kubectl 的 CA 证书.如果环境中存在多个认证插件则不会串行认证,授权来说也可以通过插件来完成用

Docker集群管理与编排的方法docker_compose（单机编排）+ docker_swarm（整合资源池）+ docker_machine（快速安装docker）mesos（AS旗下，IDC级别的硬件编排，但接口不是容器接口）+ marathon（容器接口）kubernetes孕育而生的概念：DevOps、MicroServices、Blockchaindevops概念CI/CD持续集成、持续交付、持续部署持续集成：用户提交代码后，自动构建、自动构建测试环境并测试持续交付：自动

应用程序在处理请求时，可根据其对当前请求的处理是否受影响于此前的请求，将应用划分为有状态应用和无状态应用两种,微服务体系中，各种应用均被拆分成了众多微服务或更小的应用模块，因此往往会存在为数不少的有状态应用，当然也会存在数量可观的无状态应用,而对于有状态应用来说数据持久化几乎是必然之需 kubernetes 提供的存储卷属于 pod 资源级别，共享于 pod 内的所有容器，可用于在容器的文件系统之外存储应用程序的相关数据，甚至还可独立于 pod 的生命周期之外实现数据持久化pod 挂载数据卷的实现方式p

POD生命周期Pod对象自从其创建开始至其终止退出的时间范围称为其生命周期，在这段时间中Pod会处于多种不同的状态，并执行一些操作其中，创建主容器 main container 为必需的操作，其他可选的操作还包括运行初始化容器 init container、容器启动后钩子 post start hook 、容器的存活性探测 liveness probe 就绪性探测 readiness probe 以及容器终止前钩子 pre stop hook 等，这些操作是否执行则取决于Pod的定义Pod相位无论

Kubernetes 调度器Kubernetes 依赖 scheduler 组件于以确保调度 pod 能在集群中找到一个合适的节点,并使其以期望的状态运行。调度过程中，调度器不会修改Pod资源，而是从中读取数据并根据配置的策略挑选出最适合的节点，而后通过API调用将Pod绑定至挑选出的节点之上以完成调度过程.工作逻辑kuberlet 的工作概述当用户请求通过 APIserver 到达 scheduler 后,通过 scheduler 的算法得出一个最适合运行该 pod 的节点后,会将结果传回 A