我们聊j2cli之前，先需要熟悉西jinja2模板引擎。 # jinja2 Jinja2 是一个设计者友好的，类似django 模板的 python 模板引擎。 它速度快，灵活，安全被广泛使用。使用jinja2的开源项目有ansible，django，flask，helm chart等。 # 模板引擎 * 什么是模版呢？ 模板简单来说就是一个其中包含占位变量来标识动态部分的文件，模板文件在经过
# ini简介 ini文件是一个无固定标准格式的配置文件。它以简单的文字与简单的结构组成，常常用于配置文件。ini文件的命名来源，是取自英文“初始（Initial）”的首字缩写，正与它的用途——初始化程序相应。 文件格式比较简单， 分为section、参数和值、注释 ### section INI使用section进行简单分割。section名写在方括号中，例如： ``` [ServerA]
概述etcd诞生于CoreOS公司，当前隶属于CNCF基金会，供高可用、强一致的小型keyvalue数据存储服务。架构主要的模块有：gRPCserver：负责对外提供gRPC接口，目前最新稳定版本已经支持http访问接口。用于处理用户发送的API请求以及其它etcd节点的同步与心跳信息请求raft状态机：Raft强一致性算法的具体实现，是etcd的核心wal日志存储：WriteAheadLog（预
Zookeeper概述ZooKeeper是一个分布式的，开源的分布式应用程序协调服务，它包含一个简单的原语集，属于Apache的顶级项目，可以基于它实现服务发现，配置维护，集群管理和分布式锁等。架构通过架构图我们看到zookeeper主要有如下四种角色：Leader：处理读写请求，处理与Follower的心跳检测，并以事务的方式处理与Follower和Observer的数据同步Follower：直
简介Kafka是一个分布式的，支持多分区、多副本，基于Zookeeper的流处理平台。最初由LinkedIn公司开发，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。最初kakfa是一个消息发布-订阅系统，最近几年kafka已经升级为了流处理平台，流是KafkaStreams提供的最重要的抽象，它代表一个无限的、不断更新的数据集。此流平台主要有如下核心功能：消息发布订阅：
https://zhuanlan.zhihu.com/p/308054212
简介cpu使用率计算原理cpu时间单位Linux使用jiffies作为使用cpu的时间单位。什么是jiffies呢？Linux内核定义的一个时间单位，值就是1/Hertz。Linux内核中，进程/线程消耗的时间，单位都是jiffies，初始值为0。什么是HZ(Hertz)呢？就是单位时间每秒时钟中断发生的频率。可以根据getconfCLK_TCK获取，是一个常量，一般系统默认值为100。#getc
简述Elasticsearch是一个分布式的免费开源搜索和分析引擎，能够实现近实时的数据搜索。在使用的过程中，由于各种原因可能导致集群写入或者查询缓慢，本文主要讲述集中常见的原因和解决方法。写入拒绝或者慢现象当像索引（存储和使文档可被搜索）或者搜索数据的时候会出现类似如下429状态码的报错:"status":429,"error":{"type":"es_rejected_execution_ex
简介elasticsearch的mapping属于template的一部分，mapping主要用于设置document的有哪些字段，字段的类型，字段的参数，以实现字段如何被存储和如何被索引查询等特性。mapping组成一个mapping主要有两部分组成：metadatamapping元数据字段用于自定义如何处理文档关联的元数据。例如：_index：用于定义document属于哪个index_typ
shard简介Elasticsearch中的数据会整理为索引。每个索引又由一个或多个分片组成。每个分片都是一个Lucene索引实例，您可以将其视作一个独立的搜索引擎，它能够对Elasticsearch集群中的数据子集进行索引并处理相关查询。分片是Elasticsearch在集群内分发数据的单位。Elasticsearch在对数据进行再平衡（例如发生故障后）时移动分片的速度取决于分片的大小和数量，以
Calico简介Calico组件是Tigera公司以Apache2.0开源协议开源的网络和网络解决方案组件，可用于容器、虚拟机、原生宿主机侧负载。CalicoCNI插件在CNI（ContainerNetworkInterface）框架内封装了Calico的功能，以对k8s环境做支持。虽然Flannel被公认为是最简单的选择，但Calico以其性能、灵活性而闻名。Calico的功能更为全面，不仅提供
背景随着云时代的来临，传统交换机二层互通和隔离已经不能满足云环境的需求了，主要出现了如下问题：多租户环境和虚拟机迁移为了满足在云网络中海量虚拟机迁移前后业务不中断的需要，要求虚拟机迁移前后的IP不能变化，继而要求网络必须是大二层结构。传统的二层网络技术，在链路使用率、收敛时间等方面都不能满足需要。VLAN的局限随着云环境租户的增加，传统vlan最多划分4096个已经不能满足需求。群雄争霸为了解决如
背景分布式服务部署在k8s环境，由于运行在每个pod中的服务要知晓这个分布式集群中其它的服务节点ip或者dns名称。而statefulset给其管理的pod提供了稳定的网络标识符(例如pod名字和主机名)，通过headlessservice为每一个pod提供了固定的dns名称，很好的解决了这个问题。然后，心里就又了产生了另一个疑问，k8s还有哪些方式可以直接访问到pod呢？直接访问pod的方式po
cephfs简介CephFS是个与POSIX标准兼容的文件系统，坐于基于对象的Ceph存储集群之上，其内的文件被映射到Ceph存储集群内的对象。客户端可以把此文件系统挂载在内核对象或用户空间文件系统（FUSE）上。文件目录和其他元数据存储在ceph的RADOS中，而MDS缓存元信息和文件目录信息。主要特点如下：可以支持内核空间mount-tceph方式挂载，也支持用户空间的ceph-fuse方式挂
背景之前为k8s准备了cephrbd块存储，但是最近再使用过程中发现了一个由于deployment更新导致rdb不能被正常挂载的问题。问题描述我们通过deployment生成一个pod，并且这个pod挂载一个rbd块存储用来提供持久化存储功能。有一次deployment更新，发现deployment先启动了一个被调度到其它node新的pod一直处于pending状态，而对于的老pod一直处于Ter
Pod是可以在Kubernetes中创建和管理的、最小的可部署的计算单元。Pod（就像在鲸鱼荚或者豌豆荚中）是一组（一个或多个）容器，这些容器共享存储、网络、以及怎样运行这些容器的声明。Pod中的所有容器是相对紧密的耦合在一起的，会被调度到同一个node节点上。本文测试数据来自源Kubernetes1.18版本。k8s的最小可调度单元如果选择容器作为k8s的最小可调度单元，那么容器的健康检测，多个
Container中的文件在磁盘上是临时存放的，这给Container中运行的较重要的应用程序带来一些问题：1，当容器崩溃时文件丢失。kubelet会重新启动容器。2，同一Pod中运行多个容器的情况下有共享文件需求。Kubernetes卷（Volume）这一抽象概念能够解决这两个问题。本文主要介绍k8s主流的集中卷，本文测试数据来自源Kubernetes1.18版本。emptyDir当Pod分派到
由于k8smaster集群中的一台master2节点有问题需要替换，故需要把master2从集群中移除，然后找一台新机器替代master2重新加入集群。本文主要介绍移除一台master后再重新加入集群的方法。从master集群移除master2节点在master1上执行如下命令#kubectldrainmaster2--delete-local-data--force--ignore-daemon
镜像导入导出dockerexport和dockerimport作用对当前的容器文件系统创建一个快照，并持久化为tar文件，tar文件中保存的是容器的文件系统和其上的数据。然后通过dockerimport命令导入tar文件到docker环境后，会发现导入成功的是一个只有一层镜像层的image，而不是恢复为一个容器。tar文件内容：#tarxftest.tar#lltotal766604-rw-r--
Harbor简介Harbor是由VMware公司中国团队为企业用户设计的Registryserver开源项目，包括了权限管理(RBAC)、LDAP、审计、管理界面、自我注册、HA、RESTfulAPI等企业必需的功能，属于CloudNativeComputingFoundation（CNCF，云原生计算基金会）的毕业项目。我们建议使用2.0以后的版本，Harbor在2.0以后的版本使Harbor成
k8s集群上会跑各种各样的系统和应用程序的pod，而为了快速发现问题和更好的做日志监控，就必须要做日志的采集和集中存储展示了。综合考虑之下，我们推荐使用EFK技术栈来实现这个目的。k8s日志采集架构选型1，每台节点采用DaemonSet部署agent：原理：每台节点采用DaemonSet部署一个采集日志的agent，从/var/log/containers/目录采集所有容器的日志，而容器中的日志需
环境准备我们使用的k8s和ceph环境见：https://blog.51cto.com/leejia/2495558https://blog.51cto.com/leejia/2499684ECK简介ElasticCloudonKubernetes，这是一款基于KubernetesOperator模式的新型编排产品，用户可使用该产品在Kubernetes上配置、管理和运行Elasticsearch
最近再测试k8s集群，目前有一些有状态服务需要持久化存储，故调研了一番决定用已经被大家广泛使用的ceph来做。故通过学习ceph知识点书+自己的使用实践写了这篇文章。ceph简介Ceph是一个可无限伸缩的开源分布式存储系统，设计初衷是提供较好的性能、可靠性和可扩展性，它基于RADOS实现。在经过了数年的发展之后，目前已得到众多云计算厂商的支持并被广泛应用，RedHat及OpenStack都可与Ce
问题场景我们使用suricata来做流量分析，suricata部署在一台多网卡的48核心的物理机上，由于业务需要，suricata监听流量的网卡从5块提升为了6块，新加了网卡enp176s0f1，然后发现suricata的日志中有多条类似报错：<Error>-[ERRCODE:SC_ERR_PF_RING_OPEN(34)]-Failedtoopenenp176s0f1:pfring_
ingress做为k8s集群的入口非常重要，能实现ingress功能的软件很多，可根据自身需求选择。本篇博客主要使用nginx官方提供的nginx-ingress完成了http/https7层代理和tcp四层代理的环境配置。系统环境1，k8s的版本为1.8.22，dockerce的版本为19.03.8-33，五台主机操作系统版本为centos7，kernel版本3.10.0-9574，使用五台主机
由于业务需要，近期在研究k8s，故就需要先部署一套。我通过官方文档来部署发现还是有一些坑，故整理了部署中遇到的问题做个记录。系统环境1，k8s的版本为1.18.2，dockerce的版本为19.03.8-33，服务器操作系统版本为centos7，kernel版本3.10.0-9574，使用五台主机部署，机器列表172.18.2.175master1172.18.2.180master2172.18
出现的背景kubernetes是一个容器编排开源软件，它可以轻松高效管理由千上万的主机组成的集群，并提供容器部署运行的环境。kubernetes最初由Google开发和设计，前身是Borg系统，Google有成千上万的容器运行在上面，主要帮忙Google实现简化开发和管理，并且提供基础设施的资源利用率。再内部稳定运行Borg数十年之久后，随着容器化的大流行，2014年Google开源了kubern
容器技术出现的背景服务器时代在服务器时代，应用直接跑在服务器上。业务部门想要增加一个新的应用服务，IT部门就需要采购新的服务器服务器来满足需求，而IT部门为了不让业务由于服务器瓶颈而出现问题，就会采购大幅由于业务需求的服务器。这种做法，导致了公司大量的服务器处于低负荷运行状态下，浪费了大量的资源和资产。虚拟机时代而虚拟机技术解决了如上的问题，通过虚拟机技术，实现了一个服务器安全稳定运行多个应用。虚
背景收到nginx的超时报警和服务所在机器的load报警，通过分析问题时间段的系统cpu，内存，网络io，磁盘io使用情况，发现是磁盘io达到瓶颈导致。通过iostat看磁盘的await(平均每次设备I/O操作的等待时间)时间达几百毫秒且util(一秒中有百分之多少的时间用于I/O操作，即被io消耗的cpu百分比)持续100%分析定位问题服务1，通过使用iotop来看系统上使用io最多的进程，发现
Copyright © 2005-2025 51CTO.COM 版权所有 京ICP证060544号
