请查看官方的说明 kubectl cp --help 官方说使用cp , pod里需要有tar命令 从k8s pod 中 拷贝 文件到本地 这是我使用的命令 kubectl exec redis-6c98cb5b5f-nxb59 -- tar cPf - /data/dump_redis.rdb | sudo tar xf - -C . 出现这个报错,tar: Removing leading /' from member names` 可以忽略 会在当前目录产生 data/dump_redis

不要重复造轮子,我觉得这个方案比较适合现在的情况. 我们知道,如果手工查看k8s里指定pod的日志输出,一般的方案如下: kubectl logs -f -n [namespace] [pod] -c [container] 那如何移值到gotty下面,通过web方式查看呢? 第一步,启动gotty,限制用户能输入的命令(防止非法操作) ./gotty -w -p 8081 --title-format 4k --permit-arguments kubectl logs -f 第二步,通过浏览

K8S监控实战-ELK收集K8S内应用日志 目录 K8S监控实战-ELK收集K8S内应用日志 1 收集K8S日志方案 1.1 传统ELk模型缺点: 1.2 K8s容器日志收集模型 2 制作tomcat底包 2.1 准备tomcat底包 2.1.1 下载tomcat8 2.1.2 简单配置tomcat 2.2 准备docker镜像 2.2.1 创建dockerfile 2.2.2 准备dockerfile所需文件 2.2.3 构建docker 3 部署ElasticSearch 3.1 安装Ela

问题描述: 阿里云k8s应用日志之前一直都是可以正常的采集, 先出现一问题, 通过kibana 和阿里云的日志服务都没法展示最新的k8s应用的日志, 部分应用的最新日志有被采集到,但大部分应用日志没有做采集到. 通过 命令 curl '17*****0:9200/_cat/indices?v' 查看 部分应用没有建立今天的日志索引 删除了elasticsearch组件, 再重新安装以后, 问题依然存在 通过 kubectl delete DaemonSet log-pilot -n kube-s

[k8s]k8s pod的4种网络模式最佳实战(externalIPs )       hostPort相当于docker run -p 8081:8080,不用创建svc,因此端口只在容器运行的vm上监听 缺点: 没法多pod负载 $ cat pod-hostport.yaml apiVersion: v1 kind: Pod metadata: name: webapp labels: app: webapp spec: containers: - name: webapp image: t

一.k8s pod 在节点间调度控制 k8s起pod时,会通过调度器scheduler选择某个节点完成调度,选择在某个节点上完成pod创建.当需要在指定pod运行在某个节点上时,可以通过以下几种方式: 1. 在部署pod的yaml中,指定nodeName 指定了nodeName的Pod会直接跳过Scheduler的调度逻辑,直接写入PodList列表,该匹配规则是强制匹配.eg:apiVersion: extensions/v1beta1kind: Deploymentmetadata: nam

自建k8s集群 的master 节点安装 logtail 采集工具 wget http://logtail-release-cn-hangzhou.oss-cn-hangzhou.aliyuncs.com/kubernetes/alicloud-log-k8s-custom-install.sh; chmod 744 ./alicloud-log-k8s-custom-install.sh; sh ./alicloud-log-k8s-custom-install.sh k8s-*******m

文章拷于:http://blog.itpub.net/28916011/viewspace-2216748/   用于自己备份记录错误 一个完整的k8s集群,应该包含如下六大部分:kube-dns.ingress-controller.metrics server监控系统.dashboard.存储和EFK日志系统. 我们的日志系统要部署在k8s集群之外,这样即使整个k8s集群宕机了,我们还能从外置的日志系统查看到k8s宕机前的日志. 另外,我们生产部署的日志系统要单独放在一个存储卷上. 这里我们

一.问题所在 在K8S里启动一个容器,该容器的设置的时区是UTC0,但是对于很多客户而言,其主机环境并不在UTC0.例如中国客户在UTC8.如果不把容器的时区和主机主机设置为一致,则在查找日志等时候将非常不方便,也容易造成误解. 二.解决方法 1.挂载服务器的时区 [root@k8s-m ~]# cat demo-pod.yaml apiVersion: v1 kind: Pod metadata: name: nginx-pod namespace: default labels: app:

日志系统elfk 前言 经过上周的技术预研,在本周一通过开会研究,根据公司的现有业务流量和技术栈,决定选择的日志系统方案为:elasticsearch(es)+logstash(lo)+filebeat(fi)+kibana(ki)组合.es选择使用aliyun提供的es,lo&fi选择自己部署,ki是阿里云送的.因为申请ecs需要一定的时间,暂时选择部署在测试&生产环境(吐槽一下,我司测试和生产公用一套k8s并且托管与aliyun......).用时一天(前期有部署的差不多过)完成在ku

k8s系列文章: 什么是K8S K8S configmap介绍 Pod是k8s中最小的调度单元,包含了一个"根容器"和其它用户业务容器. 如果你使用过k8s的话,当然会了解pod的基本使用,但是为了更好的应用,你需要深入了解pod的配置.调度.升级和扩缩容等.本文将会更进一步的介绍pod. 基础 为什么需要pod? pod包含一个或多个相对紧密耦合的容器,处于同一个pod中的容器共享同样的存储空间.IP地址和Port端口. 为什么k8s要设计出Pod这个概念并作为最小调度单元呢? 直接

关键词:k8s.jvm.高可用 1.背景 最近有运维反馈某个微服务频繁重启,客户映像特别不好,需要我们尽快看一下. 听他说完我立马到监控平台去看这个服务的运行情况,确实重启了很多次.对于技术人员来说,这既是压力也是动力,大多数时候我们都是沉浸在单调的业务开发中,对自我的提升有限,久而久之可能会陷入一种舒适区,遇到这种救火案例一时间会有点无所适从,但是没关系,毕竟...... "我只是收了火,但没有熄炉",借用电影中的一句话表达一下此时的心情. 2.初看日志 我当即就看这个服务的运行日志

一次迁移中出现的问题,因为要搬迁机房,集群中的节点服务器分布在两个机房,通过专线打通了,现在需要整体都迁移到其中一个机房,所以pod要进行迁移,机器资源也比较紧张,在迁移中zookeeper迁移出现问题. //master上查看zk pod情况 [root@master-web-38 ~]# kub

我们知道,当访问量或资源需求过高时,使用:kubectl scale命令可以实现对pod的快速伸缩功能 但是我们平时工作中我们并不能提前预知访问量有多少,资源需求多少. 这就很麻烦了,总不能为了需求总是把pod设置为最多状态,这样太浪费资源:也不能当请求量上来以后再去伸缩pod,这样会有好多请求不成功. k8s既然是云原生时代的产品,当然得有智能,自动这些特性. 所以现在引入一个新的概念: HPA(Horizontal Pod Autoscaler ) pod的自动水平伸缩 有了HPA,我们就不

环境概况 自建k8s集群,主机操作系统ubuntu16.04,k8s版本v1.14, 集群网络方案calico-3.3.6. worker节点数50+,均为GPU物理服务器,服务器类型异构,如Nvidia P4/T4/V100等. 异常现象 故障起因是k8s集群新增加了一台worker节点机器server-n1,该机器上带有8张网卡eth0~eth7, 其中eth0~eth3没有配置ip地址,eth4~eth7配置了ip地址,默认使用eth4网卡. 调度到server-n1节点上的pod,无法访

看系统日志 cat /var/log/messages 用kubectl 查看日志 # 注意:使用Kubelet describe 查看日志,一定要带上 命名空间,否则会报如下错误[root@node2 ~]# kubectl describe pod coredns-6c65fc5cbb-8ntpvError from server (NotFound): pods "coredns-6c65fc5cbb-8ntpv" not found kubectl describe pod k

#Pod生命周期,健康检查 pod创建过程 Init容器 就绪探测 存活探测 生命周期钩子 #Pod创建过程 master节点:kubectl -> kube-api -> kubenlet -> CRI容器环境初始化 Node节点: pause容器(网络和数据卷) -> Init容器(若有) -> 主容器(start,容器探针,top) #Init容器 Init容器用来阻塞或延迟应用容器的启动,直到满足决条件,成功退出 在所有的 Init 容器没有成功之前,Pod不会变成

注意步骤: 一般删除步骤为:先删pod再删pvc最后删pv 但是遇到pv始终处于“Terminating”状态,而且delete不掉 pod一直删不掉 [root@hadoop01 nacos-k8s]# kubectl get pod NAME READY STATUS RESTARTS AGE busybox-deployment-8588b74c4b-4rc24 / Terminating 45h metrics-app-v1-5cdbf6d7f4-8pqxj / Running 24d

今天我们来玩一下混沌工程的开源工具chaostoolkit . 它的目标是提供一个免费,开放,社区驱动的工具集以及api. 官方源码链接:https://github.com/chaostoolkit/chaostoolkit 要想了解这个工具就必须知道混沌工程原则中提到的要点.如下所示: 记往这里提到的第一个要点,建立稳态假设. 在运行这个工具之前,我们先来看一下它的架构. 简单来解释一下,就是ChaosToolkit通过Drivers来操作你的被测系统. 它的功能点包括如下部分: 下面我们把

背景 某项目采用微服务架构,dubbo 框架,K8s 方式部署. 其中 HTTP 协议由网关应用统一处理,大部分应用仅提供 dubbo 协议. 目标 应用某个实例(pod)状态异常时,尝试自动重启恢复. 解决 K8s 提供了3种存活探针(livenessProbe),以实现 pod 状态异常时重启. HTTPGetAction 首先排除了,因为上文我们说了,HTTP 访问由网关统一处理,应用本身没有 HTTP 协议. 然后是 TCPSocketAction,该探针仅能确认 dubbo 端口是否为