k8s经典理论,深入剖析k8s

k8s 基本使用（上）

本文将介绍 k8s 中的一些最基本的命令，并辅以解释一些基本概念来方便理解，也就是说，本文是一篇偏向实用性而非学术性的文章，如果你想提前了解一下 k8s 相关的知识的话，可以通过以下链接进行学习：

k8s 是经典的一对多模型，有一个主要的管理节点 master 和许多的工作节点 slaver 。当然，k8s 也可以配置多个管理节点，拥有两个以上的管理节点被称为 高可用 。k8s 包括了许多的组件，每个组件都是单运行在一个 docker 容器中，然后通过自己规划的虚拟网络相互访问。你可以通过 kubectl get pod -n kube-system 查看所有节点上的组件容器。

在管理节点中会比工作节点运行更多的 k8s 组件，我们就是靠着这些多出来的组件来对工作节点发号施令。他们都叫什么这里就不详细提了。反正对于”基本使用“来说，这些名字并不重要。

要想理解一个东西就要先明白它的内在理念。通俗点就是，k8s 做了什么？为了提供更加可靠的服务，就要增加服务器的数量，减少每个服务器的体量来平摊负载，而越来越多的虚拟机就会带来越来越高的运维成本。如何让少量的运维人员就可以管理数量众多的服务器及其上的服务呢？这就是 k8s 做的工作。

k8s 把数量众多的服务器重新抽象为一个统一的资源池 ，对于运维人员来说，他们面前没有服务器1、服务器2的概念，而是一个统一的资源池，增加新的服务器对运维人员来说，只是增加自资源池的可用量。不仅如此，k8s 把所有能用的东西都抽象成了资源的概念，从而提供了一套更统一，更简洁的管理方式。

接下来，我会把每个基本命令当做一节来进行介绍，并辅以介绍一些基本概念。本文介绍的命令涵盖了增删改查四方面，可参加下面表格，因为篇幅较长，我们将 create 及之后的不那么常用的命令放在下一篇文章 k8s 基本使用（下） 里讲：

接下来进入正题，首先来了解一下 k8s 中最最最常用的命令 kubectl get ，要记住，k8s 把所有的东西都抽象成了资源，而 kubectl get 就是用来查看这些资源的。最常见的资源就是 pod 。

不仅我们自己的服务是要包装成 pod 的，就连 k8s 自己也是运行在一堆 pod 上。接下来就让我们查看一下 k8s 的 pod ：

-n 参数指定了要查看哪个命名空间下的 pod 。 k8s 所有的 pod 都被放置在 kube-system 命名空间下。

执行了 kubectl get pod -n kube-system 命令后，你就可以看到如下内容：

其中每一行就是一个资源，这里我们看到的资源是 pod 。你看到的 pod 数量可能和我的不一致，因为这个列表里包含了 k8s 在所有节点上运行的 pod ，你加入的节点越多，那么显示的 pod 也就越多。我们来一列一列的看：

kubectl get 可以列出 k8s 中所有资源

这里只介绍了如何用 kubectl 获取 pod 的列表。但是不要把 get 和 pod 绑定在一起，pod 只是 k8s 中的一种服务，你不仅可以 get pod ，还可以 get svc ( 查看服务 )、 get rs ( 查看副本控制器 )、 get deploy ( 查看部署 )等等等等，虽然说 kubectl get pod 是最常用的一个，但是如果想查看某个资源而又不知道命令是什么， kbuectl get 资源名 就对了。

如果你想看更多的信息，就可以指定 -o wide 参数，如下：

加上这个参数之后就可以看到资源的所在 ip 和所在节点 node 了。

记得加上 -n

-n 可以说是 kubectl get 命令使用最频繁的参数了，在正式使用中，我们永远不会把资源发布在默认命名空间。所以，永远不要忘记在 get 命令后面加上 -n 。

kubectl get 命令可以列出 k8s 中的资源，而 kubectl get pod 是非常常用的查看 pod 的命令。而 -n 参数则可以指定 pod 所在的命名空间。

kubectl describe 命令可以用来查看某一资源的具体信息，他同样可以查看所有资源的详情， 不过最常用的还是查看 pod 的详情 。他也同样可以使用 -n 参数指定资源所在的命名空间。

举个例子，我们可以用下面命令来查看刚才 pod 列表中的某个 pod，注意不要忘记把 pod 名称修改成自己的：

然后你就可以看到很多的信息，咱们分开说，首先是基本属性，你可以在详细信息的开头找到它：

基本属性

其中几个比较常用的，例如 Node 、 labels 和 Controlled By 。通过 Node 你可以快速定位到 pod 所处的机器，从而检查该机器是否出现问题或宕机等。通过 labels 你可以检索到该 pod 的大致用途及定位。而通过 Controlled By ，你可以知道该 pod 是由那种 k8s 资源创建的，然后就可以使用 kubectl get 资源名 来继续查找问题。例如上文 DaemonSet/kube-flannel-ds-amd64 ，就可以通过 kubectl get DaemonSet -n kube-system 来获取上一节资源的信息。

内部镜像信息

在中间部分你可以找到像下面一样的 Containers 段落。该段落详细的描述了 pod 中每个 docker 容器的信息，常用的比如 Image 字段，当 pod 出现 ImagePullBackOff 错误的时候就可以查看该字段确认拉取的什么镜像。其他的字段名都很通俗，直接翻译即可。

事件

在 describe 查看详情的时候，最常用的信息获取处就是这个 Event 段落了，你可以在介绍内容的末尾找到它，如下：

是的，如果你看到上面这样，没有任何 Events 的话，就说明该 pod 一切正常。当 pod 的状态不是 Running 时，这里一定会有或多或少的问题，长得像下面一样，然后你就可以通过其中的信息分析 pod 出现问题的详细原因了：

kubectl describe 资源名 实例名 可以查看一个资源的详细信息，最常用的还是比如 kubectl describe pod pod名 -n 命名空间 来获取一个 pod 的基本信息。如果出现问题的话，可以在获取到的信息的末尾看到 Event 段落，其中记录着导致 pod 故障的原因。

如果你想查看一个 pod 的具体日志，就可以通过 kubectl logs pod名 来查看。注意，这个只能查看 pod 的日志。通过添加 -f 参数可以持续查看日志。例如，查看 kube-system 命名空间中某个 flannel pod 的日志，注意修改 pod 名称：

然后就可以看到如下输出：

如果你发现某个 pod 的服务有问题，但是状态还是显示 Running ，就可以使用 kubectl logs 来查看其详细日志。

在本篇文章里，我们了解了 k8s 的宗旨和一些基本概念，并知道了最为常用的 get 、 descibe 及 logs 命令，知道了这三条命令之后就几乎可以从 k8s 中获取所有常用信息了。接下来的 k8s 基本使用（下） 里，我们会更深一步，来了解 k8s 中如何创建、修改及删除资源。

计算机网络-k8s网络

K8S网络模型设计：扁平的可连通的网络

K8S的网络是一个极其复杂的网络，如果想要用两个简单的词来描述K8S网络，那么我觉得扁平和可连通是K8S网络最大的特点（不懂隔离性）。

何为连通呢？

二层网络的连通：如果能够直接通过MAC帧直接通信的网络便是二层连通的网络，LAN就是这种网络

比如无限WIFI网络，比如以太网

三层网络的连通：如果能够通过IP报直接通信的网络便是三层连通的网络，便是三层连通

三层网络的连通分为两个部分，第一个部分是三层网络中的每一个LAN都是二层连通的，其次需要存在能够连通的路由来保证；这里可以简单回顾下三层网络通信的流程

通过路由表确定目标ip是否在链路上

如果在链路上，通过arp协议获取对应主机的mac地址，发送mac帧到链路上；

如果不在同一个链路上，通过本地路由表发送mac帧给下一跳，然后下一跳解析mac帧，分析ip报，继续路由直到最终跳到目标网络再次通过mac帧发送到目标主机或者到达ttl消失。

假如其中任何一个步骤不满足或者出问题，三层网络就无法连通

何为扁平呢？

就是希望可以在pod内直接通过IP进行互相通信而不需要在pod内部使用vpn之类的东西来连接其他pod（基础架构化），具体的可以看下k8s对网络的设计与要求。

k8s在设计其网络时，就希望网络对运行在其中的pod是透明的，因此提出了以下的一些要求与原则

k8s组网要求

所有的Pods之间可以在不使用 NAT网络地址转换 的情况下相互通信

所有的Nodes之间可以在不使用NAT网络地址转换的情况下相互通信

每个Pod自己看到的自己的ip和其他Pod看到的一致

k8s网络模型设计原则

每个Pod都拥有一个独立的 IP地址，而且 假定所有 Pod 都在一个可以直接连通的、扁平的网络空间中 。

不管它们是否运行在同 一 个 Node (宿主机)中，都要求它们可以直接通过对方的 IP 进行访问。

设计这个原则的原因 是，用户不需要额外考虑如何建立 Pod 之间的连接，也不需要考虑将容器端口映射到主机端口等问题。

而要想深入了解K8S的网络，就不得不去了解Linux操作系统中的网络以及计算机网络协议栈和一些网络技术

其中关于计算机网络协议栈道部分上次分享已经分享过了，所以本次的主题更多是Linux操作系统的网络以及一些网络技术

Linux操作系统中的网络

首先，我们来看下基本的linux网络，如下图所示

一个APP生成socket数据，然后经过网络协议栈包装IP报文，然后封装成MAC帧，在经过网络协议栈的过程中，会存在netfilters对数据进行一定的处理，同时也会存在路由的过程，

如果在同一个物理链路内，将直接通过ARP协议获取目标IP地址的MAC地址最终发送出去；

如果不在同一个物理链路则通过路由表确定下一跳的MAC地址，封装成MAC帧发送到目标地址。

在这个过程中，会根据路由表选择对应的端口，如果是lo端口，则会将帧原封不动的返回计算机网络协议栈，然后回到监听对应端口的SOCKET里。

如果是以太网端口则走以太网端口，如果是蓝牙或者无线网端口同理。

iptables与netfilters

iptables是一个用户空间的应用程序，通过该程序可以修改一些配置文件，这些文件定义了防火墙的一些行为，netfilters是操作系统内核的一部分，netfilters里有5个回调钩子会触发iptables里的规则；iptables只是Linux防火墙的管理工具而已，位于/sbin/iptables。真正实现防火墙功能的是

netfilter，它是Linux内核中实现包过滤的内部结构。

这里不具体讲述其实现的原理，仅仅列出netfilters的一些功能：

1）filter表——三个链：INPUT、FORWARD、OUTPUT

作用：过滤数据包 内核模块：iptables_filter.

2）Nat表——三个链：PREROUTING、POSTROUTING、OUTPUT

作用：用于网络地址转换（IP、端口） 内核模块：iptable_nat

3）Mangle表——五个链：PREROUTING、POSTROUTING、INPUT、OUTPUT、FORWARD

作用：修改数据包的服务类型、TTL、并且可以配置路由实现QOS内核模块：iptable_mangle(别看这个表这么麻烦，咱们设置策略时几乎都不会用到它)

4）Raw表——两个链：OUTPUT、PREROUTING

作用：决定数据包是否被状态跟踪机制处理 内核模块：iptable_raw

虚拟网络设备 tap/tun

TUN 和 TAP 设备是 Linux 内核虚拟网络设备，纯软件实现。TUN（TUNnel）设备模拟网络层设备，处理三层报文如 IP

报文。TAP 设备模拟链路层设备，处理二层报文，比如以太网帧。TUN 用于路由，而 TAP 用于创建网桥。OS 向连接到 TUN/TAP

设备的用户空间程序发送报文；用户空间程序可像往物理口发送报文那样向 TUN/TAP 口发送报文，在这种情况下，TUN/TAP

设备发送（或注入）报文到 OS 协议栈，就像报文是从物理口收到一样。

虚拟网络设备 veth-pairs

虚拟以太网电缆。使用双向有名管道实现。常用于不同 namespace 之间的通信，即 namespace 数据穿越或容器数据穿越。

虚拟网络设备 bridge

bridge是linux自带的虚拟交换机（网桥），其可以连接多个以太网设备，拥有智能处理MAC帧的能力，流向交换机的MAC帧将智能的被传输到相应的二层链路

网络命名空间

在 Linux 中，网络名字空间可以被认为是隔离的拥有单独网络栈（网卡、路由转发表、iptables）的环境。网络名字空间经常用来隔离网络设备和服务，只有拥有同样网络名字空间的设备，才能看到彼此。

从逻辑上说，网络命名空间是网络栈的副本，有自己的网络设备、路由选择表、邻接表、Netfilter表、网络套接字、网络procfs条目、网络sysfs条目和其他网络资源。

从系统的角度来看，当通过clone()系统调用创建新进程时，传递标志CLONE_NEWNET将在新进程中创建一个全新的网络命名空间。

从用户的角度来看，我们只需使用工具ip（package is iproute2）来创建一个新的持久网络命名空间。

从系统实现来说，就是原本一个数据结构是static公共的，后来变成进程私有的，在PCB里存在一个命名空间的结构，命名空间里有着网络命名空间，网络命名空间拥有着所有跟网络相关的配置数据

默认空的网络命名空间可能只有一个未启动的lo回环网卡。

两个网络命名空间可以通过以太网揽直接连着两个网络命名空间的网卡，也可以通过以太网网桥连接。

通过以太网网桥或者以太网揽连接的两个网络命名空间只能说是在二层连通的，如果希望在三层连通，还需要给每个网络命名空间配置相应的路由表规则以及分配IP地址。

如何使用虚拟网络设备联通网络命名空间

SingleHost容器网络

none模式

本质上就是创建一个网络命名空间，里面没有路由表，也没有通过veths-pair连接任何链路，外部无法访问这个容器，容器也无法访问外部

host模式

本质上就是使用宿主机的默认网络命名空间

container模式

本质上就是将当前容器部署在另一个容器所在的网络命名空间，这样发给本地的报文最终通过回环网卡回到了本机，这是同一个网络命名空间可以互通的原因

bridge模式

桥接模式就是在这些网络命名空间通过veth-pairs连接到同一个虚拟交换机上（二层连通），同时在对应的命名空间配置对应的路由表规则，但是从图片中可以看到交换机另一端连的上网络协议栈。

也就是那些MAC帧都会被宿主机接收，但是宿主机接收并不一定会处理，比如并没有开启ip转发功能（工作于路由器模式还是主机模式），那么不是本地ip的报文都会被丢弃；或者说netfilters拒绝处理

这些奇怪的报文。

理论上，这些容器发送给其他容器的mac报文是会被虚拟交换机智能转发到对应的容器的，这是同一主机不同容器互相连通的原因

假如宿主机配备了相应的路由规则和防火墙规则，那么容器的报文说能够通过路由最终转发出去的，这也是容器访问互联网的原理

但是这种模式是没法运用在多主机的情况下，因为宿主机不知道其他宿主机里的虚拟网络的路由，当相关ip报到达宿主机时，这些ip报将会被宿主机交给默认路由（下一跳：路由器）

最终路由器会把相关的ip报丢失或者到达ttl最终丢失

MultiHost容器网络

路由方案

回顾docker的单机网络模型，我们发现多主机不能通行的原因就在于你只能给当前主机配置路由规则和防火墙规则，而其他主机并不知道这些ip在你的虚拟网络中，假如能够将这些路由信息同步到其他

宿主机，那么网络便会打通。比较直接的想法就是给每台宿主机配置路由规则。而路由规则要求下一跳必须在当前网络，所以假如宿主机是二层互联的，那么通过给这些宿主机同步这些路由规则便能够

实现一个扁平的连通的网络。

其中布置在每一台宿主机可以通过k8s的daemonSet实现，而这种数据的管理可以交给etcd来实现。

这类方案便是基于路由，基于这个方案的实现有基于静态路由的flannel的host-gateway，以及基于动态路由的calico（使用边际路由协议以及一堆深奥的名词的实现）。

下面来看看Flannel的host-gateway原理（每一台宿主机都相当于本机容器网络的路由器）：

通过路由方案构建的网络，宿主机也能访问这些虚拟网络里的Pod

询问基德大佬得知国际化sit环境的k8s网络接口实现就是Flannel的Host-gateway，而我们的办公网络和集群网络之间的路由是搭建好的，所以我们应该可以直接通过podId访问pod里的服务

下面是sit环境的两个服务

跟踪路由发现符合猜想

其中10.1.9.56和10.1.1.24就是宿主机的ip，这些宿主机在一个LAN里，这些宿主机相当于虚拟网络中的路由器；

猜测我们办公网和qunhe集群在一个VLAN里（二层可达）

隧道方案

隧道方案比较典型的就是UDP和XVLAN，两者都是使用Overlay网络（覆盖网络，所谓的大二层技术）；其实用隧道技术最多的是VPN应用

其中UDP是XVLAN的替代品（早期Linux没有支持XVLAN协议，通过tun/tap技术将流量引到用户空间然后解包生成包再发，因为发生在用户空间而且多次copy导致性能较差，所以一般不推荐，除非你的linux版本比较低没法用xvlan）

下面就简单介绍下XVLAN技术的大概原理，下图是XVLAN的报文格式，可以发现就是在高层协议的报文里塞了二层报文

其中XVLAN头里有一个关键的字段，VNID这是个24位的字段，每个虚拟的网络主机都有一个自身的VNID作为标识，理论上支持2的24次方个虚拟网络。

在docker的桥接网络里，是使用docker0网桥，在Flannel的xvlan方案里则是使用cni0作为网桥（和docker0没啥区别），主要的不同是cni网桥后面连接的是flannel.1这个网络设备，应该是一个虚拟网卡

这个网卡将原始报文包装成XVLAN报文（linux高版本支持xvlan报文）

这时需要的信息有 源nodeId，目标nodeId，源vnid，源macId，目标macId，源podId，目标podId

其中目标nodeId，目标macId这两个信息是不存在的；因此需要有个方式根据目标podId获取目标nodeId以及目标macId

因此需要记录如何根据目标podId获取目标macId以及目标nodeId即可

这些数据是可以托管在某个地方的，Flannel就是将这些信息记录在etcd上

在每个node上的flannel.1网络设备通过etcd来通过对方的podId获取nodeId和macId

这样最终报文就变成了一个源ip是源nodeIp，目标ip是目标nodeIp的IP报文了（两台宿主机三层可达）

原本经过虚拟网桥是直接连接网络协议栈，但在xvlan模式下，则改为连接一个flannel1，在flannel1中将对原始报文封装成overlay报文转发

udp模式类似，只是udp转发报文说通过tap连通到用户空间，用户空间对报文进行处理然后发送（因为多次内核态用户态切换且数据copy问题，性能较差，仅在不支持xvlan的低版本linux中使用）

当然xvlan是一个技术，上面只是简单介绍最简单的形式

参考：

开发内功修炼之网络篇： ;action=getalbumalbum_id=1532487451997454337scene=173from_msgid=2247485270from_itemidx=1count=3nolastread=1#wechat_redirect

K8S知识图谱:

VXLAN协议原理简介:

K8S 和 Docker 关系简单说明

本篇文章目的：让你更全面了解k8s概念，以及学到在工作中常用的操作。整体更偏向于原理和应用。在正式开始k8s之前，我们先看看k8s和Docker的关系，分别从虚拟化角度、部署方式角度叙述why use容器，话不多说，开干。

目前发现并没有将kubernetes和Docker技术产生背景和需求进行比较的文章，本文从最纯正的官方定义角度出发并展开，阐述二者产生背景及与传统技术对比。

简要介绍：

官方定义1： Docker是一个开源的应用容器引擎，开发者可以打包他们的应用及依赖到一个可移植的容器中，发布到流行的Linux机器上，也可实现虚拟化。

官方定义2： k8s是一个开源的容器集群管理系统，可以实现容器集群的自动化部署、自动扩缩容、维护等功能。

与传统技术对比：

接下来我们看两张经典的图：

一、从虚拟化角度：

上图是Docker容器（可用k8s管理的玩意儿）与传统虚拟化方式的不同之处：传统的虚拟技术在将物理硬件虚拟成多套硬件后，需要在每套硬件上都部署一个操作系统，接着在这些操作系统上运行相应的应用程序。而Docker容器内的应用程序进程直接运行在宿主机(真实物理机)的内核上，Docker引擎将一些各自独立的应用程序和它们各自的依赖打包，相互独立直接运行于未经虚拟化的宿主机硬件上，同时各个容器也没有自己的内核，显然比传统虚拟机更轻便。每个集群有多个节点，每个节点可运行多个容器，我们的kuberbete就是管理这些应用程序所在的小运行环境（container）而生。

二、从部署角度

注意，大家别把这幅图与上面Docker的那张图混淆了，图1是从虚拟化角度，说明了为应用提供必要的运行环境所需要做的虚拟化操作（即：传统：虚拟出的虚拟机装操作系统、Docker：容器引擎管理下的容器）。

而图2是在这些具体运行环境上进行真实应用部署时的情况，传统方式是将所有应用直接部署在同一个物理机器节点上，这样每个App的依赖都是完全相同的，无法做到App之间隔离，当然，为了隔离，我们也可以通过创建虚拟机的方式来将App部署到其中（就像图1上半部分那样），但这样太过繁重，故比虚拟机更轻便的Docker技术出现，现在我们通过部署Container容器的技术来部署应用，全部Container运行在容器引擎上即可。既然嫌弃虚拟机繁重，想用Docker，那好，你用吧，怎么用呢？手动一个一个创建？当然不，故kubernetes技术便出现了，以kubernetes为代表的容器集群管理系统，这时候就该上场表演了。

说白了，我们用kubernetes去管理Docker集群，即可以将Docker看成Kubernetes内部使用的低级别组件。另外，kubernetes不仅仅支持Docker，还支持Rocket，这是另一种容器技术。希望我这篇文章中简单的描述能让你对两者有所理解和认识。

到此这篇关于k8s和Docker关系简单说明的文章就介绍到这了。

以上就是本次分享的全部内容，现在想要学习的程序员欢迎关注六星社区，获取更多技能与教程。