Kubernetes学习资料

K8S概述及相关特征

概述

K8s是谷歌在2014年发布的容器化集群管理系统
使用k8s进行容器化应用部署
使用k8s利于应用扩展
k8s目标实施让部署容器化应用更加简洁和高效

特性

自动装箱

基于容器对应用运行环境的资源配置要求自动部署应用容器

自我修复(自愈能力)

当容器失败时，会对容器进行重启

当所部署的Node节点有问题时，会对容器进行重新部署和重新调度

当容器未通过监控检查时，会关闭此容器直到容器正常运行时，才会对外提供服务

如果某个服务器上的应用不响应了，Kubernetes会自动在其它的地方创建一个

水平扩展

通过简单的命令、用户UI 界面或基于CPU 等资源使用情况，对应用容器进行规模扩大或规模剪裁

当我们有大量的请求来临时，我们可以增加副本数量，从而达到水平扩展的效果

当黄色应用过度忙碌，会来扩展一个应用

服务发现

用户不需使用额外的服务发现机制，就能够基于Kubernetes 自身能力实现服务发现和负载均衡

对外提供统一的入口，让它来做节点的调度和负载均衡，相当于微服务里面的网关？

滚动更新

可以根据应用的变化，对应用容器运行的应用，进行一次性或批量式更新

添加应用的时候，不是加进去就马上可以进行使用，而是需要判断这个添加进去的应用是否能够正常使用

版本回退

可以根据应用部署情况，对应用容器运行的应用，进行历史版本即时回退

类似于Git中的回滚

密钥和配置管理

在不需要重新构建镜像的情况下，可以部署和更新密钥和应用配置，类似热部署。

存储编排

自动实现存储系统挂载及应用，特别对有状态应用实现数据持久化非常重要

存储系统可以来自于本地目录、网络存储(NFS、Gluster、Ceph 等)、公共云存储服务

批处理

提供一次性任务，定时任务；满足批量数据处理和分析的场景

K8S核心概念

Pod：K8s管理的最小单位级，是所有业务类型的基础
Controller：控制器，有状态，无状态，一次任务，定时任务，守护进程
Service、Ingress：定义一组Pod的访问规则，对外暴露端口
RBAC：安全机制，权限模型
Helm：下载机制
持久化存储

K8S集群架构组件

完整架构图

架构细节

K8S架构主要包含两部分：Master（主控节点）和 node（工作节点）

master节点架构图

Node节点架构图

k8s 集群控制节点，对集群进行调度管理，接受集群外用户去集群操作请求；

master：主控节点
- API Server：集群统一入口，以restful风格进行操作，同时交给etcd存储
  - 提供认证、授权、访问控制、API注册和发现等机制
- scheduler：节点的调度，选择node节点应用部署
- controller-manager：处理集群中常规后台任务，一个资源对应一个控制器
- etcd：存储系统，用于保存集群中的相关数据
Work node：工作节点
- Kubelet：master派到node节点代表，管理本机容器
  - 一个集群中每个节点上运行的代理，它保证容器都运行在Pod中
  - 负责维护容器的生命周期，同时也负责Volume(CSI) 和网络(CNI)的管理
- kube-proxy：提供网络代理，负载均衡等操作
容器运行环境【Container Runtime】
- 容器运行环境是负责运行容器的软件
- Kubernetes支持多个容器运行环境：Docker、containerd、cri-o、rktlet以及任何实现Kubernetes CRI (容器运行环境接口) 的软件。
fluentd：是一个守护进程，它有助于提升集群层面日志

Kubenetes集群管理工具Kubectl

概述

kubectl是Kubernetes集群的命令行工具，通过kubectl能够对集群本身进行管理，并能够在集群上进行容器化应用的安装和部署

命令格式

命令格式如下

kubectl [command] [type] [name] [flags]

参数

command：指定要对资源执行的操作，例如create、get、describe、delete
type：指定资源类型，资源类型是大小写敏感的，开发者能够以单数、复数和缩略的形式

例如：

kubectl get pod pod1
kubectl get pods pod1
kubectl get po pod1

name：指定资源的名称，名称也是大小写敏感的，如果省略名称，则会显示所有的资源，例如

kubectl get pods

flags：指定可选的参数，例如，可用 -s 或者 -server参数指定Kubernetes API server的地址和端口

常见命令

kubectl help 获取更多信息

通过 help命令，能够获取帮助信息

# 获取kubectl的命令
kubectl --help# 获取某个命令的介绍和使用
kubectl get --help

基础命令

常见的基础命令

命令	介绍
create	通过文件名或标准输入创建资源
expose	将一个资源公开为一个新的Service
run	在集群中运行一个特定的镜像
set	在对象上设置特定的功能
get	显示一个或多个资源
explain	文档参考资料
edit	使用默认的编辑器编辑一个资源
delete	通过文件名，标准输入，资源名称或标签来删除资源

部署命令

命令	介绍
rollout	管理资源的发布
rolling-update	对给定的复制控制器滚动更新
scale	扩容或缩容Pod数量，Deployment、ReplicaSet、RC或Job
autoscale	创建一个自动选择扩容或缩容并设置Pod数量

集群管理命令

命令	介绍
certificate	修改证书资源
cluster-info	显示集群信息
top	显示资源(CPU/M)
cordon	标记节点不可调度
uncordon	标记节点可被调度
drain	驱逐节点上的应用，准备下线维护
taint	修改节点taint标记

故障和调试命令

命令	介绍
describe	显示特定资源或资源组的详细信息
logs	在一个Pod中打印一个容器日志，如果Pod只有一个容器，容器名称是可选的
attach	附加到一个运行的容器
exec	执行命令到容器
port-forward	转发一个或多个
proxy	运行一个proxy到Kubernetes API Server
cp	拷贝文件或目录到容器中
auth	检查授权

其它命令

命令	介绍
apply	通过文件名或标准输入对资源应用配置
patch	使用补丁修改、更新资源的字段
replace	通过文件名或标准输入替换一个资源
convert	不同的API版本之间转换配置文件
label	更新资源上的标签
annotate	更新资源上的注释
completion	用于实现kubectl工具自动补全
api-versions	打印受支持的API版本
config	修改kubeconfig文件（用于访问API，比如配置认证信息）
help	所有命令帮助
plugin	运行一个命令行插件
version	打印客户端和服务版本信息

目前使用的命令

# 创建一个nginx镜像
kubectl create deployment nginx --image=nginx# 对外暴露端口
kubectl expose deployment nginx --port=80 --type=NodePort# 查看资源
kubectl get pod, svc

Kubernetes集群YAML文件

概述

k8s 集群中对资源管理和资源对象编排部署都可以通过声明样式（YAML）文件来解决，也就是可以把需要对资源对象操作编辑到YAML 格式文件中，我们把这种文件叫做资源清单文件，通过kubectl 命令直接使用资源清单文件就可以实现对大量的资源对象进行编排部署了。一般在我们开发的时候，都是通过配置YAML文件来部署集群的。

YAML文件：就是资源清单文件，用于资源编排

YAML文件介绍

YAML概述

YAML ：仍是一种标记语言。为了强调这种语言以数据做为中心，而不是以标记语言为重点。

YAML 是一个可读性高，用来表达数据序列的格式。

YAML 基本语法

使用空格做为缩进
缩进的空格数目不重要，只要相同层级的元素左侧对齐即可
低版本缩进时不允许使用Tab 键，只允许使用空格
使用#标识注释，从这个字符一直到行尾，都会被解释器忽略
使用 — 表示新的yaml文件开始

YAML 支持的数据结构

对象

键值对的集合，又称为映射(mapping) / 哈希（hashes） / 字典（dictionary）

# 对象类型：对象的一组键值对，使用冒号结构表示
name: Tom
age: 18# yaml 也允许另一种写法，将所有键值对写成一个行内对象
hash: {name: Tom, age: 18}

数组

# 数组类型：一组连词线开头的行，构成一个数组
People
- Tom
- Jack# 数组也可以采用行内表示法
People: [Tom, Jack]

YAML文件组成部分

主要分为了两部分，一个是控制器的定义和被控制的对象

控制器的定义

被控制的对象

包含一些镜像，版本、端口等

属性说明

在一个YAML文件的控制器定义中，有很多属性名称

属性名称	介绍
apiVersion	API版本
kind	资源类型
metadata	资源元数据
spec	资源规格
replicas	副本数量
selector	标签选择器
template	Pod模板
metadata	Pod元数据
spec	Pod规格
containers	容器配置

如何快速编写YAML文件

一般来说，我们很少自己手写YAML文件，因为这里面涉及到了很多内容，我们一般都会借助工具来创建

使用kubectl create命令

这种方式一般用于资源没有部署的时候，我们可以直接创建一个YAML配置文件

# 尝试运行,并不会真正的创建镜像
kubectl create deployment web --image=nginx -o yaml --dry-run

或者我们可以输出到一个文件中

kubectl create deployment web --image=nginx -o yaml --dry-run > hello.yaml

然后我们就在文件中直接修改即可

使用kubectl get命令导出yaml文件

可以首先查看一个目前已经部署的镜像

kubectl get deploy

然后我们导出 nginx的配置

kubectl get deploy nginx -o=yaml --export > nginx.yaml

然后会生成一个 nginx.yaml 的配置文件

yaml格式的pod定义文件完整内容

apiVersion: v1       #必选，版本号，例如v1
kind: Pod       #必选，Pod
metadata:       #必选，元数据name: string       #必选，Pod名称namespace: string    #必选，Pod所属的命名空间labels:      #自定义标签- name: string     #自定义标签名字annotations:       #自定义注释列表- name: string
spec:         #必选，Pod中容器的详细定义containers:      #必选，Pod中容器列表- name: string     #必选，容器名称image: string    #必选，容器的镜像名称imagePullPolicy: [Always | Never | IfNotPresent] #获取镜像的策略 Alawys表示下载镜像 IfnotPresent表示优先使用本地镜像，否则下载镜像，Nerver表示仅使用本地镜像command: [string]    #容器的启动命令列表，如不指定，使用打包时使用的启动命令args: [string]     #容器的启动命令参数列表workingDir: string     #容器的工作目录volumeMounts:    #挂载到容器内部的存储卷配置- name: string     #引用pod定义的共享存储卷的名称，需用volumes[]部分定义的的卷名mountPath: string    #存储卷在容器内mount的绝对路径，应少于512字符readOnly: boolean    #是否为只读模式ports:       #需要暴露的端口库号列表- name: string     #端口号名称containerPort: int   #容器需要监听的端口号hostPort: int    #容器所在主机需要监听的端口号，默认与Container相同protocol: string     #端口协议，支持TCP和UDP，默认TCPenv:       #容器运行前需设置的环境变量列表- name: string     #环境变量名称value: string    #环境变量的值resources:       #资源限制和请求的设置limits:      #资源限制的设置cpu: string    #Cpu的限制，单位为core数，将用于docker run --cpu-shares参数memory: string     #内存限制，单位可以为Mib/Gib，将用于docker run --memory参数requests:      #资源请求的设置cpu: string    #Cpu请求，容器启动的初始可用数量memory: string     #内存清楚，容器启动的初始可用数量livenessProbe:     #对Pod内个容器健康检查的设置，当探测无响应几次后将自动重启该容器，检查方法有exec、httpGet和tcpSocket，对一个容器只需设置其中一种方法即可exec:      #对Pod容器内检查方式设置为exec方式command: [string]  #exec方式需要制定的命令或脚本httpGet:       #对Pod内个容器健康检查方法设置为HttpGet，需要制定Path、portpath: stringport: numberhost: stringscheme: stringHttpHeaders:- name: stringvalue: stringtcpSocket:     #对Pod内个容器健康检查方式设置为tcpSocket方式port: numberinitialDelaySeconds: 0  #容器启动完成后首次探测的时间，单位为秒timeoutSeconds: 0   #对容器健康检查探测等待响应的超时时间，单位秒，默认1秒periodSeconds: 0    #对容器监控检查的定期探测时间设置，单位秒，默认10秒一次successThreshold: 0failureThreshold: 0securityContext:privileged:falserestartPolicy: [Always | Never | OnFailure]#Pod的重启策略，Always表示一旦不管以何种方式终止运行，kubelet都将重启，OnFailure表示只有Pod以非0退出码退出才重启，Nerver表示不再重启该PodnodeSelector: obeject  #设置NodeSelector表示将该Pod调度到包含这个label的node上，以key：value的格式指定imagePullSecrets:    #Pull镜像时使用的secret名称，以key：secretkey格式指定- name: stringhostNetwork:false      #是否使用主机网络模式，默认为false，如果设置为true，表示使用宿主机网络volumes:       #在该pod上定义共享存储卷列表- name: string     #共享存储卷名称 （volumes类型有很多种）emptyDir: {}     #类型为emtyDir的存储卷，与Pod同生命周期的一个临时目录。为空值hostPath: string     #类型为hostPath的存储卷，表示挂载Pod所在宿主机的目录path: string     #Pod所在宿主机的目录，将被用于同期中mount的目录secret:      #类型为secret的存储卷，挂载集群与定义的secre对象到容器内部scretname: string  items:     - key: stringpath: stringconfigMap:     #类型为configMap的存储卷，挂载预定义的configMap对象到容器内部name: stringitems:- key: string

实例文件举例

apiVersion: extensions/v1beta1   #接口版本
kind: Deployment                 #接口类型
metadata:name: ptengine-demo               #Deployment名称namespace: ptengine-prd           #namespace 名称labels:app: ptengine-demo              #标签
spec:replicas: 3strategy:rollingUpdate:  ##由于replicas为3,则整个升级,pod个数在2-4个之间maxSurge: 1       #滚动升级时会先启动1个podmaxUnavailable: 1 #滚动升级时允许的最大Unavailable的pod个数template:         metadata:labels:app: ptengine-demo  #模板名称必填sepc: #定义容器模板，该模板可以包含多个容器containers:                                                                   - name: ptengine-demo                                                           #镜像名称image: reg.pt1.com/ptengine-prd/ptengine-demo:0.0.1-SNAPSHOT #镜像地址CMD: [ "/bin/sh","-c","cat /etc/config/path/to/special-key" ]    #启动CMDargs:                                                                #启动参数- '-storage.local.retention=$(STORAGE_RETENTION)'- '-web.external-url=$(EXTERNAL_URL)'imagePullPolicy: IfNotPresent  #如果不存在则拉取livenessProbe:       #表示container是否处于live状态。如果LivenessProbe失败，LivenessProbe将会通知kubelet对应的container不健康了。随后kubelet将kill掉container，并根据RestarPolicy进行进一步的操作。默认情况下LivenessProbe在第一次检测之前初始化值为Success，如果container没有提供LivenessProbe，则也认为是Success；httpGet:path: /health #如果没有心跳检测接口就为/port: 8080scheme: HTTPinitialDelaySeconds: 60 ##启动后延时多久开始运行检测timeoutSeconds: 5successThreshold: 1failureThreshold: 5readinessProbe:readinessProbe:httpGet:path: /health #如果没有健康检测接口就为/port: 8080scheme: HTTPinitialDelaySeconds: 30 ##启动后延时多久开始运行检测timeoutSeconds: 5successThreshold: 1failureThreshold: 5resources:              ##CPU内存限制requests:cpu: 2memory: 2048Milimits:cpu: 2memory: 2048Mienv:                    ##通过环境变量的方式，直接传递pod=自定义Linux OS环境变量- name: LOCAL_KEY     #本地Keyvalue: value- name: CONFIG_MAP_KEY  #local策略可使用configMap的配置Key，valueFrom:configMapKeyRef:name: special-config   #configmap中找到name为special-configkey: special.type      #找到name为special-config里data下的keyports:- name: httpcontainerPort: 8080 #对service暴露端口volumeMounts:     #挂载volumes中定义的磁盘- name: log-cachemount: /tmp/log- name: sdb       #普通用法，该卷跟随容器销毁，挂载一个目录mountPath: /data/media    - name: nfs-client-root    #直接挂载硬盘方法，如挂载下面的nfs目录到/mnt/nfsmountPath: /mnt/nfs- name: example-volume-config  #高级用法第1种，将ConfigMap的log-script,backup-script分别挂载到/etc/config目录下的一个相对路径path/to/...下，如果存在同名文件，直接覆盖。mountPath: /etc/config       - name: rbd-pvc                #高级用法第2中，挂载PVC(PresistentVolumeClaim)#使用volume将ConfigMap作为文件或目录直接挂载，其中每一个key-value键值对都会生成一个文件，key为文件名，value为内容，volumes:  # 定义磁盘给上面volumeMounts挂载- name: log-cacheemptyDir: {}- name: sdb  #挂载宿主机上面的目录hostPath:path: /any/path/it/will/be/replaced- name: example-volume-config  # 供ConfigMap文件内容到指定路径使用configMap:name: example-volume-config  #ConfigMap中名称items:- key: log-script           #ConfigMap中的Keypath: path/to/log-script  #指定目录下的一个相对路径path/to/log-script- key: backup-script        #ConfigMap中的Keypath: path/to/backup-script  #指定目录下的一个相对路径path/to/backup-script- name: nfs-client-root         #供挂载NFS存储类型nfs:server: 10.42.0.55          #NFS服务器地址path: /opt/public           #showmount -e 看一下路径- name: rbd-pvc                 #挂载PVC磁盘persistentVolumeClaim:claimName: rbd-pvc1         #挂载已经申请的pvc磁盘

kubernetes资源清单

资源：对象

核心资源

workload：Pod、ReplicaSet、Deployment、StatefulSet、

DaemonSet、Job、Cronjob
服务发现及均衡：Service、Ingress……
配置与存储：Volume、CSI、
- configMap、Secret
- DownwardAPI
集群级资源：
- Namespace、Node、Role、ClusterRole、RoleBinding、ClusterRoleBinding
元数据型资源：HPA、PodTemplate、LimitRange

大部分资源的配置清单：

apiVersion：group/version
kind：资源类别
metadata：元数据
- name：名称是唯一的
- namespace
- labels：标签
- annotations：注解
spec：期望的状态，disire state
status：当前状态，current state，本字段由kubernetes集群维护，用户不能随意更改删除

查询yaml
kubectl explain kind

用yaml文件创建pod

kubectl create -f nginx.yaml

用yaml文件删除pod

kubectl delete -f nginx.yaml

Kubernetes核心资源Pod

Pod概述

Pod是K8S系统中可以创建和管理的最小单元，是资源对象模型中由用户创建或部署的最小资源对象模型，也是在K8S上运行容器化应用的资源对象，其它的资源对象都是用来支撑或者扩展Pod对象功能的，比如控制器对象是用来管控Pod对象的，Service或者Ingress资源对象是用来暴露Pod引用对象的，PersistentVolume资源对象是用来为Pod提供存储等等，K8S不会直接处理容器，而是Pod，Pod是由一个或多个container组成。

Pod是Kubernetes的最重要概念，每一个Pod都有一个特殊的被称为 “根容器”的Pause容器。Pause容器对应的镜像属于Kubernetes平台的一部分，除了Pause容器，每个Pod还包含一个或多个紧密相关的用户业务容器。

Pod基本概念

最小部署的单元
Pod里面是由一个或多个容器组成【一组容器的集合】
一个pod中的容器是共享网络命名空间
Pod是短暂的
每个Pod包含一个或多个紧密相关的用户业务容器

Pod存在的意义

创建容器使用docker，一个docker对应一个容器，一个容器运行一个应用进程
Pod是多进程设计，运用多个应用程序，也就是一个Pod里面有多个容器，而一个容器里面运行一个应用程序

Pod的存在是为了亲密性应用
- 两个应用之间进行交互
- 网络之间的调用【通过127.0.0.1 或 socket】
- 两个应用之间需要频繁调用

Pod是在K8S集群中运行部署应用或服务的最小单元，它是可以支持多容器的。Pod的设计理念是支持多个容器在一个Pod中共享网络地址和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。同时Pod对多容器的支持是K8S中最基础的设计理念。在生产环境中，通常是由不同的团队各自开发构建自己的容器镜像，在部署的时候组合成一个微服务对外提供服务。

Pod是K8S集群中所有业务类型的基础，可以把Pod看作运行在K8S集群上的小机器人，不同类型的业务就需要不同类型的小机器人去执行。目前K8S的业务主要可以分为以下几种

长期伺服型：long-running
批处理型：batch
节点后台支撑型：node-daemon
有状态应用型：stateful application

上述的几种类型，分别对应的小机器人控制器为：Deployment、Job、DaemonSet 和 StatefulSet (后面将介绍控制器)

Pod实现机制

共享网络

容器本身之间相互隔离的，一般是通过 namespace 和 group 进行隔离，那么Pod里面的容器如何实现通信？
- 首先需要满足前提条件，也就是容器都在同一个namespace之间
关于Pod实现原理，首先会在Pod会创建一个根容器： pause容器，然后我们在创建业务容器【nginx，redis 等】，在我们创建业务容器的时候，会把它添加到 info容器 中

而在 info容器 中会独立出 ip地址，mac地址，port 等信息，然后实现网络的共享
- 通过 Pause 容器，把其它业务容器加入到Pause容器里，让所有业务容器在同一个名称空间中，可以实现网络共享
完整步骤如下
- 通过 Pause 容器，把其它业务容器加入到Pause容器里，让所有业务容器在同一个名称空间中，可以实现网络共享
共享存储

Pod持久化数据，专门存储到某个地方中

使用 Volumn数据卷进行共享存储，案例如下所示

Pod镜像拉取策略

我们以具体实例来说，拉取策略就是 imagePullPolicy

拉取策略主要分为了以下几种

IfNotPresent：默认值，镜像在宿主机上不存在才拉取
Always：每次创建Pod都会重新拉取一次镜像
Never：Pod永远不会主动拉取这个镜像

Pod资源限制

也就是我们Pod在进行调度的时候，可以对调度的资源进行限制，例如我们限制 Pod调度是使用的资源是 2C4G，那么在调度对应的node节点时，只会占用对应的资源，对于不满足资源的节点，将不会进行调度

示例

我们在下面的地方进行资源的限制

这里分了两个部分

request：表示调度所需的资源
limits：表示最大所占用的资源

Pod重启机制

因为Pod中包含了很多个容器，假设某个容器出现问题了，那么就会触发Pod重启机制

重启策略主要分为以下三种

Always：当容器终止退出后，总是重启容器，默认策略【nginx等，需要不断提供服务】
OnFailure：当容器异常退出（退出状态码非0）时，才重启容器。
Never：当容器终止退出，从不重启容器【批量任务】

Pod健康检查

通过容器检查，原来我们使用下面的命令来检查

kubectl get pod

但是有的时候，程序可能出现了 Java 堆内存溢出，程序还在运行，但是不能对外提供服务了，这个时候就不能通过容器检查来判断服务是否可用了

这个时候就可以使用应用层面的检查

# 存活检查，如果检查失败，将杀死容器，根据Pod的restartPolicy【重启策略】来操作
livenessProbe# 就绪检查，如果检查失败，Kubernetes会把Pod从Service endpoints中剔除
readinessProbe

Probe支持以下三种检查方式

http Get：发送HTTP请求，返回200 - 400 范围状态码为成功
exec：执行Shell命令返回状态码是0为成功
tcpSocket：发起TCP Socket建立成功

Pod调度策略

创建Pod流程

首先创建一个pod，然后链接API Server 和 Etcd【把创建出来的信息存储在etcd中】
然后创建 Scheduler，监控API Server是否有新的Pod，如果有的话，会通过调度算法，把pod调度某个node上
在node节点，会通过 kubelet -- apiserver读取etcd 拿到分配在当前node节点上的pod，然后通过docker创建容器

影响Pod调度的属性

Pod资源限制对Pod的调度会有影响

根据request找到足够node节点进行调度

节点选择器标签影响Pod调度

关于节点选择器，其实就是有两个环境，然后环境之间所用的资源配置不同

我们可以通过以下命令，给我们的节点新增标签，然后节点选择器就会进行调度了

kubectl label node node1 env_role=prod

节点亲和性

节点亲和性 nodeAffinity 和之前nodeSelector 基本一样的，根据节点上标签约束来决定Pod调度到哪些节点上

硬亲和性：约束条件必须满足
软亲和性：尝试满足，不保证

支持常用操作符：in、NotIn、Exists、Gt(大于)、Lt(小于)、DoesNotExists

反亲和性：就是和亲和性刚刚相反，如 NotIn、DoesNotExists等

污点和污点容忍

nodeSelector 和 NodeAffinity，都是Prod调度到某些节点上，属于Pod的属性，是在调度的时候实现的。

Taint 污点：节点不做普通分配调度，是节点属性

场景

专用节点【限制ip】
配置特定硬件的节点【固态硬盘】
基于Taint驱逐【在node1不放，在node2放】

查看污点状况

kubectl describe node k8smaster | grep Taint

污点值有三个

NoSchedule：一定不被调度
PreferNoSchedule：尽量不被调度【也有被调度的几率】
NoExecute：不会调度，并且还会驱逐Node已有Pod

节点添加污点

kubectl taint node [node] key=value:污点的三个值

举例：

kubectl taint node k8snode1 env_role=yes:NoSchedule

删除污点

kubectl taint node k8snode1 env_role:NoSchedule-

演示

我们现在创建多个Pod，查看最后分配到Node上的情况

首先我们创建一个 nginx 的pod

kubectl create deployment web --image=nginx

然后使用命令查看

kubectl get pods -o wide

我们可以非常明显的看到，这个Pod已经被分配到 k8snode1 节点上了

下面我们把pod复制5份，在查看情况pod情况

kubectl scale deployment web --replicas=5

我们可以发现，因为master节点存在污点的情况，所以节点都被分配到了 node1 和 node2节点上

我们可以使用下面命令，把刚刚我们创建的pod都删除

kubectl delete deployment web

现在给了更好的演示污点的用法，我们现在给 node1节点打上污点

kubectl taint node k8snode1 env_role=yes:NoSchedule

然后我们查看污点是否成功添加

kubectl describe node k8snode1 | grep Taint

然后我们在创建一个 pod

# 创建nginx pod
kubectl create deployment web --image=nginx
# 复制五次
kubectl scale deployment web --replicas=5

然后我们在进行查看

kubectl get pods -o wide

我们能够看到现在所有的pod都被分配到了 k8snode2上，因为刚刚我们给node1节点设置了污点

最后我们可以删除刚刚添加的污点

kubectl taint node k8snode1 env_role:NoSchedule-

污点容忍

污点容忍就是某个节点可能被调度，也可能不被调度

资源清单yaml配置详解

metadata

name: 名字
namespace：命名空间
labels：标签，用于分类
- app：应用程序名字，指明应用程序(键和值都可以自定义)
- tier：层次（键和值都可以自定义）
```
标签选择器：等值关系：=，==，逻辑运算集合关系：in，notin
```
annotations：注解，与label不同的地方，它不能用于挑选对象资源，仅用于为对象提供“元数据”

显示标签

kubectl get pods --show-labels ：显示所有标签
kubectl get pods -l app ：筛选标签

许多资源支持内嵌字段定义其使用的标签选择器：

matchLabels：直接给定键值

matchExpressions：基于给定的表达式来定义使用的标签选择器，{key : “KEY”,operator : ‘‘OPERATOR’’,values : [VAL1,VAL2,……] }

操作符（operator）：

In，NotIn：values字段的值必须为非空列表；

Exists，NotExists：values字段的值必须为空列表；

spec

containers: 容器定义
- name: 名称自定义
- livenessProbe：存活性探测
- readinessProbe：就绪性探测
- image: 镜像名称
- imagePullPolicy：镜像获取策略——Always(总是拉取)，Never(不拉，需要手动)，IfNoPresent(不存在就拉取)
- lifecycle：生命周期钩子
- ports：定义暴露端口
  - name：端口名称（不是必需）
  - containerPort：端口号（可自定义）
- command：
- args：
- restartPolicy: 重启策略（Always、OnFailue、Never、Default to Always）
nodeSelector：节点选择器，可以影响调度算法
nodeName：表示直接运行在指定节点上

Pod生命周期

Pending 挂起状态
Running 运行状态
Faild 失败
Successed 已经成功运行
Unknown 未知状态

Pod生命周期中的重要行为

初始化容器
容器探测
- livenes
- readness

K8S存活&就绪探测

探针类型

ExecAction
TCPSocketAction
HTTPGetAction

livenessProbe：

exec

apiVersion: v1
kind: Pod
metadata:name: liveness-exec-pod
spec:containers:- name: liveness-exec-containerimage: busybox:latestimagePullPolicy: IfNotPresentcommand: ["/bin/sh","-c","touch /tmp/healthy; sleep 20; rm -rf /tmp/healthy; sleep 3600"]livenessProbe:exec:command: ["test","-e","/tmp/healthy"]initialDelaySeconds: 2periodSeconds: 3

httpGet

apiVersion: v1
kind: Pod
metadata:name: liveness-httpd-pod
spec:containers:- name: liveness-httpd-containerimage: nginx:latestimagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80livenessProbe:httpGet:port: httppath: /index.htmlinitialDelaySeconds: 2periodSeconds: 3

readinessProbe：

httpGet

apiVersion: v1
kind: Pod
metadata:name: readiness-httpd-pod
spec:containers:- name: readiness-httpd-containerimage: nginx:latestimagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80livenessProbe:httpGet:port: httppath: /index.htmlinitialDelaySeconds: 2periodSeconds: 3readinessProbe:httpGet:port: httppath: /index.htmlinitialDelaySeconds: 2periodSeconds: 3

lifecycle生命周期钩子

postStart：容器启动后操作

apiVersion: v1
kind: Pod
metadata:name: poststart-busybox
spec:containers:- name: busybox-httpdimage: busybox:latestimagePullPolicy: IfNotPresentlifecycle:postStart:exec:command: ["/bin/sh/","-c","echo 'home page' >> /tmp/index.html"]command: ["/bin/httpd"]args: ["-f","-h /tmp"]

preStop：容器终止前操作

Kubernetes核心资源Controller-Manager

内容

什么是Controller
Pod和Controller的关系
Deployment控制器应用场景
yaml文件字段说明
Deployment控制器部署应用
升级回滚（可以直接修改yaml文件，然后执行文件）
弹性伸缩（可以直接修改yaml文件，然后执行文件）

什么是Controller

Controller是在集群上管理和运行容器的对象，Controller是实际存在的，Pod是虚拟机的

Pod和Controller的关系

Pod是通过Controller实现应用的运维，比如弹性伸缩，滚动升级等

Pod 和 Controller之间是通过label标签来建立关系，同时Controller又被称为控制器工作负载

Deployment控制器应用

Deployment控制器可以部署无状态应用
管理Pod和ReplicaSet
部署，滚动升级等功能
应用场景：web服务，微服务

Deployment表示用户对K8S集群的一次更新操作。Deployment是一个比RS( ReplicaSet, RS) 应用模型更广的 API 对象，可以是创建一个新的服务，更新一个新的服务，也可以是滚动升级一个服务。滚动升级一个服务，实际是创建一个新的RS，然后逐渐将新 RS 中副本数增加到理想状态，将旧RS中的副本数减少到0的复合操作。

这样一个复合操作用一个RS是不好描述的，所以用一个更通用的Deployment来描述。以K8S的发展方向，未来对所有长期伺服型的业务的管理，都会通过Deployment来管理。

Deployment部署应用

之前我们也使用Deployment部署过应用，如下代码所示

kubectrl create deployment web --image=nginx

但是上述代码不是很好的进行复用，因为每次我们都需要重新输入代码，所以我们都是通过YAML进行配置

但是我们可以尝试使用上面的代码创建一个镜像【只是尝试，不会创建】

kubectl create deployment web --image=nginx --dry-run -o yaml > nginx.yaml

然后输出一个yaml配置文件 nginx.yml ，配置文件如下所示

apiVersion: apps/v1
kind: Deployment
metadata:creationTimestamp: nulllabels:app: webname: web
spec:replicas: 1selector:matchLabels:app: webstrategy: {}template:metadata:creationTimestamp: nulllabels:app: webspec:containers:- image: nginxname: nginxresources: {}
status: {}

我们看到的 selector 和 label 就是我们Pod 和 Controller之间建立关系的桥梁

使用YAML创建Pod

通过刚刚的代码，我们已经生成了YAML文件，下面我们就可以使用该配置文件快速创建Pod镜像了

kubectl apply -f nginx.yaml

但是因为这个方式创建的，我们只能在集群内部进行访问，所以我们还需要对外暴露端口

kubectl expose deployment web --port=80 --type=NodePort --target-port=80 --name=web1

关于上述命令，有几个参数

–port：就是我们内部的端口号
–target-port：就是暴露外面访问的端口号
–name：名称
–type：类型

同理，我们一样可以导出对应的配置文件

kubectl expose deployment web --port=80 --type=NodePort --target-port=80 --name=web1 -o yaml > web1.yaml

得到的web1.yaml如下所示

apiVersion: v1
kind: Service
metadata:creationTimestamp: "2020-11-16T02:26:53Z"labels:app: webmanagedFields:- apiVersion: v1fieldsType: FieldsV1fieldsV1:f:metadata:f:labels:.: {}f:app: {}f:spec:f:externalTrafficPolicy: {}f:ports:.: {}k:{"port":80,"protocol":"TCP"}:.: {}f:port: {}f:protocol: {}f:targetPort: {}f:selector:.: {}f:app: {}f:sessionAffinity: {}f:type: {}manager: kubectloperation: Updatetime: "2020-11-16T02:26:53Z"name: web2namespace: defaultresourceVersion: "113693"selfLink: /api/v1/namespaces/default/services/web2uid: d570437d-a6b4-4456-8dfb-950f09534516
spec:clusterIP: 10.104.174.145externalTrafficPolicy: Clusterports:- nodePort: 32639port: 80protocol: TCPtargetPort: 80selector:app: websessionAffinity: Nonetype: NodePort
status:loadBalancer: {}

然后我们可以通过下面的命令来查看对外暴露的服务

kubectl get pods,svc

然后我们访问对应的url，即可看到 nginx了 http://192.168.177.130:32639/

升级回滚和弹性伸缩

升级：假设从版本为1.14 升级到 1.15 ，这就叫应用的升级【升级可以保证服务不中断】
回滚：从版本1.15 变成 1.14，这就叫应用的回滚
弹性伸缩：我们根据不同的业务场景，来改变Pod的数量对外提供服务，这就是弹性伸缩

应用升级和回滚

首先我们先创建一个 1.14版本的Pod

apiVersion: apps/v1
kind: Deployment
metadata:creationTimestamp: nulllabels:app: webname: web
spec:replicas: 1selector:matchLabels:app: webstrategy: {}template:metadata:creationTimestamp: nulllabels:app: webspec:containers:- image: nginx:1.14name: nginxresources: {}
status: {}

我们先指定版本为1.14，然后开始创建我们的Pod

kubectl apply -f nginx.yaml

同时，我们使用docker images命令，就能看到我们成功拉取到了一个 1.14版本的镜像

我们使用下面的命令，可以将nginx从 1.14 升级到 1.15

kubectl set image deployment web nginx=nginx:1.15

在我们执行完命令后，能看到升级的过程

首先是开始的nginx 1.14版本的Pod在运行，然后 1.15版本的在创建
然后在1.15版本创建完成后，就会暂停1.14版本
最后把1.14版本的Pod移除，完成我们的升级

我们在下载 1.15版本，容器就处于ContainerCreating状态，然后下载完成后，就用 1.15版本去替换1.14版本了，这么做的好处就是：升级可以保证服务不中断

我们到我们的node2节点上，查看我们的 docker images;

能够看到，我们已经成功拉取到了 1.15版本的nginx了

查看升级状态

下面可以，查看升级状态

kubectl rollout status deployment web

查看历史版本

我们还可以查看历史版本

kubectl rollout history deployment web

应用回滚

我们可以使用下面命令，完成回滚操作，也就是回滚到上一个版本

kubectl rollout undo deployment web

然后我们就可以查看状态

kubectl rollout status deployment web

同时我们还可以回滚到指定版本

kubectl rollout undo deployment web --to-revision=2

弹性伸缩

弹性伸缩，也就是我们通过命令一下创建多个副本

kubectl scale deployment web --replicas=10

能够清晰看到，我们一下创建了10个副本

Controller控制器种类

ReplicaSet（副本控制器，推荐使用Deployment）

代用户创建指定数量的Pod副本，并确保Pod副本数量保持用户期望的数量状态，支持滚动更新的机制；

apiVersion: apps/v1
kind: ReplicaSet
metadata:name: myappnamespace: default
spec:replicas: 3selector:matchLabels:app: myapprelease: canarytemplate:metadata:name: myapp-podlabels:app: myapprelease: canaryenvironment: devspec:containers:- name: myapp-containerimage: nginxports:- name: httpcontainerPort: 80

Deployment（管理无状态应用的最优选择，只能用于无状态应用）

建立在ReplicaSet之上，支持滚动更新，回滚……，能控制更新节奏和更新逻辑

apiVersion: apps/v1
kind: Deployment
metadata:name: myapp-deploynamespace: default
spec:replicas: 2selector:matchLabels:app: myapprelease: canarytemplate:metadata:name: myapp-deploylabels:app: myapprelease: canaryenvironment: devspec:containers:- name: myapp-containerimage: nginxports:- name: httpcontainerPort: 80

DeamonSet（一般服务是无状态的，守护进程类）

用于确保K8S集群每一个满足条件节点只运行一个特定的Pod副本，通常用来实现一些系统级的后台任务


apiVersion: apps/v1
kind: DaemonSet
metadata:name: myapp-dsnamespace: default
spec:selector:matchLabels:app: filebeatrelease: stabletemplate:metadata:name: myapp-dslabels:app: filebeatrelease: stableenvironment: devspec:containers:- name: filebeatimage: filebeatenv:- name: REDIS_HOSTvalue: redis.default.svc.cluster.local- name: REDIS_LOG_LEVELvalue: infoports:- name: httpcontainerPort: 80

Statefulset

Statefulset主要是用来部署有状态应用

对于StatefulSet中的Pod，每个Pod挂载自己独立的存储，如果一个Pod出现故障，从其他节点启动一个同样名字的Pod，要挂载上原来Pod的存储继续以它的状态提供服务。

无状态应用

我们原来使用 deployment，部署的都是无状态的应用，那什么是无状态应用？

认为Pod都是一样的
没有顺序要求
不考虑应用在哪个node上运行
能够进行随意伸缩和扩展

有状态应用

上述的因素都需要考虑到

让每个Pod独立的
让每个Pod独立的，保持Pod启动顺序和唯一性
唯一的网络标识符，持久存储
有序，比如mysql中的主从

适合StatefulSet的业务包括数据库服务MySQL 和 PostgreSQL，集群化管理服务Zookeeper、etcd等有状态服务

StatefulSet的另一种典型应用场景是作为一种比普通容器更稳定可靠的模拟虚拟机的机制。传统的虚拟机正是一种有状态的宠物，运维人员需要不断地维护它，容器刚开始流行时，我们用容器来模拟虚拟机使用，所有状态都保存在容器里，而这已被证明是非常不安全、不可靠的。

使用StatefulSet，Pod仍然可以通过漂移到不同节点提供高可用，而存储也可以通过外挂的存储来提供高可靠性，StatefulSet做的只是将确定的Pod与确定的存储关联起来保证状态的连续性。

部署有状态应用

无头service， ClusterIp：none

这里就需要使用 StatefulSet部署有状态应用

apiVersion: v1
kind: Service
metadata:name: nginxnamespace: defaultlabels:app: nginx
spec:selector:app: nginxrelease: canaryclusterIP: Noneports:- port: 80---apiVersion: apps/v1
kind: StatefulSet
metadata:name: nginx-statefulsetnamespace: default
spec:serviceName: nginxreplicas: 3selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginxports:- containerPort: 80

然后通过查看pod，能否发现每个pod都有唯一的名称

然后我们在查看service，发现是无头的service

这里有状态的约定，肯定不是简简单单通过名称来进行约定，而是更加复杂的操作

deployment：是有身份的，有唯一标识
statefulset：根据主机名 + 按照一定规则生成域名

每个pod有唯一的主机名，并且有唯一的域名

格式：主机名称.service名称.名称空间.svc.cluster.local
举例：nginx-statefulset-0.default.svc.cluster.local

DaemonSet

DaemonSet 即后台支撑型服务，主要是用来部署守护进程

长期伺服型和批处理型的核心在业务应用，可能有些节点运行多个同类业务的Pod，有些节点上又没有这类的Pod运行；而后台支撑型服务的核心关注点在K8S集群中的节点(物理机或虚拟机)，要保证每个节点上都有一个此类Pod运行。节点可能是所有集群节点，也可能是通过 nodeSelector选定的一些特定节点。典型的后台支撑型服务包括：存储、日志和监控等。在每个节点上支撑K8S集群运行的服务。

守护进程在我们每个节点上，运行的是同一个pod，新加入的节点也同样运行在同一个pod里面

例子：在每个node节点安装数据采集工具

这里是一个FileBeat镜像，主要是为了做日志采集工作

进入某个 Pod里面，进入

kubectl exec -it ds-test-cbk6v bash

通过该命令后，我们就能看到我们内部收集的日志信息了

Job和CronJob

一次性任务和定时任务

一次性任务：一次性执行完就结束
定时任务：周期性执行

Job是K8S中用来控制批处理型任务的API对象。批处理业务与长期伺服业务的主要区别就是批处理业务的运行有头有尾，而长期伺服业务在用户不停止的情况下永远运行。Job管理的Pod根据用户的设置把任务成功完成就自动退出了。成功完成的标志根据不同的 spec.completions 策略而不同：单Pod型任务有一个Pod成功就标志完成；定数成功行任务保证有N个任务全部成功；工作队列性任务根据应用确定的全局成功而标志成功。

Job

Job也即一次性任务

使用下面命令，能够看到目前已经存在的Job

kubectl get jobs

在计算完成后，通过命令查看，能够发现该任务已经完成

我们可以通过查看日志，查看到一次性任务的结果

kubectl logs pi-qpqff

CronJob

定时任务，cronjob.yaml如下所示

这里面的命令就是每个一段时间，这里是通过 cron 表达式配置的，通过 schedule字段

然后下面命令就是每个一段时间输出

我们首先用上述的配置文件，创建一个定时任务

kubectl apply -f cronjob.yaml

创建完成后，我们就可以通过下面命令查看定时任务

kubectl get cronjobs

我们可以通过日志进行查看

kubectl logs hello-1599100140-wkn79

然后每次执行，就会多出一个 pod

删除svc 和 statefulset

使用下面命令，可以删除我们添加的svc 和 statefulset

kubectl delete svc webkubectl delete statefulset --all

Replication Controller

Replication Controller 简称 RC，是K8S中的复制控制器。RC是K8S集群中最早的保证Pod高可用的API对象。通过监控运行中的Pod来保证集群中运行指定数目的Pod副本。指定的数目可以是多个也可以是1个；少于指定数目，RC就会启动新的Pod副本；多于指定数目，RC就会杀死多余的Pod副本。

即使在指定数目为1的情况下，通过RC运行Pod也比直接运行Pod更明智，因为RC也可以发挥它高可用的能力，保证永远有一个Pod在运行。RC是K8S中较早期的技术概念，只适用于长期伺服型的业务类型，比如控制Pod提供高可用的Web服务。

Replica Set

Replica Set 检查 RS，也就是副本集。RS是新一代的RC，提供同样高可用能力，区别主要在于RS后来居上，能够支持更多种类的匹配模式。副本集对象一般不单独使用，而是作为Deployment的理想状态参数来使用

Kubernetes核心技术Service

概述

前面我们了解到 Deployment 只是保证了支撑服务的微服务Pod的数量，但是没有解决如何访问这些服务的问题。一个Pod只是一个运行服务的实例，随时可能在一个节点上停止，在另一个节点以一个新的IP启动一个新的Pod，因此不能以确定的IP和端口号提供服务。

要稳定地提供服务需要服务发现和负载均衡能力。服务发现完成的工作，是针对客户端访问的服务，找到对应的后端服务实例。在K8S集群中，客户端需要访问的服务就是Service对象。每个Service会对应一个集群内部有效的虚拟IP，集群内部通过虚拟IP访问一个服务。

在K8S集群中，微服务的负载均衡是由kube-proxy实现的。kube-proxy是k8s集群内部的负载均衡器。它是一个分布式代理服务器，在K8S的每个节点上都有一个；这一设计体现了它的伸缩性优势，需要访问服务的节点越多，提供负载均衡能力的kube-proxy就越多，高可用节点也随之增多。与之相比，我们平时在服务器端使用反向代理作负载均衡，还要进一步解决反向代理的高可用问题。

Service存在的意义

防止Pod失联【服务发现】

因为Pod每次创建都对应一个IP地址，而这个IP地址是短暂的，每次随着Pod的更新都会变化，假设当我们的前端页面有多个Pod时候，同时后端也多个Pod，这个时候，他们之间的相互访问，就需要通过注册中心，拿到Pod的IP地址，然后去访问对应的Pod

定义Pod访问策略【负载均衡】

页面前端的Pod访问到后端的Pod，中间会通过Service一层，而Service在这里还能做负载均衡，负载均衡的策略有很多种实现策略，例如：

随机
轮询
响应比

Pod和Service的关系

这里Pod 和 Service 之间还是根据 label 和 selector 建立关联的【和Controller一样】

我们在访问service的时候，其实也是需要有一个ip地址，这个ip肯定不是pod的ip地址，而是虚拟IP vip

Service常用类型

Service常用类型有三种

ClusterIp：集群内部访问
NodePort：对外访问应用使用
LoadBalancer：对外访问应用使用，公有云

举例

我们可以导出一个文件包含service的配置信息

kubectl expose deployment web --port=80 --target-port=80 --dry-run -o yaml > service.yaml

service.yaml 如下所示

apiVersion: v1
kind: Service
metadata:creationTimestamp: nulllabels:app: webname: web
spec:ports:- port: 80protocol: TCPtargetPort: 80selector:app: web
status:loadBalancer: {}

如果我们没有做设置的话，默认使用的是第一种方式 ClusterIp，也就是只能在集群内部使用，我们可以添加一个type字段，用来设置我们的service类型

apiVersion: v1
kind: Service
metadata:creationTimestamp: nulllabels:app: webname: web
spec:ports:- port: 80protocol: TCPtargetPort: 80selector:app: webtype: NodePort
status:loadBalancer: {}

修改完命令后，我们使用创建一个pod

kubectl apply -f service.yaml

然后能够看到，已经成功修改为 NodePort类型了，最后剩下的一种方式就是LoadBalanced：对外访问应用使用公有云

node一般是在内网进行部署，而外网一般是不能访问到的，那么如何访问的呢？

找到一台可以通过外网访问机器，安装nginx，反向代理
手动把可以访问的节点添加到nginx中

如果我们使用LoadBalancer，就会有负载均衡的控制器，类似于nginx的功能，就不需要自己添加到nginx上

Service工作模式：

userspace
iptables
ipvs

Service的Type:
ExternalName

ClusterIP

apiVersion: v1
kind: Service
metadata:name: redisnamespace: default
spec:selector:app: redisrole: logstorclusterIP: 10.97.97.97type: ClusterIPports:- port: 6379targetPort: 6379

NodePort

apiVersion: v1
kind: Service
metadata:name: nginxnamespace: default
spec:selector:app: nginxrelease: canaryclusterIP: 10.99.99.99type: NodePortports:- port: 80targetPort: 80nodePort: 30080

LoadBalance

No ClusterIP：Headless Service 无头service

apiVersion: v1
kind: Service
metadata:name: Nginxnamespace: default
spec:selector:app: nginxrelease: canaryclusterIP: Nonetype: NodePortports:- port: 80targetPort: 80nodePort: 30080

资源记录

SVC_NAME.NS_NAME.DOMAIN.LTD.

DOMAIN.LTD : svc.cluster.local.

例如：redis.default.svc.cluster.local.

Kubernetes配置管理Secrete、ConfigMap

Secret

Secret的主要作用就是加密数据，然后存在etcd里面，让Pod容器以挂载Volume方式进行访问

场景：用户名和密码进行加密

一般场景的是对某个字符串进行base64编码进行加密

echo -n 'admin' | base64

变量形式挂载到Pod

创建secret加密数据的yaml文件 secret.yaml

然后使用下面命令创建一个pod

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jGHYy1Gc-1620547540333)(C:\Users\h7104\Desktop\新建文件夹\Kubenetes学习资料记录\picture\捕获.PNG)]

kubectl create -f secret.yaml

通过get命令查看

kubectl get pods

然后我们通过下面的命令，进入到我们的容器内部

kubectl exec -it mypod bash

然后我们就可以输出我们的值，这就是以变量的形式挂载到我们的容器中

# 输出用户
echo $SECRET_USERNAME
# 输出密码
echo $SECRET_PASSWORD

最后如果我们要删除这个Pod，就可以使用这个命令

kubectl delete -f secret-val.yaml

数据卷形式挂载

首先我们创建一个 secret-val.yaml 文件

然后创建我们的 Pod

# 根据配置创建容器
kubectl apply -f secret-val.yaml
# 进入容器
kubectl exec -it mypod bash
# 查看
ls /etc/foo

ConfigMap

ConfigMap作用是存储不加密的数据到etcd中，让Pod以变量或数据卷Volume挂载到容器中

应用场景：配置文件

创建配置文件

首先我们需要创建一个配置文件 redis.properties

redis.port=127.0.0.1
redis.port=6379
redis.password=123456

创建ConfigMap

我们使用命令创建configmap

kubectl create configmap redis-config --from-file=redis.properties

然后查看详细信息

kubectl describe cm redis-config

Volume数据卷形式挂载

首先我们需要创建一个 cm.yaml

然后使用该yaml创建我们的pod

# 创建
kubectl apply -f cm.yaml
# 查看
kubectl get pods

最后我们通过命令就可以查看结果输出了

kubectl logs mypod

以变量的形式挂载Pod

首先我们也有一个 myconfig.yaml文件，声明变量信息，然后以configmap创建

然后我们就可以创建我们的配置文件

# 创建pod
kubectl apply -f myconfig.yaml
# 获取
kubectl get cm

然后我们创建完该pod后，我们就需要在创建一个 config-var.yaml 来使用我们的配置信息

最后我们查看输出

kubectl logs mypod

Kubernetes集群安全机制

概述

当我们访问K8S集群时，需要经过三个步骤完成具体操作

认证
鉴权【授权】
准入控制

进行访问的时候，都需要经过 apiserver， apiserver做统一协调，比如门卫

访问过程中，需要证书、token、或者用户名和密码
如果访问pod需要serviceAccount

认证

对外不暴露8080端口，只能内部访问，对外使用的端口6443

客户端身份认证常用方式

https证书认证，基于ca证书
http token认证，通过token来识别用户
http基本认证，用户名 + 密码认证

鉴权

基于RBAC进行鉴权操作

基于角色访问控制

准入控制

就是准入控制器的列表，如果列表有请求内容就通过，没有的话就拒绝

RBAC介绍

基于角色的访问控制，为某个角色设置访问内容，然后用户分配该角色后，就拥有该角色的访问权限

k8s中有默认的几个角色

role：特定命名空间访问权限
ClusterRole：所有命名空间的访问权限

角色绑定

roleBinding：角色绑定到主体
ClusterRoleBinding：集群角色绑定到主体

主体

user：用户
group：用户组
serviceAccount：服务账号

RBAC实现鉴权

创建命名空间

创建命名空间

我们可以首先查看已经存在的命名空间

kubectl get namespace

然后我们创建一个自己的命名空间 roledemo

kubectl create ns roledemo

命名空间创建Pod

为什么要创建命名空间？因为如果不创建命名空间的话，默认是在default下

kubectl run nginx --image=nginx -n=roletest

创建角色

我们通过 rbac-role.yaml进行创建

tip：这个角色只对pod 有 get、list权限

然后通过 yaml创建我们的role

#### 创建
kubectl apply -f rbac-role.yaml
#### 查看
kubectl get role -n roledemo

创建角色绑定

我们还是通过 role-rolebinding.yaml 的方式，来创建我们的角色绑定

然后创建我们的角色绑定

#### 创建角色绑定
kubectl apply -f rbac-rolebinding.yaml
#### 查看角色绑定
kubectl get role, rolebinding -n roledemo

使用证书识别身份

我们首先得有一个 rbac-user.sh 证书脚本

这里包含了很多证书文件，在TSL目录下，需要复制过来

通过下面命令执行我们的脚本

./rbac-user.sh

最后我们进行测试

#### 用get命令查看 pod 【有权限】
kubectl get pods -n roledemo
#### 用get命令查看svc 【没权限】
kubectl get svc -n roledmeo

Kubernetes核心技术Ingress

前言

原来我们需要将端口号对外暴露，通过 ip + 端口号就可以进行访问

原来是使用Service中的NodePort来实现

在每个节点上都会启动端口
在访问的时候通过任何节点，通过ip + 端口号就能实现访问

但是NodePort还存在一些缺陷

因为端口不能重复，所以每个端口只能使用一次，一个端口对应一个应用
实际访问中都是用域名，根据不同域名跳转到不同端口服务中

Ingress和Pod关系

pod 和 ingress 是通过service进行关联的，而ingress作为统一入口，由service关联一组pod中

首先service就是关联我们的pod
然后ingress作为入口，首先需要到service，然后发现一组pod
发现pod后，就可以做负载均衡等操作

Ingress工作流程

在实际的访问中，我们都是需要维护很多域名， a.com 和 b.com

然后不同的域名对应的不同的Service，然后service管理不同的pod

需要注意，ingress不是内置的组件，需要我们单独的安装

使用Ingress

步骤如下所示

部署ingress Controller【需要下载官方的】
创建ingress规则【对哪个Pod、名称空间配置规则】

创建Nginx Pod

创建一个nginx应用，然后对外暴露端口

# 创建pod
kubectl create deployment web --image=nginx
# 查看
kubectl get pods

对外暴露端口

kubectl expose deployment web --port=80 --target-port=80 --type=NodePort

部署 ingress controller

下面我们来通过yaml的方式，部署我们的ingress，配置文件如下所示

apiVersion: v1
kind: Namespace
metadata:name: ingress-nginxlabels:app.kubernetes.io/name: ingress-nginxapp.kubernetes.io/part-of: ingress-nginx---kind: ConfigMap
apiVersion: v1
metadata:name: nginx-configurationnamespace: ingress-nginxlabels:app.kubernetes.io/name: ingress-nginxapp.kubernetes.io/part-of: ingress-nginx---
kind: ConfigMap
apiVersion: v1
metadata:name: tcp-servicesnamespace: ingress-nginxlabels:app.kubernetes.io/name: ingress-nginxapp.kubernetes.io/part-of: ingress-nginx---
kind: ConfigMap
apiVersion: v1
metadata:name: udp-servicesnamespace: ingress-nginxlabels:app.kubernetes.io/name: ingress-nginxapp.kubernetes.io/part-of: ingress-nginx---
apiVersion: v1
kind: ServiceAccount
metadata:name: nginx-ingress-serviceaccountnamespace: ingress-nginxlabels:app.kubernetes.io/name: ingress-nginxapp.kubernetes.io/part-of: ingress-nginx---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:name: nginx-ingress-clusterrolelabels:app.kubernetes.io/name: ingress-nginxapp.kubernetes.io/part-of: ingress-nginx
rules:- apiGroups:- ""resources:- configmaps- endpoints- nodes- pods- secretsverbs:- list- watch- apiGroups:- ""resources:- nodesverbs:- get- apiGroups:- ""resources:- servicesverbs:- get- list- watch- apiGroups:- ""resources:- eventsverbs:- create- patch- apiGroups:- "extensions"- "networking.k8s.io"resources:- ingressesverbs:- get- list- watch- apiGroups:- "extensions"- "networking.k8s.io"resources:- ingresses/statusverbs:- update---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:name: nginx-ingress-rolenamespace: ingress-nginxlabels:app.kubernetes.io/name: ingress-nginxapp.kubernetes.io/part-of: ingress-nginx
rules:- apiGroups:- ""resources:- configmaps- pods- secrets- namespacesverbs:- get- apiGroups:- ""resources:- configmapsresourceNames:# Defaults to "<election-id>-<ingress-class>"# Here: "<ingress-controller-leader>-<nginx>"# This has to be adapted if you change either parameter# when launching the nginx-ingress-controller.- "ingress-controller-leader-nginx"verbs:- get- update- apiGroups:- ""resources:- configmapsverbs:- create- apiGroups:- ""resources:- endpointsverbs:- get---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:name: nginx-ingress-role-nisa-bindingnamespace: ingress-nginxlabels:app.kubernetes.io/name: ingress-nginxapp.kubernetes.io/part-of: ingress-nginx
roleRef:apiGroup: rbac.authorization.k8s.iokind: Rolename: nginx-ingress-role
subjects:- kind: ServiceAccountname: nginx-ingress-serviceaccountnamespace: ingress-nginx---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:name: nginx-ingress-clusterrole-nisa-bindinglabels:app.kubernetes.io/name: ingress-nginxapp.kubernetes.io/part-of: ingress-nginx
roleRef:apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: nginx-ingress-clusterrole
subjects:- kind: ServiceAccountname: nginx-ingress-serviceaccountnamespace: ingress-nginx---apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-ingress-controllernamespace: ingress-nginxlabels:app.kubernetes.io/name: ingress-nginxapp.kubernetes.io/part-of: ingress-nginx
spec:replicas: 1selector:matchLabels:app.kubernetes.io/name: ingress-nginxapp.kubernetes.io/part-of: ingress-nginxtemplate:metadata:labels:app.kubernetes.io/name: ingress-nginxapp.kubernetes.io/part-of: ingress-nginxannotations:prometheus.io/port: "10254"prometheus.io/scrape: "true"spec:hostNetwork: true# wait up to five minutes for the drain of connectionsterminationGracePeriodSeconds: 300serviceAccountName: nginx-ingress-serviceaccountnodeSelector:kubernetes.io/os: linuxcontainers:- name: nginx-ingress-controllerimage: lizhenliang/nginx-ingress-controller:0.30.0args:- /nginx-ingress-controller- --configmap=$(POD_NAMESPACE)/nginx-configuration- --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services- --udp-services-configmap=$(POD_NAMESPACE)/udp-services- --publish-service=$(POD_NAMESPACE)/ingress-nginx- --annotations-prefix=nginx.ingress.kubernetes.iosecurityContext:allowPrivilegeEscalation: truecapabilities:drop:- ALLadd:- NET_BIND_SERVICE# www-data -> 101runAsUser: 101env:- name: POD_NAMEvalueFrom:fieldRef:fieldPath: metadata.name- name: POD_NAMESPACEvalueFrom:fieldRef:fieldPath: metadata.namespaceports:- name: httpcontainerPort: 80protocol: TCP- name: httpscontainerPort: 443protocol: TCPlivenessProbe:failureThreshold: 3httpGet:path: /healthzport: 10254scheme: HTTPinitialDelaySeconds: 10periodSeconds: 10successThreshold: 1timeoutSeconds: 10readinessProbe:failureThreshold: 3httpGet:path: /healthzport: 10254scheme: HTTPperiodSeconds: 10successThreshold: 1timeoutSeconds: 10lifecycle:preStop:exec:command:- /wait-shutdown---apiVersion: v1
kind: LimitRange
metadata:name: ingress-nginxnamespace: ingress-nginxlabels:app.kubernetes.io/name: ingress-nginxapp.kubernetes.io/part-of: ingress-nginx
spec:limits:- min:memory: 90Micpu: 100mtype: Container

这个文件里面，需要注意的是 hostNetwork: true，改成ture是为了让后面访问到

kubectl apply -f ingress-con.yaml

通过这种方式，其实我们在外面就能访问，这里还需要在外面添加一层

kubectl apply -f ingress-con.yaml

最后通过下面命令，查看是否成功部署 ingress

kubectl get pods -n ingress-nginx

创建ingress规则文件

创建ingress规则文件，ingress-h.yaml

添加域名访问规则

在windows 的 hosts文件，添加域名访问规则【因为我们没有域名解析，所以只能这样做】

最后通过域名就能访问

Kubernetes核心技术Helm

Helm就是一个包管理工具【类似于npm】

为什么引入Helm

首先在原来项目中都是基于yaml文件来进行部署发布的，而目前项目大部分微服务化或者模块化，会分成很多个组件来部署，每个组件可能对应一个deployment.yaml,一个service.yaml,一个Ingress.yaml还可能存在各种依赖关系，这样一个项目如果有5个组件，很可能就有15个不同的yaml文件，这些yaml分散存放，如果某天进行项目恢复的话，很难知道部署顺序，依赖关系等，而所有这些包括

基于yaml配置的集中存放
基于项目的打包
组件间的依赖

但是这种方式部署，会有什么问题呢？

如果使用之前部署单一应用，少数服务的应用，比较合适
但如果部署微服务项目，可能有几十个服务，每个服务都有一套yaml文件，需要维护大量的yaml文件，版本管理特别不方便

Helm的引入，就是为了解决这个问题

使用Helm可以把这些YAML文件作为整体管理
实现YAML文件高效复用
使用helm应用级别的版本管理

Helm介绍

Helm是一个Kubernetes的包管理工具，就像Linux下的包管理器，如yum/apt等，可以很方便的将之前打包好的yaml文件部署到kubernetes上。

Helm有三个重要概念

helm：一个命令行客户端工具，主要用于Kubernetes应用chart的创建、打包、发布和管理（相当于yum）
Chart：应用描述，一系列用于描述k8s资源相关文件的集合（把yaml打包，是yaml的集合）
Release：基于Chart的部署实体，一个chart被Helm运行后将会生成对应的release，将在K8S中创建出真实的运行资源对象。也就是应用级别的版本管理
Repository：用于发布和存储Chart的仓库

Helm组件及架构

Helm采用客户端/服务端架构，有如下组件组成

Helm CLI是Helm客户端，可以在本地执行
Tiller是服务器端组件，在Kubernetes集群上运行，并管理Kubernetes应用程序
Repository是Chart仓库，Helm客户端通过HTTP协议来访问仓库中Chart索引文件和压缩包

Helm v3变化

2019年11月13日，Helm团队发布了Helm v3的第一个稳定版本

该版本主要变化如下

架构变化
- 最明显的变化是Tiller的删除
- V3版本删除Tiller
- relesase可以在不同命名空间重用

V3之前

V3版本

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-l0yGr72u-1620547540351)(C:\Users\h7104\Desktop\新建文件夹\Kubenetes学习资料记录\picture\微信图片_20210505155614.png)]

helm配置

首先我们需要去官网下载

第一步，下载helm安装压缩文件，上传到linux系统中
第二步，解压helm压缩文件，把解压后的helm目录复制到 usr/bin 目录中
使用命令：helm

我们都知道yum需要配置yum源，那么helm就就要配置helm源

helm仓库

添加仓库

helm repo add 仓库名  仓库地址

例如

# 配置微软源
helm repo add stable http://mirror.azure.cn/kubernetes/charts
# 配置阿里源
helm repo add aliyun https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts
# 配置google源
helm repo add google https://kubernetes-charts.storage.googleapis.com/# 更新
helm repo update

然后可以查看我们添加的仓库地址

# 查看全部
helm repo list
# 查看某个
helm search repo stable

或者可以删除我们添加的源

helm repo remove stable

Helm基本命令

chart install
chart upgrade
chart rollback

使用helm快速部署应用

使用命令搜索应用

首先我们使用命令，搜索我们需要安装的应用

# 搜索 weave仓库
helm search repo weave

根据搜索内容选择安装

搜索完成后，使用命令进行安装

helm install ui aliyun/weave-scope

可以通过下面命令，来下载yaml文件【如果】

kubectl apply -f weave-scope.yaml

安装完成后，通过下面命令即可查看

helm list

同时可以通过下面命令，查看更新具体的信息

helm status ui

但是我们通过查看 svc状态，发现没有对象暴露端口

所以我们需要修改service的yaml文件，添加NodePort

kubectl edit svc ui-weave-scope

这样就可以对外暴露端口了

然后我们通过 ip + 32185 即可访问

如果自己创建Chart

使用命令，自己创建Chart

helm create mychart

创建完成后，我们就能看到在当前文件夹下，创建了一个 mychart目录

目录格式

templates：编写yaml文件存放到这个目录
values.yaml：存放的是全局的yaml文件
chart.yaml：当前chart属性配置信息

在templates文件夹创建两个文件

我们创建以下两个

deployment.yaml
service.yaml

我们可以通过下面命令创建出yaml文件

# 导出deployment.yaml
kubectl create deployment web1 --image=nginx --dry-run -o yaml > deployment.yaml
# 导出service.yaml 【可能需要创建 deployment，不然会报错】
kubectl expose deployment web1 --port=80 --target-port=80 --type=NodePort --dry-run -o yaml > service.yaml

安装mychart

执行命令创建

helm install web1 mychart

应用升级

当我们修改了mychart中的东西后，就可以进行升级操作

helm upgrade web1 mychart

chart模板使用

通过传递参数，动态渲染模板，yaml内容动态从传入参数生成

刚刚我们创建mychart的时候，看到有values.yaml文件，这个文件就是一些全局的变量，然后在templates中能取到变量的值，下面我们可以利用这个，来完成动态模板

在values.yaml定义变量和值
具体yaml文件，获取定义变量值
yaml文件中大题有几个地方不同
- image
- tag
- label
- port
- replicas

定义变量和值

在values.yaml定义变量和值

获取变量和值

我们通过表达式形式使用全局变量 {{.Values.变量名称}}

例如： {{.Release.Name}}

安装应用

在我们修改完上述的信息后，就可以尝试的创建应用了

helm install --dry-run web2 mychart

Kubernetes持久化存储

前言

之前我们有提到数据卷：emptydir ，是本地存储，pod重启，数据就不存在了，需要对数据持久化存储

对于数据持久化存储【pod重启，数据还存在】，有两种方式

nfs：网络存储【通过一台服务器来存储】

步骤

持久化服务器上操作

找一台新的服务器nfs服务端，安装nfs
设置挂载路径

使用命令安装nfs

yum install -y nfs-utils

首先创建存放数据的目录

mkdir -p /data/nfx

设置挂载路径

# 打开文件
vim /etc/exports
# 添加如下内容
/data/nfs *(rw,no_root_squash)

执行完成后，即部署完我们的持久化服务器

Node节点上操作

然后需要在k8s集群node节点上安装nfs，这里需要在 node1 和 node2节点上安装

yum install -y nfs-utils

执行完成后，会自动帮我们挂载上

启动nfs服务端

下面我们回到nfs服务端，启动我们的nfs服务

systemctl start nfs

K8s集群部署应用

最后我们在k8s集群上部署应用，使用nfs持久化存储

# 创建一个pv文件
mkdir pv
# 进入
cd pv

然后创建一个yaml文件 nfs-nginx.yaml

通过这个方式，就挂载到了刚刚我们的nfs数据节点下的 /data/nfs 目录

最后就变成了： /usr/share/nginx/html -> 192.168.44.134/data/nfs 内容是对应的

我们通过这个 yaml文件，创建一个pod

kubectl apply -f nfs-nginx.yaml

创建完成后，我们也可以查看日志

kubectl describe pod nginx-dep1

可以看到，我们的pod已经成功创建出来了，同时下图也是出于Running状态

下面我们就可以进行测试了，比如现在nfs服务节点上添加数据，然后在看数据是否存在 pod中

# 进入pod中查看
kubectl exec -it nginx-dep1 bash

PV和PVC

对于上述的方式，我们都知道，我们的ip 和端口是直接放在我们的容器上的，这样管理起来可能不方便

所以这里就需要用到 pv 和 pvc的概念了，方便我们配置和管理我们的 ip 地址等元信息

PV：持久化存储，对存储的资源进行抽象，对外提供可以调用的地方【生产者】

PVC：用于调用，不需要关心内部实现细节【消费者】

PV 和 PVC 使得 K8S 集群具备了存储的逻辑抽象能力。使得在配置Pod的逻辑里可以忽略对实际后台存储技术的配置，而把这项配置的工作交给PV的配置者，即集群的管理者。存储的PV和PVC的这种关系，跟计算的Node和Pod的关系是非常类似的；PV和Node是资源的提供者，根据集群的基础设施变化而变化，由K8s集群管理员配置；而PVC和Pod是资源的使用者，根据业务服务的需求变化而变化，由K8s集群的使用者即服务的管理员来配置。

实现流程

PVC绑定PV
定义PVC
定义PV【数据卷定义，指定数据存储服务器的ip、路径、容量和匹配模式】

举例

创建一个 pvc.yaml

第一部分是定义一个 deployment，做一个部署

副本数：3
挂载路径
调用：是通过pvc的模式

然后定义pvc

然后在创建一个 pv.yaml

然后就可以创建pod了

kubectl apply -f pv.yaml

然后我们就可以通过下面命令，查看我们的 pv 和 pvc之间的绑定关系

kubectl get pv, pvc

到这里为止，我们就完成了我们 pv 和 pvc的绑定操作，通过之前的方式，进入pod中查看内容

kubect exec -it nginx-dep1 bash

然后查看 /usr/share/nginx.html

也同样能看到刚刚的内容，其实这种操作和之前我们的nfs是一样的，只是多了一层pvc绑定pv的操作

Kubernetes集群资源监控

概述

监控指标

一个好的系统，主要监控以下内容

集群监控
- 节点资源利用率
- 节点数
- 运行Pods
Pod监控
- 容器指标
- 应用程序【程序占用多少CPU、内存】

监控平台

使用普罗米修斯【prometheus】 + Grafana 搭建监控平台

prometheus【定时搜索被监控服务的状态】
- 开源的
- 监控、报警、数据库
- 以HTTP协议周期性抓取被监控组件状态
- 不需要复杂的集成过程，使用http接口接入即可
Grafana
- 开源的数据分析和可视化工具
- 支持多种数据源

部署prometheus

首先需要部署一个守护进程

---
apiVersion: apps/v1
kind: DaemonSet
metadata:name: node-exporternamespace: kube-systemlabels:k8s-app: node-exporter
spec:selector:matchLabels:k8s-app: node-exportertemplate:metadata:labels:k8s-app: node-exporterspec:containers:- image: prom/node-exportername: node-exporterports:- containerPort: 9100protocol: TCPname: http
---
apiVersion: v1
kind: Service
metadata:labels:k8s-app: node-exportername: node-exporternamespace: kube-system
spec:ports:- name: httpport: 9100nodePort: 31672protocol: TCPtype: NodePortselector:k8s-app: node-exporter

然后执行下面命令

kubectl create -f node-exporter.yaml

执行完，发现会报错

这是因为版本不一致的问题，因为发布的正式版本，而这个属于测试版本

所以我们找到第一行，然后把内容修改为如下所示

# 修改前
apiVersion: extensions/v1beta1
# 修改后 【正式版本发布后，测试版本不能使用】
apiVersion: apps/v1

创建完成后的效果

然后通过yaml的方式部署prometheus

configmap：定义一个configmap：存储一些配置文件【不加密】
prometheus.deploy.yaml：部署一个deployment【包括端口号，资源限制】
prometheus.svc.yaml：对外暴露的端口
rbac-setup.yaml：分配一些角色的权限

下面我们进入目录下，首先部署 rbac-setup.yaml

kubectl create -f rbac-setup.yaml

然后分别部署

# 部署configmap
kubectl create -f configmap.yaml
# 部署deployment
kubectl create -f prometheus.deploy.yml
# 部署svc
kubectl create -f prometheus.svc.yml

部署完成后，我们使用下面命令查看

kubectl get pods -n kube-system

在我们部署完成后，即可看到 prometheus 的 pod了，然后通过下面命令，能够看到对应的端口

kubectl get svc -n kube-system

通过这个，我们可以看到 prometheus 对外暴露的端口为 30003，访问页面即可对应的图形化界面

http://192.168.177.130:30003

在上面我们部署完prometheus后，我们还需要来部署grafana

kubectl create -f grafana-deploy.yaml

然后执行完后，发现下面的问题

error: unable to recognize "grafana-deploy.yaml": no matches for kind "Deployment" in version "extensions/v1beta1"

我们需要修改如下内容

# 修改
apiVersion: apps/v1# 添加selector
spec:replicas: 1selector:matchLabels:app: grafanacomponent: core

修改完成后，我们继续执行上述代码

# 创建deployment
kubectl create -f grafana-deploy.yaml
# 创建svc
kubectl create -f grafana-svc.yaml
# 创建 ing
kubectl create -f grafana-ing.yaml

我们能看到，我们的grafana正在

配置数据源

下面我们需要开始打开 Grafana，然后配置数据源，导入数据显示模板

kubectl get svc -n kube-system

我们可以通过 ip + 30431 访问我们的 grafana 图形化页面

然后输入账号和密码：admin admin

进入后，我们就需要配置 prometheus 的数据源

和对应的IP【这里IP是我们的ClusterIP】

设置显示数据的模板

选择Dashboard，导入我们的模板

然后输入 315 号模板

然后选择 prometheus数据源 mydb，导入即可

导入后的效果如下所示

Kubernetes全套笔记相关推荐

Kubernetes学习笔记（一）
2019独角兽企业重金招聘Python工程师标准>>> Kubernetes学习笔记(一) 博客分类: Kubernetes 导语 2015年4月,传闻已久的Borg论文伴随Kube ...
kubernetes学习笔记（二）：k8s初体验
本文采用本地k8s v1.10.3版本开发,如果还没有搭建可参照 kubernetes学习笔记 (一):搭建本地k8s开发环境进行搭建搭建本地Docker镜像仓库 docker pull docke ...
Kubernetes学习笔记之Calico CNI Plugin源码解析(一)
女主宣言今天小编为大家分享Kubernets Calico CNI Plugin的源码学习笔记,希望对正在学习k8s相关部分的同学有所帮助: PS:丰富的一线技术.多元化的表现形式,尽在" ...
Kubernetes学习笔记-未整理
Kubernetes学习笔记标签:Kubernetes 学习笔记原文:https://github.com/wtysos11/NoteBook/blob/master/微服务/Kubernetes ...
Kubernetes学习笔记
Kubernetes学习笔记 1.简介用于自动部署.扩缩和管理容器化应用程序的开源系统,支持自动化部署.大规模可伸缩. 2.架构 2.1.Control Plane 对集群做出全局决策 Contro ...
Kubernetes学习笔记【2年以前的笔记】
Kubernetes学习笔记知识储备熟悉linux基础命令熟悉docker的基本原理和操作了解ssl证书工作原理了解负载均衡工作原理(L4/L7) 了解分布式概念了解域名解析原理了解网络 ...
深度学习与计算机视觉教程：斯坦福CS231n · 全套笔记解读
作者:韩信子@ShowMeAI 教程地址:https://www.showmeai.tech/tutorials/37 本文地址:https://www.showmeai.tech/article-d ...
Kubernetes学习笔记之Calico CNI Plugin源码解析(二)
女主宣言今天小编继续为大家分享Kubernetes Calico CNI Plugin学习笔记,希望能对大家有所帮助. PS:丰富的一线技术.多元化的表现形式,尽在"360云计算" ...
Kubernetes学习笔记（二）：Pod控制器详解：资源元信息、ReplicaSet、Deployment、DaemonSet、Job、CronJob
1.资源元信息 Kubernetes的资源对象组成:主要包括了Spec.Status两部分.其中Spec部分用来描述期望的状态,Status部分用来描述观测到的状态 Kubernetes的元数据部分. ...