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

我花了10个小时,写出了这篇K8S架构解析 https://www.toutiao.com/i6759071724785893891/   每个微服务通过 Docker 进行发布,随着业务的发展,系统中遍布着各种各样的容器.于是,容器的资源调度,部署运行,扩容缩容就是我们要面临的问题. 基于 Kubernetes 作为容器集群的管理平台被广泛应用,今天我们一起来看看 Kubernetes 的架构中有那些常用的组件以及运行原理. Kubernetes 架构概述 Kubernetes 是用来管理容器

思想: 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-

今天研究了一下k8s的网络模型,该解析基于flannel vxlan+ kubeproxy iptables 模式. 一.Docker 首先分析一下Docker层面的网络模型,我们知道容器是基于内核的namespace机制去实现资源的隔离的.network是众多namespace中的一个,那么如何保证一个节点上容器之间的通信呢?Docker的做法是通过虚拟网桥来桥接虚拟网卡.下面具体解释一下. 首先每一个容器在默认情况下都是在自己的network namespace里面的,也就是说默认情况下它只

CoreDNS解析异常记录 异常情况:集群是用kubespray部署的4个worknode,coredns默认部署2个deployment.今天发现部署了coredns的node上的pod正常解析内部域名,而另外2个未运行coredns的node却无法解析. 配置文件: 下图中我们看到coredns2个pod分别在node1与node2上,只要分配到这2节点上的deployment都可以正常解析. 其他节点无法解析: 处理过程: 正常来说所有的pod都是通过coredns来进行集群内域名解析的,

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

一. 实践说明 首先我们先创建一组资源,包括一个deployment和一个service apiVersion: apps/v1 kind: Deployment metadata: name: nginx labels: name: nginx spec: selector: matchLabels: name: nginx1 replicas: 1 template: metadata: labels: name: nginx1 spec: nodeName: meizu container

摘要: 集群其他组件全部完成后我们应当部署集群 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

前提条件:已经部署好ceph集群 本次实验由于环境有限,ceph集群是部署在k8s的master节点上的 一.创建ceph存储池 在ceph集群的mon节点上执行以下命令: ceph osd pool create k8s-volumes 64 64 查看下副本数 [root@master ceph]# ceph osd pool get k8s-volumes size size: pg的设置参照以下公式: Total PGs = ((Total_number_of_OSD * ) / max

Docker+K8s基础篇(二) docker的资源控制 A:docker的资源限制 Kubernetes的基础篇 A:DevOps的介绍 B:Kubernetes的架构概述 C:Kubernetes的集群安装 Kubernetes的简单应用 A:Kubernetes命令的介绍和使用 B:Kubernetes的增删改查: C:service资源的增删改查: D:pods资源的滚动部署,升级,回滚: ♣一:docker的资源控制 A:docker的资源限制 在之前我们提到过容器有6大基本功能组成,

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

不得不说千万不要随意更改版本,我用的1.13的版本,然后学到这一步时,还因yaml文件不同,卡住了很久,然后各种google才找到解决办法  https://www.linuxea.com/2112.html 以前是用heapster来收集资源指标才能看,现在heapster要废弃了. 从k8s v1.8开始后,引入了新的功能,即把资源指标引入api. 资源指标:metrics-server 自定义指标: prometheus,k8s-prometheus-adapter 因此,新一代架构: 1

3.Volume 容器磁盘上的文件的生命周期是短暂的,这就使得在容器中运行重要应用时会出现一些问题.首先,当容器崩溃时,kubelet 会重启它,但是容器中的文件将丢失--容器以干净的状态(镜像最初的状态)重新启动.其次,在Pod 中同时运行多个容器时,这些容器之间通常需要共享文件.Kubernetes 中的 Volume 抽象就很好的解决了这些问题 docker 启动时 命令有 restar 为always时 容器崩溃等重新启动不是以干净的状态启动,而是会恢复到原来的状态 Kubernetes

服务发现,说白了就是服务(应用)之间相互定位的过程. 服务发现需要解决的问题: 1.服务动态性强--容器在k8s中ip变化或迁移 2.更新发布频繁--版本迭代快 3.支持自动伸缩--大促或流量高峰 我们为了解决pod地址变化的问题,我们之前部署了service资源,将pod地址通过service资源暴露的固定地址,来解决以上问题, 那么,如何解决service资源名称和service资源暴露出来的集群网络IP做自动的对应呢,从而达到服务的自动发现呢? 在k8s中,coredns就是为了解决以上问

资源指标:metrucs-server 自定义指标:prometheus, k8s-prometheus-adapter(转换prometheus数据的格式) 新一代架构: 核心指标流水线:由kubelet.metrics-server以及由API server提供的api组成:CPU累积使用率.内存实时使用率. Pod的资源占用率及容器的磁盘占用率: 监控流水线:用于从系统收集各种指标数据并提供终端用户.存储系统以及HPA,它们包含核心指标及许多非核心指 标.非核心指标本身不能被k8s所解析,

配置说明 官方有使用etcd插件的详细说明,地址如下:https://coredns.io/plugins/etcd/ 需要特别说明的是,目前coredns只支持etcd v2版本的api 这里直接摘出用法示例: etcd [ZONES...] { stubzones fallthrough [ZONES...] path PATH endpoint ENDPOINT... upstream [ADDRESS...] tls CERT KEY CACERT } 常用参数说明: ZONES :经过

1.部署metrics-server 从v1.8开始,引入了新的功能,即把资源指标引入api,资源指标:metrics-server,自定义指标:prometheus,k8s-prometheus-adapter(把prometheus采集的数据转化成k8s可理解的数据). 新一代架构: a.核心指标流水线:由kubelet.metrics-server以及由API server提供的api组成; cpu累计利用率.内存实时利用率.pod的资源占用率及容器的磁盘占用率; b.监控流水线:用于从系

目录 资源指标: Metrics-Server 资源指标: Metric-Server介绍 Metric-Server部署 下载yaml文件 因为有墙, 所以提前下载image镜像, 当然也可以手动修改yaml相关文件 修改文件, 不然报错 创建Metric-Server 自定义资源指标: Prometheus k8s-prometheus-adapter 项目 Prometheus 在k8s集群中部署Prometheus github地址 需要部署的服务清单 安装部署所有服务及插件 部署kub

快速入门 实验:通过服务自动发现的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