作者：溪恒、谢石、遐宇 Kubernetes 本身比较复杂，使用门槛较高，用户在开始容器化迁移时经常遇到各种各样的问题，由于缺乏故障定位的技能和工具，用户常常产生挫败感，甚至放弃业务容器化。其中网络问题表现尤为突出，Kubernetes 网络虚拟化导致网络问题排查的难度巨大。 KubeSkoop 是阿里云容器服务团队开源的 Kubernetes 容器网络诊断工具，支持主流的网络插件和云厂商的 Ku

前言 本文将对Kubernetes中的Service相关的网络基础知识进行梳理，并会演示如何从零搭建一个Ingress，所有镜像在国内均可下载，参考资料为《kubernetes权威指南：从docker到kubernetes实践全接触》第五版。 正文 一. 前置准备 为了演示网络相关的概念，这里准备了一个一主两从的K8s集群，集群节点信息如下所示。 NAME STATUS ROLES AGE VER

作者：庄宇 Kubernetes 作为一项核心技术已成为现代应用程序架构的基础，将 Kubernetes 作为容器编排系统已发展为越来越多企业的必然选择。 随着对云计算接受程度不断提高，以及企业规模和业务持续发展的共同驱动下，越来越多的企业在考虑或已经采用多云和混合云方案，以提升架构的灵活性和健壮性。 Kubernetes 多集群需求的演进及运维挑战 企业可能会将集群部署在不同云厂商的公有云 K8

来源｜KubeWharf 社区 项目地址：github.com/kubewharf/k… Kelemetry是字节跳动开发的用于Kubernetes控制平面的追踪系统，它从全局视角串联起多个 Kubernetes 组件的行为，追踪单个 Kubernetes 对象的完整生命周期以及不同对象之间的相互影响。通过可视化 K8s 系统内的事件链路，它使得 Kubernetes 系统更容易观测、更容易理解、

Docker容器编排工具是一种用于自动化应用程序部署和管理的工具。在容器化应用程序的世界中，容器编排工具是必不可少的。本文将介绍两个最常用的Docker容器编排工具：Kubernetes和Docker Swarm，并探讨如何使用它们来提高应用程序的可靠性和可扩展性。 Kubernetes是Google开源的容器编排系统，它可以自动化部署、扩展和管理容器化应用程序。Kubernetes提供了一种高度

Kubernetes 作为一项核心技术已成为现代应用程序架构的基础，越来越多的企业使用其作为容器编排系统。Kubernetes 集群经历了 从单 Kubernetes 集群到多 Kubernetes 集群、从多 Kubernetes 集群到 Kubernetes 多集群的演进[1]，集群的展现形式不断发生着变化。 为此，Kubernetes 多集群 SIG 提出了 KEP-1645: Multi-

在过去的文章中，我们曾 追踪过 Kubernetes 中的网络数据包[1]，这篇文章将追踪 Kubernetes 中的 DNS 查询。 让我们以在 Pod 中解析 Service 完全限定域名（FQDN） foo.bar.svc.cluster.local 为例。 在开始之前，先回顾下 DNS 的解析流程。 DNS 的解析流程 图片 简化版的 DNS 处理流程： DNS 客户端（如浏览器、应用程序

本次环境都在kebernetes v1.11.2，准备了四台使用centos7.5机器来做kubernetes的测试，有三台节点ip段均为10.10.240.0/24段(这意味着其他ip段无法加入)，pod网络使用172.16.0.0/16，server网络使用默认10.96.0.0/12 其中分别使用aliyun的镜象站点和谷歌官网的资源进行安装和配置，可做部分参考大致的情况如下： 先决条件 1

在之前的一章中简单的介绍了Yum安装kubernetes的方式，这次的笔记记录kubernetes的一些基础入门的一些操作，更多的是关乎于kubectl的一些使用，如：创建pod，scv，动态的增删，回滚，以及简单的网络等 kubectl kubectl其实就是kubernetes的一个客户端程序，他通过连接master节点上的api-server，而在api-server上，kubectl就是唯

pod是有生命周期的，为了给对应的客户端提供一个固定的访问端点。在客户端与服务pod之间提供一个中间层Service，service严重依赖kubernetes(1.11.2)之上的附件CoreDNS(kube-dns) kubernetes的名称解析，强依赖于CoreDNS，在kubernetes中的名称解析中必须存在CoreDNS kubernetes提供的网络功能，需要依赖于第三方网络方案，

在之前，我们知道应用程序分为两类，一种是有状态，一种无状态。无状态的有nginx等。有状态的居多。 如：redis,mysql,zook集群等，其中一些不单单有主从状态，更有启动顺序等的区分。这时候可使用statefulse，但是statefulse在完成一些配置的时候仍然是非常麻烦的，很多时候需要手动编写脚本，或者依赖于地第三方的一些工具来做。statefulse在处理，特别是在一些运维逻辑非常

kubernetes上运行着众多的应用，特别是无状态的应用，更甚有一些核心的数据。对于这些数据的访问或者管理，并不是任何人可以随意的管理使用的。因此，kubernetes对于整个系统的认证，授权，以及后续的访问控制做了非常紧密和精心的设计。 通常，客户端通过客户端工具kubectl来访问kubernetes， 对于管理员或者kubectl来讲api server是作为管理的唯一入口。 这联想起了i

之前我们知道kubernetes的授权是用插件来实现，并且支持很多插件，并且支持很多插件同时使用，且只要通过其中一个授权检查通过则不会在进行其他插件进行检查，而后由准入控制插件后续检查。 授权插件常用有四个：节点Node，ABAC属性访问控制，RBAC，Webhook回掉机制实现授权、 RBAC RBAC的全称是Role-based AC，在kubernetes中RBAC就是定义标准的资源： Ro

延续上一篇Role和Cluster Role示例,其中绑定都是role绑定rolebinding，clusterrole绑定clusterrolebinding，现在使用rolebinding绑定clusterrole，这样以来权限就会降级到rolebinding所在的权限 我们先切换到kubernetes-admin用户下 [root@linuxea role]# kubectl config

dashboard也是做为kubernetes核心附件存在，这种附件还有就是作为名称解析和服务发现的coredns，通常系统部署后会自动安装。Dashboard在新的版本里面有这复杂的权限检查机制 在使用kubeadm安装的RBAC默认强制启用的，而Dashboard接口是管理整个集群的接口，认证管理的方式类似于“自我认证”。 它类似于kubernetes集群UI前段，认证也是kubernetes

之前介绍的pod资源调度，此篇主要记录的是kubernetes上运行pod的对象的时，如何去监控系统级的一些资源指标，业务指标的获取，以及监控。 容器在启动的时候，可以根据资源需求，配置资源限额的，如CPU，内存。而CPU资源属于可压缩资源，一个容器在本应该获取指定的资源获取不到的时候，进行等待即可，而内存则不一样。内存属于非可压缩资源，如果内存资源因为指定的大小而不够的时候会因为内存资源耗尽而被

在docker中可以使用那个stats查看容器的资源使用，而在Kubernetes中可以使用top查看。但是一般都会报错，如下： [root@linuxea metrics]# kubectl top pod Error from server (NotFound): the server could not find the requested resource (get services ht

metrics-server metrics-server是用户开放的一个api server，这个api server用于服务资源指标服务器，并不是服务kubernetes api，更不是服务pod api，仅仅用于服务cpu利用率，内存使用率等等对象。 metrics-server并不是kubernetes组成部分，只是托管在kubernetes之上的一个pod，为了能让用户使用metrics

核心组件与程序架构 核心组件 Chart 一个helm程序包，包含了k8s上部署应用程序的清单的定义(并不包含镜像，镜像是由镜像仓库来提供)，镜像的引用，依赖关系，资源定义等等。必要时，包含其他的定义，如：Service. Repository 而Chart是有多个，放置到Repository，也可以说是一个Chart。同时也是一个http/https服务器。 Release Chart实例化后部

etcd是一个分布式键值存储，它提供了一种在一组机器上存储数据的可靠方法。它是开源的，可在GitHub上获得。etcd在网络分区期间优雅地处理leader选举，并且可以容忍机器故障，包括leader。 应用程序可以将数据读写到etcd中。一个简单的用例是将etcd中的数据库连接详细信息或功能标记存储为键值对。可以监视这些值，允许您的应用在更改时重新配置。 高级用法利用一致性保证来实现数据库lead