Kubernetes入门级教程
Reference Website: https://gitee.com/yooome/golang.
1. Introduction
1.1 应用部署方式演变
- 传统部署:互联网早期,会直接将应用程序部署在物理机上
优点:
简单,不需要其它技术的参与
缺点:
不能为应用程序定义资源使用边界,很难合理地分配计算资源,而且程序之间容易产生影响- 虚拟化部署:可以在一台物理机上运行多个虚拟机,每个虚拟机都是独立的一个环境
优点:
程序环境不会相互产生影响,提供了一定程度的安全性
缺点:
增加了操作系统,浪费了部分资源- 容器化部署:与虚拟化类似,但是共享了操作系统
优点:
1.可以保证每个容器拥有自己的文件系统、CPU、内存、进程空间等
优点:
2.运行应用程序所需要的资源都被容器包装,并和底层基础架构解耦
优点:
3.容器化的应用程序可以跨云服务商、跨Linux操作系统发行版进行部署
- 容器化部署方式给带来很多的便利,但是也会出现一些问题
问题1:
可以保证每个容器拥有自己的文件系统、CPU、内存、进程空间等
问题2:
当并发访问量变大的时候,怎么样做到横向扩展容器数量- 容器管理的问题统称为
容器编排
问题
Swarm:Docker自己的容器编排工具
Mesos:Apache的一个资源统一管控的工具,需要和Marathon结合使用
Kubernetes:Google开源的的容器编排工具
1.2 概述
- Kubernetes(简称K8S) 是Google开源的分布式的容器管理平台,方便我们在服务器集群中管理我们容器化应用。它可以在集群的每个节点上运行特定的程序,来对节点中的容器进行管理。目的是实现资源管理的自动化。
- Kubernetes(简称K8S) 主要提供了如下的主要功能:
自我修复:
一旦某一个容器崩溃,能够在1秒中左右迅速启动新的容器
弹性伸缩:
可以根据需要,自动对集群中正在运行的容器数量进行调整
服务发现:
服务可以通过自动发现的形式找到它所依赖的服务
负载均衡:
如果一个服务起动了多个容器,能够自动实现请求的负载均衡
版本回退:
如果发现新发布的程序版本有问题,可以立即回退到原来的版本
存储编排:
可以根据容器自身的需求自动创建存储卷
1.3 关键字介绍
- 架构图
左面的master架构
右边是node架构- 关键字介绍
kubectl:
命令行工具
Pod:
kubernetes的最小控制单元,容器都是运行在pod中的,一个pod中可以有1个或者多个容器
controller:
负责维护集群的状态,比如副本期望数量、故障检测、自动扩展、滚动更新等
api server:
所有服务访问的唯一入口,提供认证、授权、访问控制、API 注册和发现等机制
scheduler:
负责资源的调度,按照预定的调度策略将 Pod 调度到相应的机器上
etcd:
键值对数据库,保存了整个集群的状态,官方将它定义成一个可信赖的分布式键值存储服务
kubelet:
负责维护容器的生命周期,同时也负责 Volume 和网络的管理
kube-proxy:
负责为 Service 提供 cluster 内部的服务发现和负载均衡
Container runtime:
负责镜像管理以及 Pod 和容器的真正运行
label:
标签,用于对pod进行分类,同一类pod会拥有相同的标签
NameSpace:
命名空间,用来隔离pod的运行环境- 调用过程
1.一旦kubernetes环境启动之后,master和node都会将自身的信息存储到etcd数据库中
2.一个nginx服务的安装请求会首先被发送到master节点的apiServer组件
3.apiServer组件会调用scheduler组件来决定到底应该把这个服务安装到哪个node节点上,在此时,它会从etcd中读取各个node节点的信息,然后按照一定的算法进行选择,并将结果告知apiServer
4.apiServer调用controller-manager去调度Node节点安装nginx服务上
5.kubelet接收到指令后,会通知docker,然后由docker来启动一个nginx的pod
6.一个nginx服务就运行了,如果需要访问nginx,就需要通过kube-proxy来对pod产生访问的代理
2. Cluster Install
Kubernetes 二进制安装: https://blog.csdn.net/weixin_43916074/article/details/129188190.
Kubernetes kubeadm install: https://blog.csdn.net/weixin_43916074/article/details/129188162.
3. 基础知识
- 在kubernetes中,所有的内容都抽象为资源,用户需要通过操作资源来管理kubernetes。
3.1 资源管理
- kubernetes的最小管理单元是pod而不是容器,所以只能将容器放在Pod中
- kubernetes一般也不会直接管理Pod,而是通过Pod控制器来管理Pod的。
3.1.1 资源管理方式
- 命令式对象管理:直接使用命令去操作kubernetes资源
kubectl run nginx-pod --image=nginx:1.17.1 --port=80- 命令式对象配置:通过命令配置和配置文件去操作kubernetes资源
kubectl create/patch -f nginx-pod.yaml- 声明式对象配置:通过apply命令和配置文件去操作kubernetes资源
kubectl apply -f nginx-pod.yaml
类型 | 操作对象 | 适用环境 | 优点 | 缺点 |
---|---|---|---|---|
命令式对象管理 | 对象 | 测试 | 简单 | 只能操作活动对象,无法审计、跟踪 |
命令式对象配置 | 文件 | 开发 | 可以审计、跟踪 | 项目大时,配置文件多,操作麻烦 |
声明式对象配置 | 目录 | 开发 | 支持目录操作 | 意外情况下难以调试 |
3.1.2 命令式对象管理
- kubectl命令的语法如下:
kubectl [command] [type] [name] [flags]
comand:
指定要对资源执行的操作,例如create、get、delete
type:
指定资源类型,比如deployment、pod、service
name:
指定资源的名称,名称大小写敏感
flags:
指定额外的可选参数- 查看资源类型
kubectl api-resources
- 查看操作命令
kubectl --help
- Demo
查看所有pod:kubectl get pod
查看某个pod:kubectl get pod pod_name
查看某个pod,以yaml格式展示结果:kubectl get pod pod_name -o yaml
# 创建一个namespace
[root@master ~]# kubectl create namespace dev
namespace/dev created
# 获取namespace
[root@master ~]# kubectl get ns
NAME STATUS AGE
default Active 21h
dev Active 21s
kube-node-lease Active 21h
kube-public Active 21h
kube-system Active 21h
# 在此namespace下创建并运行一个nginx的Pod
[root@master ~]# kubectl run pod --image=nginx:latest -n dev
kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead.
deployment.apps/pod created
# 查看新创建的pod
[root@master ~]# kubectl get pod -n dev
NAME READY STATUS RESTARTS AGE
pod 1/1 Running 0 21s
# 删除指定的pod
[root@master ~]# kubectl delete pod pod-864f9875b9-pcw7x
pod "pod" deleted
# 删除指定的namespace
[root@master ~]# kubectl delete ns dev
namespace "dev" deleted
3.1.3 命令式对象配置
- 创建配置文件
查看所有pod:kubectl get pod
- 创建资源
kubectl create -f nginxpod.yaml
- 查看资源
kubectl get -f nginxpod.yaml
- 删除资源
kubectl delete -f nginxpod.yaml
apiVersion: v1
kind: Namespace
metadata:
name: dev
---
apiVersion: v1
kind: Pod
metadata:
name: nginxpod
namespace: dev
spec:
containers:
- name: nginx-containers
image: nginx:latest
3.1.4 声明式对象配置
- 声明式对象配置跟命令式对象配置很相似,使用apply
kubectl apply -f nginxpod.yaml
- 声明式对象配置就是使用apply描述一个资源最终的状态
如果资源不存在,就创建,相当于 kubectl create
如果资源已存在,就更新,相当于 kubectl patch
3.1.5 总结
- 创建/更新资源
kubectl apply -f XXX.yaml- 删除资源
kubectl delete -f XXX.yaml- 查询资源
kubectl get(describe)
3.2 NameSpace
- Namespace是kubernetes系统中的一种非常重要资源,它的主要作用是用来实现多套环境的资源隔离或者多租户的资源隔离。
- kubernetes在集群启动之后,会默认创建几个namespace
3.2.1 常规创建和删除
- 创建
kubectl create ns dev- 删除
kubectl delete ns dev
3.2.2 通过配置文件创建和删除
- 创建yaml文件:ns-dev.yaml
- 创建
kubectl create -f ns-dev.yaml- 删除
kubectl delete -f ns-dev.yaml
3.2.3 查看
# 1 查看所有的ns 命令:kubectl get ns
[root@master ~]# kubectl get ns
NAME STATUS AGE
default Active 45h
kube-node-lease Active 45h
kube-public Active 45h
kube-system Active 45h
# 2 查看指定的ns 命令:kubectl get ns ns名称
[root@master ~]# kubectl get ns default
NAME STATUS AGE
default Active 45h
# 3 指定输出格式 命令:kubectl get ns ns名称 -o 格式参数
# kubernetes支持的格式有很多,比较常见的是wide、json、yaml
[root@master ~]# kubectl get ns default -o yaml
apiVersion: v1
kind: Namespace
metadata:
creationTimestamp: "2021-05-08T04:44:16Z"
name: default
resourceVersion: "151"
selfLink: /api/v1/namespaces/default
uid: 7405f73a-e486-43d4-9db6-145f1409f090
spec:
finalizers:
- kubernetes
status:
phase: Active
# 4 查看ns详情 命令:kubectl describe ns ns名称
[root@master ~]# kubectl describe ns default
Name: default
Labels: <none>
Annotations: <none>
Status: Active # Active 命名空间正在使用中 Terminating 正在删除命名空间
# ResourceQuota 针对namespace做的资源限制
# LimitRange针对namespace中的每个组件做的资源限制
No resource quota.
No LimitRange resource.
3.3 Pod
- Pod是kubernetes集群进行管理的最小单元,程序要运行必须部署在容器中,而容器必须存在于Pod中。
- Pod可以认为是容器的封装,一个Pod中可以存在一个或者多个容器。
- 集群中的各个组件也都是以Pod方式运行的
kubectl get pod -n kube-system
3.3.1 结构
- pod结构
- 每个Pod中都可以包含一个或者多个容器
1.用户程序所在的容器,数量可多可少
2.Pause容器,这是每个Pod都会有的一个根容器
>1.可以以它为依据,评估整个Pod的健康状态
>2.可以在根容器上设置Ip地址,以实现Pod内部的网路通信,Pod的之间的通讯采用虚拟二层网络技术来实现,一般用的是Flannel
3.3.2 Pod定义
apiVersion: v1 #必选,版本号,例如v1
kind: Pod #必选,资源类型,例如 Pod
metadata: #必选,元数据
name: string #必选,Pod名称
namespace: string #Pod所属的命名空间,默认为"default"
labels: #自定义标签列表
- name: string
spec: #必选,Pod中容器的详细定义
containers: #必选,Pod中容器列表
- name: string #必选,容器名称
image: string #必选,容器的镜像名称
imagePullPolicy: [ Always|Never|IfNotPresent ] #获取镜像的策略
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,默认TCP
env: #容器运行前需设置的环境变量列表
- 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 #内存请求,容器启动的初始可用数量
lifecycle: #生命周期钩子
postStart: #容器启动后立即执行此钩子,如果执行失败,会根据重启策略进行重启
preStop: #容器终止前执行此钩子,无论结果如何,容器都会终止
livenessProbe: #对Pod内各容器健康检查的设置,当探测无响应几次后将自动重启该容器
exec: #对Pod容器内检查方式设置为exec方式
command: [string] #exec方式需要制定的命令或脚本
httpGet: #对Pod内个容器健康检查方法设置为HttpGet,需要制定Path、port
path: string
port: number
host: string
scheme: string
HttpHeaders:
- name: string
value: string
tcpSocket: #对Pod内个容器健康检查方式设置为tcpSocket方式
port: number
initialDelaySeconds: 0 #容器启动完成后首次探测的时间,单位为秒
timeoutSeconds: 0 #对容器健康检查探测等待响应的超时时间,单位秒,默认1秒
periodSeconds: 0 #对容器监控检查的定期探测时间设置,单位秒,默认10秒一次
successThreshold: 0
failureThreshold: 0
securityContext:
privileged: false
restartPolicy: [Always | Never | OnFailure] #Pod的重启策略
nodeName: <string> #设置NodeName表示将该Pod调度到指定到名称的node节点上
nodeSelector: obeject #设置NodeSelector表示将该Pod调度到包含这个label的node上
imagePullSecrets: #Pull镜像时使用的secret名称,以key:secretkey格式指定
- name: string
hostNetwork: false #是否使用主机网络模式,默认为false,如果设置为true,表示使用宿主机网络
volumes: #在该pod上定义共享存储卷列表
- name: string #共享存储卷名称 (volumes类型有很多种)
emptyDir: {} #类型为emtyDir的存储卷,与Pod同生命周期的一个临时目录。为空值
hostPath: string #类型为hostPath的存储卷,表示挂载Pod所在宿主机的目录
path: string #Pod所在宿主机的目录,将被用于同期中mount的目录
secret: #类型为secret的存储卷,挂载集群与定义的secret对象到容器内部
scretname: string
items:
- key: string
path: string
configMap: #类型为configMap的存储卷,挂载预定义的configMap对象到容器内部
name: string
items:
- key: string
path: string
- 查看资源的可配置项
kubectl explain pod
kubectl explain pod.metadata
kubectl explain pod.spec.containers
- 镜像的拉取策略
Always:
总是从远程仓库拉取镜像(一直远程下载)
IfNotPresent:
本地有则使用本地镜像,本地没有则从远程仓库拉取镜像(本地有就本地 本地没远程下载)
Never:
只使用本地镜像,从不去远程仓库拉取,本地没有就报错 (一直使用本地)
- 环境变量
- port
- 资源配置
3.3.3 生命周期
- pod生命周期
1.pod创建过程
2.运行初始化容器(init container)过程
3.运行主容器(main container)
>1.容器启动后钩子(post start)、容器终止前钩子(pre stop)
>2.容器的存活性探测(liveness probe)、就绪性探测(readiness probe)
4.pod终止过程- 钩子函数
Exec命令:在容器内执行一次命令
TCPSocket:在当前容器尝试访问指定的socket
HTTPGet:在当前容器中向某url发起http请求
- Demo
3.3.4 容器探测
- 容器探测的目的
容器探测用于检测容器中的应用实例是否正常工作,是保障业务可用性的一种传统机制。如果实例的状态不符合预期,那么kubernetes就会把该问题实例" 摘除 "- 两种探针来实现容器探测
>1.liveness probes:
存活性探针,用于检测应用实例当前是否处于正常运行状态,如果不是,k8s会重启容器
>2.readiness probes:
就绪性探针,用于检测应用实例当前是否可以接收请求,如果不能,k8s不会转发流量- 两种探针支持的三个方法
Exec命令:在容器内执行一次命令,如果命令执行的退出码为0,则认为程序正常,否则不正常
TCPSocket:将会尝试访问一个用户容器的端口,如果能够建立这条连接,则认为程序正常,否则不正常
HTTPGet:调用容器内Web应用的URL,如果返回的状态码在200和399之间,则认为程序正常,否则不正常
- exce demo
- TCPSocket demo
- HTTPGet demo
3.3.5 重启策略
- 一旦容器探测出现了问题,kubernetes就会对容器所在的Pod进行重启
>1.Always :
容器失效时,自动重启该容器,这也是默认值。
>2.OnFailure :
容器终止运行且退出码不为0时重启
>3.Never :
不论状态为何,都不重启该容器- xxx.yaml demo
3.3.6 查询pod信息
其实前面已经见过很多次了,再整理一下
- 查询运行的基本信息
kubectl get pods -n dev
- 查询详细信息,运行log
kubectl describe pod nginx -n dev
3.3.7 访问pod
- kubectl get pods -n dev -o wide
3.3.8 删除pod
- delete pod nginx -n dev
3.4 Lable标签
它的作用就是在资源上添加标识,用来对它们进行区分和选择
- Label的特点
1.一个Label会以key/value键值对的形式附加到各种对象上,如Node、Pod、Service等等
2.一个资源对象可以定义任意数量的Label ,同一个Label也可以被添加到任意数量的资源对象上去
3.Label通常在资源对象定义时确定,当然也可以在对象创建后动态添加或者删除- 标签的选择
- 命令
1.添加标签
kubectl label pod nginx-pod version=1.0 -n dev
2.更新标签
kubectl label pod nginx-pod version=2.0 -n dev --overwrite
3.查看标签
kubectl get pod nginx-pod -n dev --show-labels
4.筛选标签
kubectl get pod -n dev -l version=2.0 --show-labels
5.删除标签
kubectl label pod nginx-pod version- -n dev
4. Pod控制器
4.1 控制器介绍
- pod控制器功能
- pod控制器种类
4.2 ReplicaSet(RS)
- 介绍
- yaml配置文件
- demo
- rs扩容性
- 镜像升级
- 删除rs
4.3 Deployment(Deploy)
- 介绍
- yaml文件配置
- demo
- 扩容
- 镜像更新
重建更新
编辑yaml,在spec节点下添加更新策略
变更镜像,进行验证
滚动更新
编辑yaml,在spec节点下添加更新策略
更新镜像,进行校验
- 版本回退
rollout指令参数
rollout demo
- 删除Deployment
kubectl delete -f pc-deployment.yaml
4.4 Horizontal Pod Autoscaler(HPA)
- 介绍
4.4.1 安装metrics-server
# 安装git
[root@k8s-master01 ~]# yum install git -y
# 获取metrics-server, 注意使用的版本
[root@k8s-master01 ~]# git clone -b v0.3.6 https://github.com/kubernetes-incubator/metrics-server
# 修改deployment, 注意修改的是镜像和初始化参数
[root@k8s-master01 ~]# cd /root/metrics-server/deploy/1.8+/
[root@k8s-master01 1.8+]# vim metrics-server-deployment.yaml
hostNetwork: true
image: registry.cn-hangzhou.aliyuncs.com/google_containers/metrics-server-amd64:v0.3.6
args:
- --kubelet-insecure-tls
- --kubelet-preferred-address-types=InternalIP,Hostname,InternalDNS,ExternalDNS,ExternalIP
# 安装metrics-server
[root@k8s-master01 1.8+]# kubectl apply -f ./
# 查看pod运行情况
[root@k8s-master01 1.8+]# kubectl get pod -n kube-system
metrics-server-6b976979db-2xwbj 1/1 Running 0 90s
# 使用kubectl top node 查看资源使用情况
[root@k8s-master01 1.8+]# kubectl top node
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
k8s-master01 289m 14% 1582Mi 54%
k8s-node01 81m 4% 1195Mi 40%
k8s-node02 72m 3% 1211Mi 41%
[root@k8s-master01 1.8+]# kubectl top pod -n kube-system
NAME CPU(cores) MEMORY(bytes)
coredns-6955765f44-7ptsb 3m 9Mi
coredns-6955765f44-vcwr5 3m 8Mi
etcd-master 14m 145Mi
4.4.2 准备deployment和servie
1.创建pc-hpa-pod.yaml文件
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
namespace: dev
spec:
strategy1: # 策略 =>这里注意没有后面的1
type: RollingUpdate # 滚动更新策略
replicas: 1
selector:
matchLabels:
app: nginx-pod
template:
metadata:
labels:
app: nginx-pod
spec:
containers:
- name: nginx
image: nginx:1.17.1
resources: # 资源配额
limits: # 限制资源(上限)
cpu: "1" # CPU限制,单位是core数
requests: # 请求资源(下限)
cpu: "100m" # CPU限制,单位是core数
2.测试
# 创建deployment
[root@k8s-master01 1.8+]# kubectl run nginx --image=nginx:1.17.1 --requests=cpu=100m -n dev
# 创建service
[root@k8s-master01 1.8+]# kubectl expose deployment nginx --type=NodePort --port=80 -n dev
# 查看
[root@k8s-master01 1.8+]# kubectl get deployment,pod,svc -n dev
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/nginx 1/1 1 1 47s
NAME READY STATUS RESTARTS AGE
pod/nginx-7df9756ccc-bh8dr 1/1 Running 0 47s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/nginx NodePort 10.101.18.29 <none> 80:31830/TCP 35s
4.4.3 部署HPA
1.创建pc-hpa.yaml文件
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: pc-hpa
namespace: dev
spec:
minReplicas: 1 #最小pod数量
maxReplicas: 10 #最大pod数量
targetCPUUtilizationPercentage: 3 # CPU使用率指标
scaleTargetRef: # 指定要控制的nginx信息
apiVersion: apps/v1
kind: Deployment
name: nginx
2.执行
# 创建hpa
[root@k8s-master01 1.8+]# kubectl create -f pc-hpa.yaml
horizontalpodautoscaler.autoscaling/pc-hpa created
# 查看hpa
[root@k8s-master01 1.8+]# kubectl get hpa -n dev
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
pc-hpa Deployment/nginx 0%/3% 1 10 1 62s
4.4.4 测试
- kubectl get hpa -n dev -w
- kubectl get deployment -n dev -w
- kubectl get pods -n dev -w
4.5 DaemonSet(DS)
- 介绍
- yaml配置文件
- demo
- 校验
4.6 Job
- 介绍
Job,主要用于负责批量处理(一次要处理指定数量任务)或短暂的一次性任务
- yaml配置文件
- demo
- 创建,运行并删除
4.7 CronJob(CJ)
- 介绍
- yaml配置文档
- demo
- 创建,运行和删除
5. Service
5.1 Service Introduction
- 介绍
5.2 kube-proxy支持的三种工作模式
- 1.userspace 模式
- 2.iptables 模式
- 3.ipvs 模式
5.3 Service Type
5.4 Service Use
- 1.环境准备
利用Deployment创建出3个pod,注意要为pod设置app=nginx-pod的标签
- 2.创建pod,并访问服务
- 3.创建ClusterIP类型的Service
创建yaml文件,通过selector,关联前面的pod
执行文件,查看结果
- 4.Endpoint
介绍endpoint
查看所有endpoint
kubectl get endpoints -n dev -o wide- 5.负载分发策略
两种分发的策略
两种分发的策略的测试
5.5 HeadLiness类型的Service
在某些场景中,开发人员可能不想使用Service提供的负载均衡功能,而希望自己来控制负载均衡策略,针对这种情况,kubernetes提供了HeadLiness Service,这类Service不会分配Cluster IP,如果想要访问service,只能通过service的域名进行查询。
- 创建yaml文件
- 测试
5.6 NodePort类型的Service
- 介绍
- 创建yaml文件
- 测试
5.7 LoadBalancer类型的Service
5.8 ExternalName类型的Service
- 介绍
- 创建yaml文件
- 测试
5.9 Ingress介绍
- 介绍
- demo(nginx)
5.9.1 环境搭建
# 创建文件夹
[root@k8s-master01 ~]# mkdir ingress-controller
[root@k8s-master01 ~]# cd ingress-controller/
# 获取ingress-nginx,本次案例使用的是0.30版本
[root@k8s-master01 ingress-controller]# wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/mandatory.yaml
[root@k8s-master01 ingress-controller]# wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/provider/baremetal/service-nodeport.yaml
# 修改mandatory.yaml文件中的仓库
# 修改quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.30.0
# 为quay-mirror.qiniu.com/kubernetes-ingress-controller/nginx-ingress-controller:0.30.0
# 创建ingress-nginx
[root@k8s-master01 ingress-controller]# kubectl apply -f ./
# 查看ingress-nginx
[root@k8s-master01 ingress-controller]# kubectl get pod -n ingress-nginx
NAME READY STATUS RESTARTS AGE
pod/nginx-ingress-controller-fbf967dd5-4qpbp 1/1 Running 0 12h
# 查看service
[root@k8s-master01 ingress-controller]# kubectl get svc -n ingress-nginx
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
ingress-nginx NodePort 10.98.75.163 <none> 80:32240/TCP,443:31335/TCP 11h
5.9.2 准备service和pod
- 创建模型
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
namespace: dev
spec:
replicas: 3
selector:
matchLabels:
app: nginx-pod
template:
metadata:
labels:
app: nginx-pod
spec:
containers:
- name: nginx
image: nginx:1.17.1
ports:
- containerPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: tomcat-deployment
namespace: dev
spec:
replicas: 3
selector:
matchLabels:
app: tomcat-pod
template:
metadata:
labels:
app: tomcat-pod
spec:
containers:
- name: tomcat
image: tomcat:8.5-jre10-slim
ports:
- containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: nginx-service
namespace: dev
spec:
selector:
app: nginx-pod
clusterIP: None
type: ClusterIP
ports:
- port: 80
targetPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: tomcat-service
namespace: dev
spec:
selector:
app: tomcat-pod
clusterIP: None
type: ClusterIP
ports:
- port: 8080
targetPort: 8080
# 创建
[root@k8s-master01 ~]# kubectl create -f tomcat-nginx.yaml
# 查看
[root@k8s-master01 ~]# kubectl get svc -n dev
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx-service ClusterIP None <none> 80/TCP 48s
tomcat-service ClusterIP None <none> 8080/TCP 48s
5.9.3 Http代理
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: ingress-http
namespace: dev
spec:
rules:
- host: nginx.itheima.com
http:
paths:
- path: /
backend:
serviceName: nginx-service
servicePort: 80
- host: tomcat.itheima.com
http:
paths:
- path: /
backend:
serviceName: tomcat-service
servicePort: 8080
# 创建
[root@k8s-master01 ~]# kubectl create -f ingress-http.yaml
ingress.extensions/ingress-http created
# 查看
[root@k8s-master01 ~]# kubectl get ing ingress-http -n dev
NAME HOSTS ADDRESS PORTS AGE
ingress-http nginx.itheima.com,tomcat.itheima.com 80 22s
# 查看详情
[root@k8s-master01 ~]# kubectl describe ing ingress-http -n dev
...
Rules:
Host Path Backends
---- ---- --------
nginx.itheima.com / nginx-service:80 (10.244.1.96:80,10.244.1.97:80,10.244.2.112:80)
tomcat.itheima.com / tomcat-service:8080(10.244.1.94:8080,10.244.1.95:8080,10.244.2.111:8080)
...
# 接下来,在本地电脑上配置host文件,解析上面的两个域名到192.168.109.100(master)上
# 然后,就可以分别访问tomcat.itheima.com:32240 和 nginx.itheima.com:32240 查看效果了
5.9.4 Https代理
1.创建证书
# 生成证书
openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/C=CN/ST=BJ/L=BJ/O=nginx/CN=itheima.com"
# 创建密钥
kubectl create secret tls tls-secret --key tls.key --cert tls.crt
2.创建ingress-https.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: ingress-https
namespace: dev
spec:
tls:
- hosts:
- nginx.itheima.com
- tomcat.itheima.com
secretName: tls-secret # 指定秘钥
rules:
- host: nginx.itheima.com
http:
paths:
- path: /
backend:
serviceName: nginx-service
servicePort: 80
- host: tomcat.itheima.com
http:
paths:
- path: /
backend:
serviceName: tomcat-service
servicePort: 8080
3.测试
# 创建
[root@k8s-master01 ~]# kubectl create -f ingress-https.yaml
ingress.extensions/ingress-https created
# 查看
[root@k8s-master01 ~]# kubectl get ing ingress-https -n dev
NAME HOSTS ADDRESS PORTS AGE
ingress-https nginx.itheima.com,tomcat.itheima.com 10.104.184.38 80, 443 2m42s
# 查看详情
[root@k8s-master01 ~]# kubectl describe ing ingress-https -n dev
...
TLS:
tls-secret terminates nginx.itheima.com,tomcat.itheima.com
Rules:
Host Path Backends
---- ---- --------
nginx.itheima.com / nginx-service:80 (10.244.1.97:80,10.244.1.98:80,10.244.2.119:80)
tomcat.itheima.com / tomcat-service:8080(10.244.1.99:8080,10.244.2.117:8080,10.244.2.120:8080)
...
# 下面可以通过浏览器访问https://nginx.itheima.com:31335 和 https://tomcat.itheima.com:31335来查看了
6. 数据存储
6.1 普通存储volumn
6.1.1 EmptyDir
1.创建一个volume-emptydir.yaml
apiVersion: v1
kind: Pod
metadata:
name: volume-emptydir
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
ports:
- containerPort: 80
volumeMounts: # 将logs-volume挂在到nginx容器中,对应的目录为 /var/log/nginx
- name: logs-volume
mountPath: /var/log/nginx
- name: busybox
image: busybox:1.30
command: ["/bin/sh","-c","tail -f /logs/access.log"] # 初始命令,动态读取指定文件中内容
volumeMounts: # 将logs-volume 挂在到busybox容器中,对应的目录为 /logs
- name: logs-volume
mountPath: /logs
volumes: # 声明volume, name为logs-volume,类型为emptyDir
- name: logs-volume
emptyDir: {}
2.测试
# 创建Pod
[root@k8s-master01 ~]# kubectl create -f volume-emptydir.yaml
pod/volume-emptydir created
# 查看pod
[root@k8s-master01 ~]# kubectl get pods volume-emptydir -n dev -o wide
NAME READY STATUS RESTARTS AGE IP NODE ......
volume-emptydir 2/2 Running 0 97s 10.42.2.9 node1 ......
# 通过podIp访问nginx
[root@k8s-master01 ~]# curl 10.42.2.9
......
# 通过kubectl logs命令查看指定容器的标准输出
[root@k8s-master01 ~]# kubectl logs -f volume-emptydir -n dev -c busybox
10.42.1.0 - - [27/Jun/2021:15:08:54 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.29.0" "-"
6.1.2 HostPath
1.volume-hostpath.yaml
apiVersion: v1
kind: Pod
metadata:
name: volume-hostpath
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
ports:
- containerPort: 80
volumeMounts:
- name: logs-volume
mountPath: /var/log/nginx
- name: busybox
image: busybox:1.30
command: ["/bin/sh","-c","tail -f /logs/access.log"]
volumeMounts:
- name: logs-volume
mountPath: /logs
volumes:
- name: logs-volume
hostPath:
path: /root/logs
type: DirectoryOrCreate # 目录存在就使用,不存在就先创建后使用
关于type的值的一点说明:
DirectoryOrCreate
目录存在就使用,不存在就先创建后使用
Directory
目录必须存在
FileOrCreate
文件存在就使用,不存在就先创建后使用
File
文件必须存在
Socket
unix套接字必须存在
CharDevice
字符设备必须存在
BlockDevice
块设备必须存在
2.测试
# 创建Pod
[root@k8s-master01 ~]# kubectl create -f volume-hostpath.yaml
pod/volume-hostpath created
# 查看Pod
[root@k8s-master01 ~]# kubectl get pods volume-hostpath -n dev -o wide
NAME READY STATUS RESTARTS AGE IP NODE ......
pod-volume-hostpath 2/2 Running 0 16s 10.42.2.10 node1 ......
#访问nginx
[root@k8s-master01 ~]# curl 10.42.2.10
[root@k8s-master01 ~]# kubectl logs -f volume-emptydir -n dev -c busybox
# 接下来就可以去host的/root/logs目录下查看存储的文件了
### 注意: 下面的操作需要到Pod所在的节点运行(案例中是node1)
[root@node1 ~]# ls /root/logs/
access.log error.log
# 同样的道理,如果在此目录下创建一个文件,到容器中也是可以看到的
6.1.3 NFS
1.准备nfs的环境
# 在nfs上安装nfs服务
[root@nfs ~]# yum install nfs-utils -y
# 准备一个共享目录
[root@nfs ~]# mkdir /root/data/nfs -pv
# 将共享目录以读写权限暴露给192.168.5.0/24网段中的所有主机
[root@nfs ~]# vim /etc/exports
[root@nfs ~]# more /etc/exports
/root/data/nfs 192.168.5.0/24(rw,no_root_squash)
# 启动nfs服务
[root@nfs ~]# systemctl restart nfs
# 在node上安装nfs服务,注意不需要启动
[root@k8s-master01 ~]# yum install nfs-utils -y
2.创建volume-nfs.yaml
apiVersion: v1
kind: Pod
metadata:
name: volume-nfs
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
ports:
- containerPort: 80
volumeMounts:
- name: logs-volume
mountPath: /var/log/nginx
- name: busybox
image: busybox:1.30
command: ["/bin/sh","-c","tail -f /logs/access.log"]
volumeMounts:
- name: logs-volume
mountPath: /logs
volumes:
- name: logs-volume
nfs:
server: 192.168.5.6 #nfs服务器地址
path: /root/data/nfs #共享文件路径
3.运行pod,进行测试
# 创建pod
[root@k8s-master01 ~]# kubectl create -f volume-nfs.yaml
pod/volume-nfs created
# 查看pod
[root@k8s-master01 ~]# kubectl get pods volume-nfs -n dev
NAME READY STATUS RESTARTS AGE
volume-nfs 2/2 Running 0 2m9s
# 查看nfs服务器上的共享目录,发现已经有文件了
[root@k8s-master01 ~]# ls /root/data/
access.log error.log
6.2 高级存储
6.2.1 介绍
- PV/PVC介绍
- 使用了PV和PVC之后,工作可以得到进一步的细分
存储:
存储工程师维护
PV:
kubernetes管理员维护
PVC:
kubernetes用户维护
6.2.2 PV的使用
- PV的配置清单
- 访问类型
- 回收策略
- 生命周期
1.准备NFS环境
# 创建目录
[root@nfs ~]# mkdir /root/data/{pv1,pv2,pv3} -pv
# 暴露服务
[root@nfs ~]# more /etc/exports
/root/data/pv1 192.168.5.0/24(rw,no_root_squash)
/root/data/pv2 192.168.5.0/24(rw,no_root_squash)
/root/data/pv3 192.168.5.0/24(rw,no_root_squash)
# 重启服务
[root@nfs ~]# systemctl restart nfs
2.创建pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv1
spec:
capacity:
storage: 1Gi
accessModes:
- ReadWriteMany
persistentVolumeReclaimPolicy: Retain
nfs:
path: /root/data/pv1
server: 192.168.5.6
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv2
spec:
capacity:
storage: 2Gi
accessModes:
- ReadWriteMany
persistentVolumeReclaimPolicy: Retain
nfs:
path: /root/data/pv2
server: 192.168.5.6
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv3
spec:
capacity:
storage: 3Gi
accessModes:
- ReadWriteMany
persistentVolumeReclaimPolicy: Retain
nfs:
path: /root/data/pv3
server: 192.168.5.6
3.进行测试
# 创建 pv
[root@k8s-master01 ~]# kubectl create -f pv.yaml
persistentvolume/pv1 created
persistentvolume/pv2 created
persistentvolume/pv3 created
# 查看pv
[root@k8s-master01 ~]# kubectl get pv -o wide
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS AGE VOLUMEMODE
pv1 1Gi RWX Retain Available 10s Filesystem
pv2 2Gi RWX Retain Available 10s Filesystem
pv3 3Gi RWX Retain Available 9s Filesystem
6.2.3 PVC的使用
1.创建pvc.yaml,申请pv
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc1
namespace: dev
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 1Gi
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc2
namespace: dev
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 1Gi
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc3
namespace: dev
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 1Gi
2.创建pods.yaml, 使用pv
apiVersion: v1
kind: Pod
metadata:
name: pod1
namespace: dev
spec:
containers:
- name: busybox
image: busybox:1.30
command: ["/bin/sh","-c","while true;do echo pod1 >> /root/out.txt; sleep 10; done;"]
volumeMounts:
- name: volume
mountPath: /root/
volumes:
- name: volume
persistentVolumeClaim:
claimName: pvc1
readOnly: false
---
apiVersion: v1
kind: Pod
metadata:
name: pod2
namespace: dev
spec:
containers:
- name: busybox
image: busybox:1.30
command: ["/bin/sh","-c","while true;do echo pod2 >> /root/out.txt; sleep 10; done;"]
volumeMounts:
- name: volume
mountPath: /root/
volumes:
- name: volume
persistentVolumeClaim:
claimName: pvc2
readOnly: false
3.进行测试
# 创建pod
[root@k8s-master01 ~]# kubectl create -f pods.yaml
pod/pod1 created
pod/pod2 created
# 查看pod
[root@k8s-master01 ~]# kubectl get pods -n dev -o wide
NAME READY STATUS RESTARTS AGE IP NODE
pod1 1/1 Running 0 14s 10.244.1.69 node1
pod2 1/1 Running 0 14s 10.244.1.70 node1
# 查看pvc
[root@k8s-master01 ~]# kubectl get pvc -n dev -o wide
NAME STATUS VOLUME CAPACITY ACCESS MODES AGE VOLUMEMODE
pvc1 Bound pv1 1Gi RWX 94m Filesystem
pvc2 Bound pv2 2Gi RWX 94m Filesystem
pvc3 Bound pv3 3Gi RWX 94m Filesystem
# 查看pv
[root@k8s-master01 ~]# kubectl get pv -n dev -o wide
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM AGE VOLUMEMODE
pv1 1Gi RWX Retain Bound dev/pvc1 5h11m Filesystem
pv2 2Gi RWX Retain Bound dev/pvc2 5h11m Filesystem
pv3 3Gi RWX Retain Bound dev/pvc3 5h11m Filesystem
# 查看nfs中的文件存储
[root@nfs ~]# more /root/data/pv1/out.txt
node1
node1
[root@nfs ~]# more /root/data/pv2/out.txt
node2
node2
4.生命周期
- PV和PVC之间的相互作用遵循以下生命周期
6.3 存储配置
6.3.1 ConfigMap
1.创建configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: configmap
namespace: dev
data:
info: |
username:admin
password:123456
2.使用上面的文件创建configmap
# 创建configmap
[root@k8s-master01 ~]# kubectl create -f configmap.yaml
configmap/configmap created
# 查看configmap详情
[root@k8s-master01 ~]# kubectl describe cm configmap -n dev
Name: configmap
Namespace: dev
Labels: <none>
Annotations: <none>
Data
====
info:
----
username:admin
password:123456
Events: <none>
3.创建一个pod-configmap.yaml,将上面创建的configmap挂载进去
apiVersion: v1
kind: Pod
metadata:
name: pod-configmap
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
volumeMounts: # 将configmap挂载到目录
- name: config
mountPath: /configmap/config
volumes: # 引用configmap
- name: config
configMap:
name: configmap
4.测试
# 创建pod
[root@k8s-master01 ~]# kubectl create -f pod-configmap.yaml
pod/pod-configmap created
# 查看pod
[root@k8s-master01 ~]# kubectl get pod pod-configmap -n dev
NAME READY STATUS RESTARTS AGE
pod-configmap 1/1 Running 0 6s
#进入容器
[root@k8s-master01 ~]# kubectl exec -it pod-configmap -n dev /bin/sh
# cd /configmap/config/
# ls
info
# more info
username:admin
password:123456
6.3.2 Secret
1.首先使用base64对数据进行编码
[root@k8s-master01 ~]# echo -n 'admin' | base64 #准备username
YWRtaW4=
[root@k8s-master01 ~]# echo -n '123456' | base64 #准备password
MTIzNDU2
2.编写secret.yaml,并创建Secret
apiVersion: v1
kind: Secret
metadata:
name: secret
namespace: dev
type: Opaque
data:
username: YWRtaW4=
password: MTIzNDU2
# 创建secret
[root@k8s-master01 ~]# kubectl create -f secret.yaml
secret/secret created
# 查看secret详情
[root@k8s-master01 ~]# kubectl describe secret secret -n dev
Name: secret
Namespace: dev
Labels: <none>
Annotations: <none>
Type: Opaque
Data
====
password: 6 bytes
username: 5 bytes
3.创建pod-secret.yaml,将上面创建的secret挂载进去
apiVersion: v1
kind: Pod
metadata:
name: pod-secret
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
volumeMounts: # 将secret挂载到目录
- name: config
mountPath: /secret/config
volumes:
- name: config
secret:
secretName: secret
4.测试
# 创建pod
[root@k8s-master01 ~]# kubectl create -f pod-secret.yaml
pod/pod-secret created
# 查看pod
[root@k8s-master01 ~]# kubectl get pod pod-secret -n dev
NAME READY STATUS RESTARTS AGE
pod-secret 1/1 Running 0 2m28s
# 进入容器,查看secret信息,发现已经自动解码了
[root@k8s-master01 ~]# kubectl exec -it pod-secret /bin/sh -n dev
/ # ls /secret/config/
password username
/ # more /secret/config/username
admin
/ # more /secret/config/password
123456
7. 安全认证
7.1 访问控制
Kubernetes作为一个分布式集群的管理工具,保证集群的安全性是其一个重要的任务。所谓的安全性其实就是保证对Kubernetes的各种客户端进行认证和鉴权操作。
7.1.1 客户端
7.1.2 认证、授权与准入控制
7.2 认证管理
7.2.1 三种客户端身份认证方式
1.HTTP Base认证:通过用户名+密码的方式认证
这种认证方式是把“用户名:密码”用BASE64算法进行编码后的字符串放在HTTP请求中的Header Authorization域里发送给服务端。服务端收到后进行解码,获取用户名及密码,然后进行用户身份认证的过程。
2.HTTP Token认证:通过一个Token来识别合法用户
这种认证方式是用一个很长的难以被模仿的字符串–Token来表明客户身份的一种方式。每个Token对应一个用户名,当客户端发起API调用请求时,需要在HTTP Header里放入Token,API Server接到Token后会跟服务器中保存的token进行比对,然后进行用户身份认证的过程。
3.HTTPS证书认证:基于CA根证书签名的双向数字证书认证方式
这种认证方式是安全性最高的一种方式,但是同时也是操作起来最麻烦的一种方式。
7.3 授权管理
7.3.1 几种授权策略
7.3.2 RBAC(Role-Based Access Control)
- 介绍
- Role、ClusterRole
rules中的参数
- RoleBinding、ClusterRoleBinding
RoleBinding引用ClusterRole进行授权
7.3.3 实战
1.创建账号
# 1) 创建证书
[root@k8s-master01 pki]# cd /etc/kubernetes/pki/
[root@k8s-master01 pki]# (umask 077;openssl genrsa -out devman.key 2048)
# 2) 用apiserver的证书去签署
# 2-1) 签名申请,申请的用户是devman,组是devgroup
[root@k8s-master01 pki]# openssl req -new -key devman.key -out devman.csr -subj "/CN=devman/O=devgroup"
# 2-2) 签署证书
[root@k8s-master01 pki]# openssl x509 -req -in devman.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out devman.crt -days 3650
# 3) 设置集群、用户、上下文信息
[root@k8s-master01 pki]# kubectl config set-cluster kubernetes --embed-certs=true --certificate-authority=/etc/kubernetes/pki/ca.crt --server=https://192.168.109.100:6443
[root@k8s-master01 pki]# kubectl config set-credentials devman --embed-certs=true --client-certificate=/etc/kubernetes/pki/devman.crt --client-key=/etc/kubernetes/pki/devman.key
[root@k8s-master01 pki]# kubectl config set-context devman@kubernetes --cluster=kubernetes --user=devman
# 切换账户到devman
[root@k8s-master01 pki]# kubectl config use-context devman@kubernetes
Switched to context "devman@kubernetes".
# 查看dev下pod,发现没有权限
[root@k8s-master01 pki]# kubectl get pods -n dev
Error from server (Forbidden): pods is forbidden: User "devman" cannot list resource "pods" in API group "" in the namespace "dev"
# 切换到admin账户
[root@k8s-master01 pki]# kubectl config use-context kubernetes-admin@kubernetes
Switched to context "kubernetes-admin@kubernetes".
2.创建Role和RoleBinding,为devman用户授权
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
namespace: dev
name: dev-role
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: authorization-role-binding
namespace: dev
subjects:
- kind: User
name: devman
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: dev-role
apiGroup: rbac.authorization.k8s.io
[root@k8s-master01 pki]# kubectl create -f dev-role.yaml
role.rbac.authorization.k8s.io/dev-role created
rolebinding.rbac.authorization.k8s.io/authorization-role-binding created
3.切换账户,再次验证
# 切换账户到devman
[root@k8s-master01 pki]# kubectl config use-context devman@kubernetes
Switched to context "devman@kubernetes".
# 再次查看
[root@k8s-master01 pki]# kubectl get pods -n dev
NAME READY STATUS RESTARTS AGE
nginx-deployment-66cb59b984-8wp2k 1/1 Running 0 4d1h
nginx-deployment-66cb59b984-dc46j 1/1 Running 0 4d1h
nginx-deployment-66cb59b984-thfck 1/1 Running 0 4d1h
# 为了不影响后面的学习,切回admin账户
[root@k8s-master01 pki]# kubectl config use-context kubernetes-admin@kubernetes
Switched to context "kubernetes-admin@kubernetes".
7.4 准入控制
通过了前面的认证和授权之后,还需要经过准入控制处理通过之后,apiserver才会处理这个请求。
7.4.1 command
- 命令
--admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,ResourceQuota,DefaultTolerationSeconds
- 详解
8. Command
8.0 编辑文件
# 进入某个容器
kubectl exec mypod -c ruby-container -it -- bash
# 编辑名为docker-registry的service
kubectl edit svc/docker-registry
8.1 在宿主机执行命令
# 执行 pod 的 date 命令,默认使用 pod 的第一个容器执行
kubectl exec mypod -- date
kubectl exec mypod --namespace=test -- date
# 指定 pod 中某个容器执行 date 命令
kubectl exec mypod -c ruby-container -- date
8.2 创建资源对象
# yaml
kubectl create -f xxx-rc.yaml
kubectl create -f xxx-service.yaml
# json
kubectl create -f ./pod.json
cat pod.json | kubectl create -f -
# yaml2json
kubectl create -f docker-registry.yaml --edit -o json
# 一次性创建
kubectl create -f xxx-service.yaml -f xxx-rc.yaml
# 根据目录下所有的 yaml 文件定义内容进行创建
kubectl create -f <目录>
# 使用 url 来创建资源
kubectl create -f https://git.io/vPieo
8.3 查询资源对象
# 查看所有 Node 或 Namespace 对象
kubectl get nodes
kubectl get namespace
# 查看子命令帮助信息
kubectl get --help
# 列出默认namespace中的所有pod
kubectl get pods
# 列出指定namespace中的所有pod
kubectl get pods --namespace=test
# 列出所有namespace中的所有pod
kubectl get pods --all-namespaces
# 列出所有pod并显示详细信息
kubectl get pods -o wide
kubectl get replicationcontroller web
kubectl get -k dir/
kubectl get -f pod.yaml -o json
kubectl get rc/web service/frontend pods/web-pod-13je7
kubectl get pods/app-prod-78998bf7c6-ttp9g --namespace=test -o wide
kubectl get -o template pod/web-pod-13je7 --template={{.status.phase}}
# 列出该namespace中的所有pod包括未初始化的
kubectl get pods,rc,services --include-uninitialized
# 查看所有 RC 对象
kubectl get rc
# 查看所有 Deployment 对象
# 查看全部deployment
kubectl get deployment
# 列出指定deployment
kubectl get deployment my-app
# 查看所有 Service 对象
kubectl get svc
kubectl get service
# 查看不同 Namespace 下的 Pod 对象
kubectl get pods -n default
kubectl get pods --all-namespace
8.4 查询资源描述
# 显示 Pod 详细信息
kubectl describe pods/nginx
kubectl describe pods my-pod
kubectl describe -f pod.json
# 查看 Node 详细信息
kubectl describe nodes c1
# 查看 RC 关联的 Pod 信息
kubectl describe pods <rc-name>
8.5 修改资源
# 滚动更新 pod frontend-v1
kubectl rolling-update frontend-v1 -f frontend-v2.json
# 更新资源名称并更新镜像
kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2
# 更新 frontend pod 中的镜像
kubectl rolling-update frontend --image=image:v2
# 退出已存在的进行中的滚动更新
kubectl rolling-update frontend-v1 frontend-v2 --rollback
# 强制替换; 删除后重新创建资源; 服务会中断
kubectl replace --force -f ./pod.json
# 添加标签
kubectl label pods my-pod new-label=awesome
# 添加注解
kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq
# 部分更新节点
kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}'
# 更新容器镜像;spec.containers[*].name 是必须的,因为这是合并的关键字
kubectl patch pod valid-pod -p \
'{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}'
8.6 删除资源对象
# yaml文件名字按照你创建时的文件一致
kubectl delete -f xxx.yaml
# 删除包括某个 label 的 pod 对象
kubectl delete pods -l name=<label-name>
# 删除包括某个 label 的 service 对象
kubectl delete services -l name=<label-name>
# 删除包括某个 label 的 pod 和 service 对象
kubectl delete pods,services -l name=<label-name>
# 删除所有 pod/services 对象
kubectl delete pods --all
kubectl delete service --all
kubectl delete deployment --all
8.7 查看log日志
# 不实时刷新kubectl logs mypod
kubectl logs mypod --namespace=test
# 查看日志实时刷新
kubectl logs -f mypod -c ruby-container
9. Awakening
在一秒钟内看到本质的人和花半辈子也看不清一件事本质的人,自然是不一样的命运。