K8s基础

qiutian2020

1、k8s在企业中应用的场景—用于管理容器

1）自动化运维平台
2）充分利用服务器资源
3）服务无缝迁移（开发环境->测试环境->生产环境，JDK,MYSQL,ES,MQ,WEB服务）

3、k8s架构原理

1）k8s是google企业使用go语言开发。borg系统
2）k8s架构------一个master对应一群node节点。
* master节点

• * api server----k8s网关，所有指令请求都必须经过api server
• * scheduler----调度器，使用调度算法，把请求资源调度某一个node节点
• * controller----控制器，维护k8s资源对象
• * etcd----存储资源对象
  

* node节点

• * docker----运营容器的基础环境。容器引擎
• * kubelet----在每一个node节点都存在一份，在node节点上的资源指令由kubelet来实行。负责本地pod的维护工作
• * kube-proxy----代理服务，在多个pod之间做负载均衡
• * fluentd----日志收集服务
• * pod----是k8s管理的基本单元（最小单元），pod内部是容器。k8s不直接管理容器，而是管理pod，pod内部可以有1个容器，也可以有多个容器。
  

4、pod的作用

1）pod是是一个虚拟化分组，有自己的IP地址，主机名，相当于一台独立沙箱环境。相当于主机，可以封装一个或者多个容器。
2）通常情况下，在服务部署的时候，使用pod来管理一组相关的服务，一个pod中要么部署一个服务，要么部署一组有关系的服务（nginx、mysql）
3）实现服务集群：只要复制多方pod的副本即可，这也是k8s管理的先进之处，k8s如果继续扩容，缩容，只需要控制pod的数量即可。
4）pod底层网络，数据存储是如何进行的？
pod----是k8s管理的基本单元（最小单元），pod内部是容器。k8s不直接管理容器，而是管理pod，pod内部可以有1个容器，也可以有多个容器。
pod内部容器创建之前，必须先创建pause容器。服务容器之间访问使用localhost，相当于访问本地服务一样性能很高。

5、ReplicateSet副本控制器

* ReplicationController 副本控制器

* ReplicaSet 副本控制器

副本控制器基本理解：控制pod集群副本（服务集群）的数量，永远与预期设定的数量保持一致即可。

例如

前提：replicas=3（3个副本），永远保证副本数量=3，当副本设置为3的时候，副本控制器将会永远保证副本数量为3，当有pod服务宕机时候，副本控制器将会立马创建一个新的pod，永远保证副本数量为3

ReplicaSet & ReplicationController有什么区别？？

ReplicaSet 可以使用标签选择器进行单选、复合选择【推荐使用】

ReplicationController 单选

副本控制器：标签选择器 -- 选择维护一组相关的服务（它自己的服务），通过这组服务来维护大家的pod

selector：

app = web

release = stable

6、Deployment 部署对象

* 服务部署结构模型

* 滚动更新

ReplicaSet副本控制器控制pod副本的数量。但是：项目的需求在不变的迭代，不断的更新，项目版本将会不停的发版版本的变化如何做到服务的更新？

滚动更新

部署模型：ReplicaSet不支撑滚动更新，Deployment对象支撑滚动更新。通常和ReplicaSet一起使用

Deployment管理ReplicaSet，ReplicaSet管理副本。

RepicaSet：1、重新建立新的RS；2、重新建立新的POD

7、Statefulment部署对象

* 部署模型
* 有状态服务
MySql使用容器化部署，存在什么样的问题？？
* 容器是有生命周期的，一旦宕机，数据丢失
* pod部署，pod有生命周期，数据丢失

总结：k8s来说，不能使用deployment部署模型部署有状态服务。通常情况下，deployment被用来部署无状态服务的。那么对于有状态服务的部署，使用statefulSet进行有状态服务的部署。
状态服务的说明：

• 1、有状态服务
  
  • * 有 实时 的数据需要存储
  • * 有状态服务集群中，把某一个服务抽离出去，一段时间后再加入集群网络，如果集群网络无法使用。
    
• 2、无状态服务
  
  • * 没有 实时 的数据需要存储
  • * 无状态服务集群中，把某一个服务抽离出去，一段时间后再加入集群网络，对集群服务没有任何影响。
    
• Stateful保证Pod重新建立后hostname不发生变化，通过hostname关联数据。
  

8、Pods组网通信概览

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

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

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

需要解决以下四个网络问题：

Docker容器和Docker容器之间的网络

Pod与Pod之间的网络

Pod与Service之间的网络

Internet与Service之间的网络

9、容器和容器之间的网络

每个POD里存在多个docker容器，同一个POD里的多个docker容器共享一个命名空间。

Pod中的每个Docker容器拥有与Pod相同的IP和port地址空间，并且由于他们在同一个网络命名空间，他们之间可以通过localhost相互访问。

同一个Pod内的多个docker容器相互通信？其实是使用Docker的一种网络模型：–net=container

container模式指定新创建的Docker容器和已经存在的一个容器共享一个网络命名空间，而不是和宿主机共享。新创建的Docker容器不会创建自己的网卡，配置自己的 IP，而是和一个指定的容器共享 IP、端口范围等

每个Pod容器有有一个pause容器其有独立的网络命名空间，在Pod内启动Docker容器时候使用 –net=container就可以让当前Docker容器加入到Pod容器拥有的网络命名空间（pause容器）

补充：docker的其他几类网络模型

--net=bridge: 默认的模式，安装完docker以后，系统会自动添加一个docker使用的网桥，docker0，当大家创建一个新的容器时，容器通过dhcp获取与docker0同网段的地址来和宿主机互通网络；

--net=host: 直接使用宿主机的命名空间，使用宿主机的IP和端口；

--net=none:  给容器创建独立的命名空间，不作任何网络配置，容器中只有l0，如果用户需要配置docker容器的IP地址，则必须在none模式下；

（1）命名空间的概念

命名空间不能相互嵌套，每个 Kubernetes 资源只能在一个命名空间中。

命名空间是在多个用户之间划分集群资源的一种方法（通过资源配额）。

查看命名空间：kubectl get ns

a)三个初始命名空间

default 没有指明使用其它命名空间的对象所使用的默认命名空间

kube-system Kubernetes 系统创建对象所使用的命名空间

kube-public 这个命名空间是自动创建的，所有用户（包括未经过身份验证的用户）都可以读取它。这个命名空间主要用于集群使用，以防某些资源在整个集群中应该是可见和可读的。这个命名空间的公共方面只是一种约定，而不是要求。

b)命名空间相关常用命令

查看哪些 Kubernetes 资源在命名空间中，哪些不在命名空间中：

kubectl api-resources --namespaced=true   ##查看哪些资源在命名空间

kubectl api-resources --namespaced=false  ##查看哪些资源不在命名空间

查看资源的时候加上指定的命名空间

kubectl get pods -n   kube-system

创建命名空间

kubectl create ns test

切换命名空间

kubectl config set-context --current --namespacekube-system ##切换到kube-system的命名空间

10、POD与POD之间的网络

k8s中，每个Pod拥有一个ip地址，不同的Pod之间可以直接使用该IP与彼此进行通讯

在同一个Node上，从Pod的视角看，它存在于自己的网络命名空间中，并且需要与该Node上的其他网络命名空间上的Pod进行通信。

原理：

linux虚拟以太网设备或者说是由两个虚拟接口组成的veth对使不同的网络命名空间链接起来，这些虚拟接口分布在多个网络命名空间上（这里是指多个Pod上）。

为了让多个Pod的网络命名空间链接起来，大家可以让veth对的一端链接到root网络命名空间（宿主机的），另一端链接到Pod的网络命名空间。

每对Veth就像一根接插电缆，连接两侧并允许流量在它们之间流动；这种veth对可以推广到同一个Node上任意多的Pod上，如上图这里展示使用veth对链接每个Pod到虚拟机的root网络命名空间。

linux以太网桥（Linux Ethernet bridge）是一个虚拟的2层网络设备，目的是把多个以太网段链接起来，网桥维护了一个转发表，通过检查转发表通过它传输的数据包的目的地并决定是否将数据包传递到连接到网桥的其他网段，网桥代码通过查看网络中每个以太网设备特有的MAC地址来决定是传输数据还是丢弃数据。

网桥实现了ARP协议用来根据给定的ip地址找到对应机器的数据链路层的mac地址，一开始转发表为空，当一个数据帧被网桥接受后，网桥会广播该帧到所有的链接设备（除了发送方设备），并且把响应这个广播的设备记录到转发表；随后发往相同ip地址的流量会直接从转发表查找正确的mac地址，然后转发包到对应的设备。

11、不同node中的pod之间的通信

k8s网络模型需要每个pod必须通过ip地址可以进行访问，每个pod的ip地址总是对网络中的其他pod可见，并且每个pod看待自己的ip与别的pod看待的是一样的（虽然他没规定如何实现），下面大家看不同Node间Pod如何交互

k8s中每个集群中的每个Node都会被分配了一个CIDR块（无类别域间路由选择，把网络前缀都相同的连续地址组成的地址组称为CIDR地址块）用来给该Node上的Pod分配IP地址。(保证pod的ip不会冲突) 另外还需要把pod的ip与所在的nodeip关联起来

如上图Node1(vm1)上的Pod1与Node2(vm2)上Pod4之间进行交互。

首先pod1通过自己的以太网设备eth0把数据包发送到关联到root命名空间的veth0上，然后数据包被Node1上的网桥设备cbr0接受到，网桥查找转发表发现找不到pod4的Mac地址，则会把包转发到默认路由（root命名空间的eth0设备），然后数据包经过eth0就离开了Node1，被发送到网络。

数据包到达Node2后，首先会被root命名空间的eth0设备，然后通过网桥cbr0把数据路由到虚拟设备veth1,最终数据表会被流转到与veth1配对的另外一端（pod4的eth0）

12、Pod与service之间的网络

pod的ip地址是不持久的，当集群中pod的规模缩减或者pod故障或者node故障重启后，新的pod的ip就可能与之前的不一样的。所以k8s中衍生出来Service来解决这个问题。

k8s中 Service管理了一系列的Pods，每个Service有一个虚拟的ip,要访问service管理的Pod上的服务只需要访问你这个虚拟ip就可以了，这个虚拟ip是固定的，当service下的pod规模改变、故障重启、node重启时候，对使用service的用户来说是无感知的，因为他们使用的service的ip没有变。

当数据包到达Service虚拟ip后，数据包会被通过k8s给该servcie自动创建的负载均衡器路由到背后的pod容器。