kubernetes基础知识

kubernetes基础知识

​
个人博客文章链接：kubernetes基础知识 - masaka的树屋 欢迎关注

文章目录

核心概念

containerpodslabelsnamespace replication

replicationControllerreplicaSetsliveness probedaemonSetjob Service

Endpointservice type： volume

emptyDirhostPathPersistentVolumes & PersistentVolumeClaims deploymentoverall picture

核心概念 container

docker等容器，提供docker镜像运行的环境。docker利用namespace、cgroup等linux提供的能力，来使运行在同一机器上的各个container互不影响。各container都认为自己拥有独立的文件、进程等系统，同时，机器的cpu、内存等资源也被划分给不同的container。

pods

一个container正常来说只应该包含一个进程，因为这样能更好的监控container的状态，可以理解为k8s监控的最小粒度就是container；而一个pod会包含一个或多个紧密相关的container，一个pod下的container会部署在一个物理节点，也就意味着一个pod下不同container的交互是可以通过localhost进行的。

一般来说，一个pod中只会有一个container，存在多个container的情况一般是一个为主container，其他container负责辅助做一些事情，比如说log agent负责上报主container生产的日志。

labels

所有k8s的资源，比如pod、node，都可以被打上标，label为kv形式，且一个资源上能打上多种标签。打完标签后，可以通过label selectors来筛选出打上特定label的资源。

比方说可以将不同版本的pod通过label打上不同的标签：version=v1/v2/…，然后利用label selectors就可以将version=v1的pod全部取出。label还可以标示node资源，举个例子：如果某些node底层是gpu，可以将这些nodes搭上label：gpu=true，然后在部署需要在gpu上运行的服务时，便可通过label selectors来指定特定的pods需要部署在gpu=true的nodes上。

namespace

一个pod可能会有多个label，但只会有一个namespace。namespace的概念可以类比于租户，通过namespace可以指定到不同的租户的命名空间。但需要注意的是，namespace仅仅是个逻辑上的分类，在你指定了某个namespace后，你只能看到对应namespace的pod，但并不作其他方面的区分，比方说不同namespace的pod仍可以互相调用

replication replicationController

监控正在运行的pods，并确保pods的数量是和配置好的数量是一样的。replicationController通过label selector来指明需要关注的pods，如果某个pod在运行期间修改了label，导致特定的replicationController通过label selector找不到该pod了，那么replicationController会根据配置重新建立pod

replicaSets

用来替代replicationController，本质上比replicationController支持更丰富的label selector的匹配规则

liveness probe

用来检测pod是否还能正常对外提供服务，k8s会定期执行probe来看pod是否正常工作，如果probe运行失败，则会重启container。probe主要有以下三种方式：

1. http get
2. tcp socket
3. 任意脚本，看返回值是否为0

daemonSet

有些pod需要在所有node、或者在所有打了某些标签的node上运行，比如每个node都需要有pod来上报日志、或者k8s集群上的每个node都需要部署kube-proxy进程

job

job：一次性跑完的任务，不是持续性的服务

cronjob：周期性的服务

Service

---

service可以理解为就是psm，提供了一类服务的入口。本质上，replicaSets等负责管理pod，而service负责pod与内外部服务的交互。在service定义时需要定义port和targetport，port代表service正在监听的端口，收到请求后，service会将请求转发到对应pod的targetport上。

Endpoint

在service和pod中间，有名为Endpoint的资源，记录了符合条件的pod的ip，service在进行路由时，先通过endpoint挑选一个pod的ip和port，再路由过去。加这么一层抽象的原因是，可以将service与pod进行解耦，能在endpoint中申明想要连接的pod的ip和port，然后将service与endpoint关联起来

service type：

NodePort：相比于普通service的port和targetport，新增了nodeport的配置，指的是每个node节点的该port上的请求，都会被路由到该service

LoadBalancer：外部请求会先于lb进行通信，再由lb进行路由

Ingress：作用在http层，能够根据url的不同发送到对应的service上

liveness probe与readiness probe的区别：liveness负责去kill掉不健康的pod，用健康的pod来进行替换，而readiness：只有readiness probe认为健康的pod，才能够对外提供服务

---

volume

pod在销毁之后资源就被回收了，但是对于运行过程中产生的一些数据，可能会有存储的需求，以便下次pod/container重启时，能够读取到之前的数据

emptyDir

这个类型的volume没有和node的地址进行关联，在pod重启后，该volume也会被销毁，这个类型主要可以用作同一pod下多个container的相互通信，或者单个container有些临时的文件也可以存储。

举个例子，一个pod下有业务的container和上报log的container，业务container会将日志写到某个地址，如果上报log的container需要访问到这个日志，就可以在pod中定义一个类型为emptyDir的volume，然后两个pod都去挂载这个volume，即可实现container通过文件通信。

类型为emptyDir的volume，猜测应该就是在起的pod中创建一个文件夹，以供该pod中需要挂载该volume的containers进行挂载

hostPath

指向node文件系统中特定的文件，一般正常的pod不会使用这种类型的volume，也不能当作持久化存储的方式，因为只是保存在了某个node上，下次调度pod时可能调度到其他的node上面

PersistentVolumes & PersistentVolumeClaims

被持久化的数据，需要被运行在任意node上的特定pod给访问到，这也就要求这些数据需要被保存在网络存储中（network-attached storage, NAS）。例如google提供了GCE（google comput engine） persistent disk、aws提供了awsElasticBlockStore，都可以用来挂载进行数据存储，挂载示意图如下所示

k8s的设计哲学是上层应用的开发者应该尽可能少知道底层的实现，比如在创建服务的时候，并不关心pod被调度到了哪个node上面执行；相应的，对于volume来说，应用开发者理应也不需要关注数据到底存储在哪个具体存储中的，这就有了PersistentVolumes和PersistentVolumesClaims，PersistentVolumes一般是k8s运营负责配置，用来屏蔽底层的存储介质的细节，而应用开发者通过提供的PersistentVolumes，使用PersistentVolumesClaims的方式来指定挂载哪个PersistentVolumes，从而对应用开发者屏蔽了底层存储的细节。

deployment

服务进行发布升级时，往往需要滚动升级的方式，以能够在发布过程中也能继续对外提供服务。为了实现滚动升级，可以使用下面这种方式：

新开一个replicaSet，定义为新的镜像包，并将pod的数量设置为1当新的replicaSet的pod正常起来后，将原来replicaSet的pod数量-1重复这个 *** 作，知道旧的pods为0，新的pod为原来的数量

在没有deployment之前，做滚动升级就是上面的做法。但是k8s另一个哲学就是只需要自己想要达到什么状态，而达到这一状态所需要进行什么步骤则并不需要用户来关心。拿数据库进行对比，sql语句只是声明了需要什么样的数据，而不是描述要怎么获取数据，使用哪个索引、先拿数据还是先过滤等完全是由数据库来进行 *** 作，不需要用户来指明。对应的，在滚动升级时，应该只需要告诉k8s需要将某个版本滚动升级到某个版本，而不需要具体指明所需要的步骤。

deployment这种资源类型直接 *** 控的是replicateSet，在升级时会创建一个新的replicateSet，来进行滚动升级。另外，在滚动删除完，deployment还是会维护之前版本replicateSet的配置，以便后面提供rollback的能力。

overall picture

整体架构如下图所示，deployment通过replicaSet来控制版本的发布、回滚，re plicaSet根据配置来管理pod的生命周期，删除不健康的pod并用新的pod来代替。service负责内外部流量的路由，收到请求后根据endpoint给出的pod的ip和port将流量路由到对应的pod节点，而对于readiness probe检测不通过的pod，会从endpoint中剔除（但不是删除），以免不健康的pod还在对外提供服务。

​