[系统运维]云原生学习笔记（二）

Kubernetes基本原理

提纲

• docker编排与容器云
• k8s基本组件

容器编排

当时流行的三个容器编排工具： k8s、docker swarm、Mesos

• Kubernetes优势

  • 更灵活的容器编排策略
  • 更丰富的主机管理和调度策略
  • 更多的工具
  • 更好的微服务支持
  • …

• kubernetes起源

  • borg omega k8s

云原生圈里面已经不再讨论编排工具用什么了，讨论围绕k8s做些什么

Kubernetes基本组件

github上k8s项目：里面有一个development手册，README.md

基本组成：master和node结点

• Pod
• Container
• Label
• Replication
• Service
• Node
• Kubernetes

设计原则

• 声明式的状态驱动：通过写配置文件yaml进行操作（也可以通过可视化界面编辑自动生成yaml文件）
• 行动（react）：通过log等观察pod执行情况

kubernetes架构

API server、Controller Manager、Scheduler、kubelet、kube-proxy

• Master

  • 集群控制即诶单，负责集群管理和控制
  • 运行各类关键进程

• API server

• Scheduler

  • 给他一个任务，让他创建调度一个pod，调度这个pod在那个node运行
  • Scheduler会有一些预选策略：哪些node可以运行现在的pod；再进行一个优选，通过评分机制选择出一个唯一的node进行运行pod。
  • 以上的调度是基于静态数据的调度，我们希望他可以给予动态数据进行动态策略的制定。

如何看Kubernetes代码

• 如何找切入点：

比如找Scheduler，找到这个模块的main函数，顺着执行逻辑，选择有用的代码去看。

k8s代码有些问题：有些默认的借口调度

Etcd

Kubelet

每个node结点上都会有一个kubelet负责master下发到该节点的具体任务，

kube-proxy

深入理解Pod

Pod基本概念

• pod是一组紧密关联的容器集合，是k8s调度的基本单位，不可分割

• 一个pod里的多个容器可以共享存储和网络，可以看作一个逻辑主机。共享如namespace之类的隔离资源

  • 我们希望每个容器里面跑单进程，单进程意味着一些资源调度工作需要外部完成，pod就是做这个的。
    

• 资源挂载的粒度在pod级别而不是容器级别

Pod的创建

通过kube创建pod

Pod-通过ymal或json进行创建

ymal文件：

 apiVersion:v1
kind:Pod
metadata:
	name:redis-pod-1
spec:
	restartPolicy:Never
	

ymal文件是根据缩进去判断逻辑的， metadata文件

apiVersion: apps/v1 
kind: Statefu lSet 
metadata :
	name: mongo
spec :
	serviceName:" mongo'
	replicas: 2
	selector :
		matchLabe ls :
			role: mongo
	template : 
		metadata :
			labe ls :
role: mongo
spec :
terminat ionGracePer iodSeconds: 10
contai ners :
name: mongo 
image: mongo
command: ["binbash", "-ce", "tail -f dewnu l l"]
ports :
- containerPort: 27817
VOlumeMounts :
name: mongo pers is tent -s torage
mountPath: usr/share/db
name: mongo-s i deca r
image: cvallance/mongo k8s -s idecar
env:
name: MONGO s IDECAR POD LABELS
value: 'ro le-mongo ,envi ronment test 
name: KUBERNETES MONGO SERUICE NAME
value: " mongo 
VOlumeC la imTemp lates :
- metadata : 
name: mongo pers is tent -s torage
annotat ions :
"statefu lset -mongo yaml" 4ZL, 1026C

多容器Pod

Pod生命周期

• pending：类似于挂起状态
• Running：
• successed：

Pod属性列表：

• recourses：
  • limits：(存在一些资源浪费问题，但是限制并不能下调，一旦出现访问量激增，低限度的node会直接杀死进程)
    • cpu : string
    • memory : string
  • requests :
    • cpu : string
    • memory : string

ImagePullPolicy：

三种拉取策略

RestartPolicy：

重启策略：Pod支持三种重启策略，在配置文章中通过restartPolicy字段进设置重启策略

• Always：只要推出就重启
• OnFailure：失败推出时重启
• Never：退出就不再重启

注意：这里重启是在Node上重启，而不是支持重新调度Node

资源限制示例：

健康检查：

为了确保容器在部署后正常运心，k8s提供两种探针：

• LivenessProbe：探测应用是否处于健康状态，如果不健康则删除重启
• ReadnessProbe：探测是否正常，如果不正常，则不会接受来自k8s Service的流量

Probe补充说明：

init Container

• 在应用容器启动之前的初始化容器，一个偏管理层的容器，Api Server 不会去管它
• 它能够对资源初始化，进行一些管理

静态Pod

• 直接有K8S进行管理，不由api server管理，

• 可以通过配置文件直接拉取的文件

• 本身没有业务信息

• 课后作业

  • 通过命令行：使用nginx

Label

• label的使用方式，通过yaml文件进行指定
• 对node的label可以通过命令进行管理

Config Map

• 保存配置数据的键值对，可以用来保存单个属性，也可以保存配置文件
• 就是一套完整的配置信息，单独管理，直接解决了环境配置问题。

有状态部署：

部署数据库集群的时候，并不是每一个节点都是对等的，至少是有先后顺序的。

• 举个例子：

mongo跑两个实例：两个数据库实例

实例自身带有持久存储，在容器之外挂载的存储器，避免容器挂掉之后数据没了。

mongo两个实例分别是0、1 顺序是先0后1

一个是主节点，一个是从节点。

在运行日志里可以看到运行pod时出现的问题，比如持久化存储挂载失败。