1. 查询k8s集群部署pod的基本情况 如下图,我们可知容器coredns和dnsutils都部署成功,但是由于域名解析的问题,导致coredns和dnsutils的容器不断重启(原因heath检查,无法请求成功,被kubelet重启了pod) 命令如下: root >> kubectl get all --all-namespaces -o wide root >> kubectl describe pod coredns-57bbd778b9-kxl7b -n kube-sy

K8S CoreDNS部署失败,查看错误日志,提示如下 root >> kubectl get all --all-namespaces -o wide root >> kubectl logs -f coredns-56f56989d6-krs6h -n kube-system 错误提示,如下: Failed to list *v1.Namespace: Get https://10.3.0.1:443/api/v1/namespaces?limit=500&resour

思想: kube-dns或coredns本质上是一个dns服务软件.都需要配置配置文件.要控制怎么查询,即控制他的配置文件即可. 本文先说下coredns怎么配置,然后在配下kube-dns(包含了外建dnsmasq搭建,模拟集群访问公司私有域情景) 参考: https://coredns.io/2017/03/01/coredns-for-kubernetes-service-discovery-take-2/ https://coredns.io/2017/05/08/custom-dns-

最近由于master整个挂掉,导致相关一些基础服务瘫掉,修复中测试有些节点网络又出现不通的情况正常的启动相关一些服务后,测试一些节点,比较费劲,还有进入pod,以及还有可能涉及命名空间操作这里可以这样,当然前提你的coredns是正常的,而且我用的版本是 版本信息 Calico Version v3

上一章我们已经通过yaml文件将.netcore程序跑起来了,但还有一下细节问题可以分享给大家. 1.pod管理 1.1创建pod kubectl create -f netcore-pod.yaml 我们创建一个netcore-pod.yaml文件,内容如下: apiVersion: v1 kind: Pod #指明类型 metadata: name: netcore-pod labels: app: netcorepod spec: containers: - name: netcorepo

摘要: 集群其他组件全部完成后我们应当部署集群 DNS 使 service 等能够正常解析,1.11版本coredns已经取代kube-dns成为集群默认dns. 1)下载yaml配置清单 [root@k8s-master01 ~]# mkdir /opt/k8s/coredns [root@k8s-master01 ~]# cd /opt/k8s/coredns/ [root@k8s-master01 coredns]# wget https://raw.githubusercontent.c

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

说明:部署的过程中请保证每个命令都有在相应的节点执行,并且执行成功,此文档已经帮助几十人(仅包含和我取得联系的)快速部署k8s高可用集群,文档不足之处也已更改,在部署过程中遇到问题请先检查是否遗忘某个步骤,文档中每个步骤都是必须的. 经测验此文档也适合高可用部署k8s v.12,只需修改对应版本号就可. 1.部署架构 详细架构: 2.基本配置 主机名 IP地址 说明 组件 k8s-master01 ~ 03 192.168.20.20 ~ 22 master节点 * 3 keepalived.n

快速入门 实验:通过服务自动发现的redis主从 难点: 1,服务的自动发现,即如何确定coreDNS 已生效 2,redis的主从验证 遇到的问题: 1,Can't handle RDB format version 9 解决:一般是低版本无法兼容高版本的 rdb 导致的.要求删除 dump.rdb文件,再启动 redis-server. 但是pod 中命令不足,所以自己新建镜像使用. 2,使用k8s 起的pod 和docker 起的容器,在容器内部 /etc/resolve.cnf内的ns

Kubernetes addons 之 coredns部署 2019.06.04 18:04:35字数 1045阅读 121 DNS 是 Kubernetes 的核心功能之一,通过 kube-dns 或 CoreDNS 作为集群的必备扩展来提供命名服务. Kubernetes基于DNS的服务发现 在Kubernetes集群推荐使用Service Name作为服务的访问地址,因此需要一个Kubernetes集群范围的DNS服务实现从Service Name到Cluster Ip的解析,这就是Kub

最近在公司的数据同步项目(以下简称 ZDTP)中,需要使用到分布式调度数据同步执行单元,目前使用的方案是将数据同步执行单元打包成镜像,使用 K8s 进行调度. 在 ZDTP 中,数据同步的动作可抽象成一个执行单元(以下称为 worker),类似于线程执行单元 Runnable ,Runnable 放入一个队列中等待线程的调度执行,执行完 Runnable 即完成了它的使命.当用户在 ZDTP 控制台中创建同步任务并启动任务时,会根据同步任务的配置,产生若干个用于该任务的 worker,假设这些

现状 加参数 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=logs/test.dump 可以实现在jvm发生内存错误后 会生成dump文件 方便开发人员分析异常原因. 当运行在k8s中,如果进程发生错误 导出dump文件后 ,k8s会重启dokcer容器,上一次崩溃生成的dump文件就没有了.如果应用并没有完全崩溃 此时极其不稳定 最好也能通知到技术人员来处理.这样不方便我们排查原因 所有写了一个小工具.大概原理如下 1. -XX:+Heap

1 kubernetes组件 1.1 Kubernetes 集群图 官网集群架构图 1.2 组件及功能 1.2.1 控制组件(Control Plane Components) 控制组件对集群做出全局决策(例如,调度),以及检测和响应集群事件. 例如,当检测到一个deployment的replicas字段不满足设定值时就会启动一个新的pod. kube-apiserver k8s API Server提供了k8s各类资源对象(pod,RC,Service等)的增删改查及watch等HTTP Re

写在开始之前,在开始之前我们需要了解几个概念: 1.什么是持续集成? 持续集成是一种软件开发实践,即团队开发成员经常集成他们的工作,通常每个成员每天至少集成一次,也就意味着每天可能会发生多次集成.每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽快地发现集成错误.许多团队发现这个过程可以大大减少集成的问题,让团队能够更快的开发内聚的软件. 2.什么是 kubernetes? Kubernetes 是一个开源的,用于管理云平台中多个主机上的容器化的应用,Kubernetes 的

实验环境 基础架构 主机名 角色 ip HDSS7-11.host.com k8s代理节点1 10.4.7.11 HDSS7-12.host.com k8s代理节点2 10.4.7.12 HDSS7-21.host.com k8s运算节点1 10.4.7.21 HDSS7-22.host.com k8s运算节点2 10.4.7.22 HDSS7-200.host.com k8s运维节点(docker仓库) 10.4.7.200 硬件环境 5台vm,每台至少2c2g 软件环境 OS: CentOS

Istio多集群(1)-多控制面 参考自官方文档. 目录 Istio多集群(1)-多控制面 复制控制面 要求 在每个集群中部署Istio控制面 配置DNS 配置应用服务 配置用例服务 卸载 FAQ 复制控制面 本节将使用多个主集群(带控制面的集群)来部署Istio多集群,每个集群都有自己的控制面,集群之间使用gateway进行通信. 由于不使用共享的控制面来管理网格,因此这种配置下,每个集群都有自己的控制面来管理后端应用.为了策略执行和安全目的,所有的群集都处于一个公共的管理控制之下. 通过复制

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

Kubernetes服务pod的健康检测liveness和readiness详解 接下来给大家讲解下在K8S上,我们如果对我们的业务服务进行健康检测. Health Check.restartPolicy 这里我们再进一步,来聊聊K8s上面服务的健康检测特性.在K8s上,强大的自愈能力是这个容器编排引擎的非常重要的一个特性,自愈的默认实现方式是通过自动重启发生故障的容器,使之恢复正常.除此之外,我们还可以利用Liveness 和 Readiness检测机制来设置更为精细的健康检测指标,从而实现如

Pod生命周期 我们一般将pod对象从创建至终这段时间范围成为pod的生命周期,它主要包含以下的过程: pod创建过程 运行初始化容器(init container)过程 运行主容器(main container) 容器启动后钩子(post start).容器终止前钩子(pre stop) 容器的存活性检测(liveness probe).就绪性检测(readiness probe) pod终止过程 pod的创建和终止 pod的创建过程 用户通过kubectl或其他api客户端提交需要创建的po

1. k8s-生产环境部署django项目k8s-dashboard管理系统 gitee地址: https://gitee.com/scajy/django-k8s-dashboard.git 部署架构 nginx 前端web服务,接收到动态请求通过uwsgi模块将请求转发给uwsgi服务器,uwsgi服务器通过django处理完后返回给Nginx,Nginx返回用户浏览器展示. 既然uwsgi是一个可以独立部署的服务器,为什么还用Nginx代理? Nginx作为入口可配置安全策略,并且可以为u