使用Harbor管理Docker镜像
前言根据Harbor官方描述： Harbor是一个用于存储和分发Docker镜像的企业级Registry服务器，通过添加一些企业必需的功能特性，例如安全、标识和管理等，扩展了开源Docker Distribution。作为一个企业级私有Registry服务器，Harbor提供了更好的性能和安全。提升用户使用Registry构建和运行环境传输镜像的效率。Harbor支持安装在多个Registry节点的镜像资源复制，镜像全部保存在私有Registry中， 确保数据和知识产权在公司内部网络中管控。另外，Harbor也提供了高级的安全特性，诸如用户管理，访问控制和活动审计等。 部署 添加docker官方源 sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo 安装docker yum list docker-ce --showduplicates | sort -r yum install -y docker-ce-18.06.3.ce-3.el7 ...
ES集群节点维护
写在前边的话由于生产环境需要，现将ES集群节点进行精减维护，以下为具体操作步骤： 注：操作时请使用root权限执行 数据迁移ES集群运行中，每个节点数据都是平均的，下线维护一个节点，先把该节点数据迁移到其他节点，避免发生意外。以下使用Kibana进行操作。 例如，如果准备对172.31.1.34节点做维护 迁移命令如下： PUT _cluster/settings { "transient": { "cluster.routing.allocation.exclude._ip": "172.31.1.34" } } 迁移后进行查看： GET _cluster/settings 返回以下内容： { "persistent": {}, "transient": { "cluster": { "routing": { ...
AWS常用cli命令
写在前边的话对AWS服务操作可以通过管理控制台、各语言SDK、CLI以及API等方式。管理控制台最简单，可以直接通过Web界面操作，但是有些服务或者服务下的某些操作无法直接用控制台调用； API的方式最复杂，需要自己生成哈希值签署请求以及处理请求错误等低级别的操作，AWS 的大部分服务都提供REST的API以及类似于REST的查询API，API提供的服务操作是最新最全面的； SDK 的好处是封装好了请求签署与请求错误处理以及重试机制，用户只需要直接调用相关接口即可，但对于新的服务及操作的支持可能会滞后于API接口的发布。CLI 其实也可以看成SDK的一种，它是AWS 服务操作的一把瑞士军刀。 本文针对项目实践中所用到的 AWS 服务的常用 CLI 命令进行一个简单总结，方便以后查阅。 EC2 挂载 EBS linux 查看块设备： lsblk 格式化磁盘： sudo mkfs -t ext4 /dev/xvdb 挂载卷： sudo mount /dev/xvdb /mnt/mydir 卸载卷： sudo umount /dev/xvdb windows di...
Kubernetes的Kube Proxy的转发规则分析
概要 filter表 nat表 Chain KUBE-SERVICES Chain KUBE-NODEPORTS (1 references) Chain KUBE-POSTROUTING (1 references) 报文处理流程图 发送到Node的报文的处理过程 Node发出的报文的处理过程概要 kube-proxy是kubernetes中设置转发规则的组件，通过iptables修改报文的流向。 以下是在一台kubernetes node节点上观察到的结果，kube-proxy是一个独立的组件，下面的观察结果适用于运行在其它地方的kube-proxy。 $kube-proxy --version kubernetes v1.5.2 通过iptables -L -t [iptables表名]可以看到，kube-proxy只修改了filter和nat表。五个检查点: INPUT OUPUT . | /_\ +--...
发布Azure资源管理（ARM）模板
以下为代码模板，根据自己情况修改{ "$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#", "contentVersion": "1.0.0.0", "parameters": { "virtualMachineName": { "type": "string", "metadata": { "description": "虚拟机名称" } }, "virtualMachineSize": { "type": "string", "defaul...
使用 CLI 创建 Azure VM 的自定义映像
自定义映像类似于应用商店映像，不同的是自定义映像的创建者是你自己。 自定义映像可用于启动配置，例如预加载应用程序、应用程序配置和其他 OS 配置。 在本教程中，你将创建自己的 Azure 虚拟机自定义映像。 你将学习如何执行以下操作： 取消预配和通用化 VM 创建自定义映像 从自定义映像创建 VM 列出订阅中的所有映像 删除映像 在 Azure 中国区使用 Azure CLI 2.0 之前，请先运行 az cloud set -n AzureChinaCloud 来改变云环境。如果想切回国际版 Azure，请再次运行 az cloud set -n AzureCloud。如果选择在本地安装并使用 CLI，本教程要求运行 Azure CLI 2.0.4 或更高版本。 运行 az --version 即可查找版本。 如果需要进行安装或升级，请参阅安装 Azure CLI 2.0。 开始之前下列步骤详细说明了如何将现有 VM 转换为可重用自定义映像，用于创建新的 VM 实例。若要完成本教程中的示例，必须现有一个虚拟机。 如果需要，此脚本示例可为你创建一个虚拟机。 按照教程进行操作时...
Kubernetes 滚动升级
run test deploy [root@k8s-master ~]# kubectl run --image=nginx --port=80 --replicas=2 test-nginx scale replica [root@k8s-master ~]# kubectl scale --replicas=1 deploy/test-nginx [root@k8s-master ~]# kubectl get deploy NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE busybox 2 2 2 2 39d busybox1 1 1 1 1 39d test-nginx 1 1 1 1 2h update image [root...
K8S的 QoS策略
QoSk8s中对容器的资源分配有三种策略： Guaranteed 。该策略下，pod.spec.containers[].resources中会存在cpu或memory的request和limit。顾名思义是该容器对资源的最低要求和最高使用量限制。如果我们配置了limit，没有配置request，默认会以limit的值来定义request。具体的配置可以参考以前的这篇笔记。 BestEffort。当pod的描述文件中没有resource.limit、resource.request相关的配置时，意味着这个容器想跑多少资源就跑多少资源，其资源使用上限实际上即所在node的capacity。 Burstable。当resource.limit和resource.request以上述两种方式以外的形式配置的时候，就会采用本模式。QoS目前只用cpu和memory来描述，其中cpu可压缩资源，当一个容器的cpu使用率超过limit时会被进行流控，而当内存超过limit时则会被oom_kill。这里kubelet是通过自己计算容器的oom_score，确认相应的linux进程的oom_a...
K8s容器一直重启问题排查
问题昨天有个客户反馈服务不可访问，查看服务日志发现dns无法解析，通过kubectl查看kube-dns 这个pod一直在重启，客户只反馈了这一个问题，如图： 过了一会后发现kube-dns灾厄已经恢复，但是kube-flannel这个pod又开始一直重启。根据自己以往的经验还以为是路由出了什么问题，所以在排查路由方面浪费了一些时间， 排查一段时间路由后未发现异常，随后想到查看有问题机器的kubelet日志，如下 describe node的Events如下： 解决通过日志可以发现是磁盘满导致的原因，但在当时看到问题时只是根据经验以为是路由有问题（只能说是学艺不精），但是我还没来得及查看磁盘，就补客户给清理过，而且客户还顺手把机器给重启了，机器启动后一切就恢复正常 排查后来上网搜索相关错误字段，随后阅读相关文章以及查看k8s代码，发现k8s有一个Eviction Manager的机制，如下图： 如果在启动k8s时没有设置Eviction Thresholds（驱逐阈值)，k8s将按代码里（上图）默认的值执行 但是通过可看kubelet日志发现，前一天的时候就已经发现有相关报...
Kubernetes Eviction Manager工作机制分析
摘要为了极限的压榨资源，很多时候Kubernetes集群会运行一些Best-Effort Task，这样就会存在资源超配的情况，Kubernetes是如何控制Node上资源的使用，在压榨资源使用的同时又能保证Node的稳定性？本文就为你介绍其背后运行机制。我的下一篇博文，会对Kubelet Eviction Manager进行源码分析，感兴趣的同学可以关注。 研究过Kubernetes Resource QoS的同学，肯定会有一个疑问：QoS中会通过Pod QoS和OOM Killer进行资源的回收，当发生资源紧缺的时候。那为什么Kubernetes会再搞一个Kubelet Eviction机制，来做几乎同样的事呢？ 首先，我们来谈一下kubelet通过OOM Killer来回收资源的缺点： System OOM events本来就是对资源敏感的，它会stall这个Node直到完成了OOM Killing Process。 当OOM Killer干掉某些containers之后，kubernetes Scheduler可能很快又会调度一个新的Pod到该Node上或者contai...
