Kubernetes基本概念

Pod

k8s的最终目标就是以应用为中心，来组织和围绕如何更好的以容器化的方式运行应用。而在k8s上运行容器的做小的原子单元是由k8s抽象出的pod。

Pod的含义是豌豆荚的意思，它意味着一个豆荚内存在着好几个豌豆。而在k8s中pod则代表着一组关联度非常密切的容器。如主容器为应用容器，而辅助容器为日志收集的agent之类的容器。这种辅助容器可以称之为容器的SideCar。

在k8s中pod内的容器组合有以下几种：

SideCar
Adapter
Ambassador

在k8s的容器应用中，容器之间是存在关系的。这种关系是需要由容器编排系统进行管理，这种关系分为亲密和非紧密。

亲密：k8s会将其放入几个pod内实现同进退。这些容器中的Network、IPC、UTS是共享的。并且共享一组存储卷。所以主容器会挂载一组存储卷，将所有数据写入存储卷中，SideCar也挂载同一组存储卷，所以主容器所写的内容都会被sidecar所收集。容器间通信使用lo接口即可。
非紧密：容器各自是各自的Pod。通信需要借助网络插件。
pod-to-pod：网络插件实现
pod-to-service：ipvs、iptables规则实现
kube-proxy：kube-proxy会监视着apiserver上service的变动。把集群上的每一个service的定义转换为本地的ipvs或iptables规则。当service发生增删改查，kube-proxy会将其变化为本机iptables规则上的增删改查。

容器间的通信

容器间的通信有以下两种：

同一主机：两个pod地址在同一网段内，直接通过宿主机的bridge进行通信。
跨主机：使用叠加或者承载网络来进行通信，需要依靠网络插件来实现。

flannel的网络通信

在flannel网络插件中，默认创建的pod会自动挂载到宿主机的CNI0桥上。

# 宿主机上的cni0网桥
root@k8s-master01:~# ifconfig cni0
cni0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.244.0.1  netmask 255.255.255.0  broadcast 10.244.0.255
        inet6 fe80::d8ca:b5ff:fea1:a90a  prefixlen 64  scopeid 0x20<link>
        ether da:ca:b5:a1:a9:0a  txqueuelen 1000  (Ethernet)
        RX packets 143158  bytes 11677858 (11.6 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 154789  bytes 14020277 (14.0 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

各宿主机上不但有cni0这个bridge设备，还存在一个flannel.1这个隧道网络，跨主机通信时报文会发送给bridge网络，bridge网络会通过flannel.1这个隧道网络发送给目标主机，目标主机发现为本地的地址转发给pod，从而实现pod间跨主机通信。

root@k8s-master01:~# ifconfig flannel.1
flannel.1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.244.0.0  netmask 255.255.255.255  broadcast 10.244.0.0
        inet6 fe80::f0ff:71ff:fed7:612c  prefixlen 64  scopeid 0x20<link>
        ether f2:ff:71:d7:61:2c  txqueuelen 0  (Ethernet)
        RX packets 2944  bytes 4796228 (4.7 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1831  bytes 139032 (139.0 KB)
        TX errors 0  dropped 34 overruns 0  carrier 0  collisions 0

需要注意的是隧道报文需要封装一个额外的首部，这个首部会映像MTU，因此要设定内部容器间通信的MTU要小于1500，以便于额外封装首部时不会产生巨型帧。

控制器和pod间关系

控制器使用标签选择器关联的pod上来，我们要定义一个控制器，需要指定运行几个副本(replicas)、pod的模板(template)。

当控制器中所关联的某个pod宕机后，控制器会自动再创建出一个pod以确保副本数量与指定的数量相同。

pod的宕机会被kubelet发现，kubelet会运行control loop来监控节点上的所有pod状态是否健康，当发现有pod宕机，kubelet会报告给apiserver。而控制器则会监视着apiserver，当发现有被自己所关联的pod宕机时，控制器会重新创建一个pod，并把原来宕机的pod删除。

API Server

k8s的API Server提供的是一个RESTful风格的接口，他把一切的资源都抽象为资源resource。

资源类型：Pod，Deployment，Service等等。

可以将每一个资源类型看作是一张表，每个表都存在一些对象。如果期望向这些表中插入数据，则需要向API Sever发送指令。调用API Server的API。

API server客户端

kubectl就是KUBE API Server的专用api调用客户端。

kubectl向资源列表中插入数据时有3种方式：

命令式命令：在命令行种使用命令及选项实现。
命令式配置文件：使用命令并通过选项传递一个配置文件来实现。
声明式配置文件：使用命令并通过选项传递配置文件来实现。

# 声明式配置文件资源规范,yaml格式数据项。
apiVersion: ...  # 资源对象所属的API群组及版本
kind: ...        # 
metadata:       # 资源对象的元数据
 ...
spec:        # 所需状态，或称为期望状态
  ...

API群组及版本

k8s上存在的API群组和版本信息非常多，为了方便管理k8s把许多的资源类型按照相关性分成了组，每个组可以单独演进。

查询系统上所有的API群组版本

当前k8s上存在的所有API群组和版本可以通过命令查询获得。

root@k8s-master01:~# kubectl api-versions
admissionregistration.k8s.io/v1
admissionregistration.k8s.io/v1beta1
apiextensions.k8s.io/v1
apiextensions.k8s.io/v1beta1
apiregistration.k8s.io/v1
apiregistration.k8s.io/v1beta1
apps/v1
authentication.k8s.io/v1
authentication.k8s.io/v1beta1
authorization.k8s.io/v1
authorization.k8s.io/v1beta1
autoscaling/v1
autoscaling/v2beta1
autoscaling/v2beta2
batch/v1
batch/v1beta1
certificates.k8s.io/v1
certificates.k8s.io/v1beta1
coordination.k8s.io/v1
coordination.k8s.io/v1beta1
discovery.k8s.io/v1
discovery.k8s.io/v1beta1
events.k8s.io/v1
events.k8s.io/v1beta1
extensions/v1beta1
flowcontrol.apiserver.k8s.io/v1beta1
longhorn.io/v1beta1
networking.k8s.io/v1
networking.k8s.io/v1beta1
node.k8s.io/v1
node.k8s.io/v1beta1
policy/v1
policy/v1beta1
rbac.authorization.k8s.io/v1
rbac.authorization.k8s.io/v1beta1
scheduling.k8s.io/v1
scheduling.k8s.io/v1beta1
storage.k8s.io/v1
storage.k8s.io/v1beta1
v1

api群组的版本分为3种：

v1：稳定版
v1beta1：beta版本，公测。
alpha：内测版本，在下个版本可能被丢弃。

查看某个资源所在的群组

以下以pod为例来查看其资源的群组

# 使用kubectl explain命令来查看相应资源的群组和配置清单的使用方式
root@k8s-master01:~# kubectl explain pod
KIND:     Pod
VERSION:  v1   # pod属于核心群组的v1版本

DESCRIPTION:
     Pod is a collection of containers that can run on a host. This resource is
     created by clients and scheduled onto hosts.

FIELDS:
   apiVersion   <string>
     APIVersion defines the versioned schema of this representation of an
     object. Servers should convert recognized schemas to the latest internal
     value, and may reject unrecognized values. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources

   kind <string>
     Kind is a string value representing the REST resource this object
     represents. Servers may infer this from the endpoint the client submits
     requests to. Cannot be updated. In CamelCase. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

   metadata     <Object>
     Standard object's metadata. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

   spec <Object>
     Specification of the desired behavior of the pod. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

   status       <Object>
     Most recently observed status of the pod. This data may not be up to date.
     Populated by the system. Read-only. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status