# kind 所有类型
kubectl api-resources -o wide --namespaced=true
| 命令 | 作用 |
|---|---|
| create | 创建资源 |
| edit | 编辑资源 |
| get | 获取资源 |
| patch | 更新(修改)资源 |
| delete | 删除资源 |
| explain | 展示资源文档 |
| 命令 | 作用 |
|---|---|
| run | 在集群中运行指定镜像 |
| expose | 暴露资源为service |
| describe | 展示资源内部信息 |
| logs | 输出容器在pod中的日志 |
| attach | 进入运行中的容器 |
| cp | 在pod内外复制文件 |
| rollout | 管理资源的发布 |
| scale | 扩/缩容Pod数量 |
| autoscale | 自动调整pod数量 |
| 资源名称 | 缩写 | 说明 | 资源作用 |
|---|---|---|---|
| nodes | no | node节点 | 集群组成部分 |
| namespace | ns | 命名空间 | 隔离Pod |
| 资源名称 | 缩写 | 说明 | 资源作用 |
|---|---|---|---|
| pods | po | pod | 装载容器的最小单元 |
| 资源名称 | 缩写 | 说明 | 资源作用 |
|---|---|---|---|
| replicationcontroller | rc | 控制pod资源 | |
| replicasets | rs | 控制pod资源 | |
| daemonsets | ds | 控制pod资源 | |
| jobs | 控制pod资源 | ||
| cronjobs | cj | 控制pod资源 | |
| horizontalpodautoscalers | hpa | 控制pod资源 | |
| statefulsets | sts | 控制pod资源 |
| 资源名称 | 缩写 | 说明 | 资源作用 |
|---|---|---|---|
| services | svc | 服务 | 统一pod对外接口 |
| ingress | ing | 统一pod对外接口 |
| 参数 | 说明 |
|---|---|
| -A | 展示所有 |
| -f | 指定文件 |
| -k | 处理kustomization目录。此标志不能与-f或-R一起使用。 |
| -L | 指定标签lebel |
| -o | 指定输出格式,常用的有json、yaml、wide(详细列表) |
| -R | 递归处理-f,–filename中使用的目录。在需要管理时非常有用 |
| -l | 要进行筛选的选择器(只支持标签查询),支持“=”、“=”和“!=”。(例如-l键1=value1,键2=value2) |
| 用法示例: | kubectl get pod -l "key=value" |
| -w | 持续跟踪命令的状态或者事件变化,类似tail -f功能 |
| -n | 指定命名空间,--namepace的缩写 |
| -i | 即使未连接任何组件,也要保持pod中容器上的stdin打开。 |
| -t | 为pod中的每个容器分配了一个tty。 |
命令行敲出的指令分为2种,
kubectl、run、create、apply 等等都是命令,-或者--的都是参数,比如--port、-image、-n
资源管理方式分类
| 类型 | 操作对象 | 适用环境 | 优点 | 缺点 | 使用频率 |
|---|---|---|---|---|---|
| 命令式对象管理 | 对象 | 测试 | 简单 | 只操作活动对象,无法审计、跟踪 | 较少 |
| 命令式对象配置 | 文件 | 开发 | 可以审计跟踪 | 项目大时,配置文件多,操作麻烦 | 常用 |
| 声明式对象配置 | 开发 | 支持目录操作 | 意外情况下难以调试 | 较少 |
直接使用命令去操作k8s资源,命令和参数一起出现
kubectl run nginx-pod --image=nginx:1.17.1 --port=80
通过命令和配置文件去操作作k8s资源,命令还是那个命令,只不过参数都放在配置文件里面
kubectl create/patch -f nginx-pod.yaml
kubectl apply -f nginx-pod.yaml
使用apply创建资源,
kubectl create -f nginx-pod.yaml
kubectl patch -f nginx-pod.yaml
[root@master ~]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
master Ready control-plane,master 15h v1.20.9
node1 Ready <none> 13h v1.20.9
node2 Ready <none> 11h v1.20.9
说明
在master节点执行以下命令即可删除
# 先卸载节点,但是还未删除
kubectl drain node1 --delete-local-data --force --ignore-daemonsets
# 删除节点
kubectl delete node node2
还需要在work节点上执行以下命令来清空ini配置
kubeadm reset
先在主节点创建令牌
# 执行后会返回一个 kubeadm 开头的命令
kubeadm token create --print-join-command
然后在需要加入集群的节点中执行令牌,注意这里的命令是通过kubeadm token create --print-join-command命令返回的结果
# 在工作节点上执行以下命令即可加入集群
kubeadm join cluster-endpoint:6443 --token xxx.xxx --discovery-token-ca-cert-hash sha256:xxx
# 第一种用法
[root@master ~]# kubectl get namespaces
NAME STATUS AGE
default Active 16h # 所有未指定namespace的对象都会被分配在default空间
kube-node-lease Active 16h # 集群节点之间的心跳维护,v1.13开始引入
kube-public Active 16h # 此命名空间可以被所有人访问(包括未认证用户)
kube-system Active 16h # k8s系统空间,所有由k8s创建的资源都分配到这个空间
# 第二种用法
kubectl get namespace
# 第三种用法
kubectl get ns
# 获取名为default的namespace
kubectl get ns default
[root@master ~]# kubectl describe ns default
Name: default
Labels: <none>
Annotations: <none>
Status: Active
No resource quota. # 针对namespace做的资源限制
No LimitRange resource. # LimitRange 针对 namespace中每个组件做的资源限制
说明
记住,名称中不能用下划线_,可以用横行- 第一种创建方式–命令行创建
kubectl create ns xxx
第二种创建方式–命令行 + 配置文件
创建一个名为namespace-dev.yaml的文件,内容如下(注意大小写,kind的头字母必须大写)
apiVersion: v1
kind: Namespace
metadata:
name: dev
然后偶执行命令进行创建
kubectl create -f namespace-dev.yaml
需要注意的是,删除后,当前命名空间下的pod、deployment、container也会一起删掉
第一种–使用命令删除
kubectl delete ns xxx
第二种–使用配置文件删除
kubectl delete -f namespace-dev.yaml
kubectl describe ns xxx
[root@master ~]# kubectl get pod -A
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system calico-kube-controllers-7498f6cbdd-k6m4q 0/1 Running 20 10h
kube-system calico-node-5bj92 0/1 Init:0/2 1 10h
kube-system calico-node-fqn48 0/1 Init:0/2 0 10h
kube-system calico-node-r2ln8 0/1 Init:0/2 1 10h
kube-system coredns-5897cd56c4-vnw4c 0/1 ContainerCreating 0 15h
kube-system coredns-5897cd56c4-zvwdn 0/1 ContainerCreating 0 15h
第二种用法
kubectl get pods -A
第三种用法
kubectl get po -A
说明
Running:运行中Init:0/2 : 正在初始化 已初始化完成数量/总数ContainerCreating : 容器正在创建中,需要注意的是,如果长时间还是这个状态的话,就是有错误了,需通过命令kubectl describe pod podName查看原因获取所有namespace的pod并监视资源变动
加上-w 表示监视资源变动信息,此时命令行进入阻塞状态,如果pod有变化将会马上呈现出来;
kubectl get pod -A -w
其他参数
# -n 表示获取指定namespace的pod
kubectl get pod -n kube-system
# 如果不加 -n 参数,默认获取的是default下的pod,所以以下2个命令的执行结果是一样的
kubectl get pod
kubectl get pod -n default
因为pod里面至少要有一个容器,所以pod是和容器一起创建的,新建一个文件pod.ymal,内容如下
apiVersion: v1
kind: Pod
metadata:
name: pod-name
namespace: dev
spec:
containers:
- image: nginx:1.17.1
name: nginx-container
ports:
- name: nginx-port
containerPort: 80
protocol: TCP
然后执行命令并指定配置文件进行创建
kubectl create -f pod.ymal
# 删除deployment,删除后,与此deployment关联的pod也会一起删除
kubectl delete deployment xxx
# 删除pod
kubectl delete pod xxx
# 为pod资源打标签,需要注意的是,打标签之前,pod必须提前创建好
kubectl label pod pod-name labelKey=labelValue -n deplot-name
# 为node资源打标签
kubectl label nodes node1 nodetag=node1
以下示例是为pod资源打标签,这种方式是和pod一起创建的,新建一个配置文件 label.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-name
namespace: dev
labels:
lebelKey1: "labelValue1"
lebelKey2: "labelValue2"
lebelKey3: "labelValue3"
spec:
containers:
- image: nginx:1.17.1
name: nginx-container
ports:
- name: nginx-port
containerPort: 80
protocol: TCP
执行命令创建pod
kubectl apply -f label.ymal
适合更新label值,前提是label的key必须已存在;
kubectl label pod pod-name labelKey=labelValue -n deplot-name --overwrite
kubectl get pod pod-name -n dev --show-labels
# 查询lebelKey1=labelValue1的pod
kubectl get pod -n dev -l lebelKey1=labelValue1 --show-labels
# 查询A不等于B的pod
kubectl get pod -n dev -l A!=B --show-labels
删除key为lebelKey的标签
# 删除pod资源的表标签
kubectl label pod ymal-create-pod-name lebelKey- -n dev
# 删除node资源的标签
kubectl label nodes node1 nodetag-
pod控制器有很多种,我们这里就用deployment
使用以下run命令运行一个nginx,deployment名称为app=run-cmd-nginx-deploy-3
kubectl create deployment app=run-cmd-nginx-deploy-3 --image=nginx:1.17.1 --port=80 --replicas=3 -n dev
# 说明
nginx-deploy # pod控制器的名称,也就是deployment,
--image=nginx:1.17.1 # 指定镜像版本
--port=80 # 指定nginx的端口
--replicas=3 # 创建三个副本,也就是会创建三个pod(注意:在k8s版本v1.8以后,r--eplicas已失效,建议使用deployment,不过仅仅是run命令失效,create 和yaml配置文件还是有效的)
-n dev # 指定namespace
通过以下命令可以看到,会自动生成一个app=run-cmd-nginx-deploy-3的标签
[root@master ~]# kubectl get deployment -o wide -n dev --show-labels
NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR LABELS
run-cmd-nginx-deploy-3 3/3 3 3 18m nginx nginx:1.17.1 app=run-cmd-nginx-deploy-3 app=run-cmd-nginx-deploy-3
新建一个deployment.yaml文件,内容如下
apiVersion: apps/v1 # 前面的apps/必须这样写,斜杠后面随便写,暂不知为何
kind: Deployment # 创建deployment
metadata:
name: ymal-deployment-name # deployment名称
namespace: dev # 所属命名空间
spec:
replicas: 3 # 副本数量
selector:
matchLabels: # 匹配标签
deploy-label-1: ymal-label # 此选择器和下面的template.metadata..labels进行关联,可以发现这俩值是一样的,一样的值就会进行关联
template: # pod模板
metadata: # 以下是pod配置
labels:
deploy-label-1: ymal-label
spec:
containers: # 以下是容器配置
- image: nginx:1.17.1
name: nginx-container
ports:
- name: nginx-port
containerPort: 80
protocol: TCP
# 查看deployment详细信息
kubectl describe deployment xxx -n dev
# 查看所有的deplyment
kubectl get deployment -A
# 查询某个deployment
kubectl get deployment xxx -n dev
# 模糊查询
kubectl get deployment -A | grep xxx
# 查询deployment下的所有pod
kubectl get pod -A | grep deployment-name
需要注意的是,一旦删除pod控制器,此pod控制器下的所有pod和容器也会一并删除;
# 第一种删除方式,直接命令删除
kubectl delete deployment xxx -n dev
# 第二种删除方式,使用配置文件进行删除
kubectl delete -f deployment.yaml
默认创建的pod是只能对内访问的,所以需要创建一个对外的访问端口,创建一个service其实就是暴露对外的访问端口
kubectl expose deployment xxx --name=service-name --port=80 --target-port=80 --type=NodePort
说明
expose deployment xxx : 需要暴露的deployment名称--name :service名称--port : service 暴露的端口--target-port : 目标端口,也就是pod容器中的端口--type:service类型,分为以下几个
创建好service之后,查看service信息,可以看到,暴露的端口为:30474,
192.168.253.131:30474就可以访问到页面了;10.96.216.128:80即可[root@master ~]# kubectl get svc -n dev
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
ymal-service-name NodePort 10.96.216.128 <none> 80:30474/TCP 10m
# 说明
CLUSTER-IP # 此ip只能内部访问
PORT(S) # 我们看到上面有2个端口80:30474,80是内部访问端口,30474是外部访问的端口;
新建一个service.ymal文件,内容如下
apiVersion: v1
kind: Service
metadata:
name: service-name
namespace: dev
spec:
clusterIP: 10.96.98.123
ports:
- port: 80
protocol: TCP
targetPort: 80
selector: # 标签选择器,需要和deployment的label一致
deploy-label-1: ymal-label
type: NodePort
以下三种用法都可以
# 第一种
kubectl get services
# 第二种
kubectl get services
# 第三种
kubectl get svc
kubectl delete service xxx
查询pod控制器和pod
kubectl get deployment,pod -n dev
Endpoint是kubernetes中的一个资源对象,存储在etcd中,用来记录一个service对应的所有pod的访问地址,它是根据service配置文件中selector描述产生的。
一个Service由一组Pod组成,这些Pod通过Endpoints暴露出来,Endpoints是实现实际服务的端点集合。换句话说,service和pod之间的联系是通过endpoints实现的。
每创建一个service,k8s会自动创建一个同名的 Endpoint出来
# 一定要加s
kubectl get endpoints -n dev
# 查看endpoint的详细信息
kubectl describe endpoints -n dev
如果是由service创建出来的endpoints,删除后会马上创建出一个同名的endpoint出来,如果要删除必须先删除service
kubectl delete endpoints xxxx -n dev
因为每次创建一个service,k8s会自动创建一个同名的 Endpoint出来,所我们直接创建service就可以了
kind: Service
apiVersion: v1
metadata:
name: nginx
namespace: dev
spec:
type: ClusterIP
ports:
- name: app-port
protocol: TCP
port: 80
targetPort: 80
selector:
app: nginx-pod
kubectl run 和 kubectl create的区别# run后面的xxx是pod名称
kubectl run xxx --image=nginx:1.17.1 --port=80
# create 后面必须指定创建的资源是什么类似,比如我下面创建了一个deployment,xxx是deployment的名字,镜像是nginx,端口80,启用3个pod副本,
kubectl create deployment xxx --image=nginx:1.17.1 --port=80 --replicas=3
--help用来查看帮助文档,如果你不知道某个命令怎么使用了,就可以用--help查询命令的用法
kubectl --help
kubectl create --help
kubectl run --help
kubectl explain --help
explain查看资源结构explain用来查看配置文件的 资源结构,如果不知道配置文件中的资源用有哪些结构,那么就可以使用explain命令来查看
# 查看pod资源结构
kubectl explain pod
# 查看容器配置的资源结构
kubectl explain pod.spec.containers
#查看namespace资源结构
kubectl explain namespace
#查看service资源结构
kubectl explain service
# 查看deployment资源结构
kubectl explain deployment
# 容器名称可通过命令`kubectl describe pod`查看
# centos 使用 /bin/bash
# ubuntu或debain 使用/bin/sh
kubectl exec pod名称 -it -c 容器名称 /bin/sh
system-view进入系统视图quit退到系统视图sysname交换机命名vlan20创建vlan(进入vlan20)displayvlan显示vlanundovlan20删除vlan20displayvlan20显示vlan里的端口20Interfacee1/0/24进入端口24portlink-typeaccessvlan20把当前端口放入vlan20undoporte1/0/10删除当前VLAN端口10displaycurrent-configuration显示当前配置02配置交换机支持TELNETinterfacevlan1进入VLAN1ipaddress192.168.3.100
文章目录一、污点(Taint)1、污点简介2、污点的组成3、污点的设置和去除二、容忍(Tolerations)1、容忍简介2、容忍的基本用法3、示例4、多污点与多容忍配置三、警戒(cordon)和转移(drain)四、Pod启动阶段(相位phase)五、故障排除步骤一、污点(Taint)节点亲和性,是Pod的一种属性(偏好或硬性要求),它使Pod被吸引到一类特定的节点Taint则相反,它使节点能够排斥一类特定的PodTaint和Toleration相互配合,可以用来避免Pod被分配到不合适的节点上。每个节点上都可以应用一个或多个taint,这表示对于那些不能容忍这些taint的Pod,是不会被
文章目录Kubernetes(k8s)工作负载一、Workloads二、Pod三、Deployment四、RC、RS、DaemonSet、StatefulSet五、Job、CronJob1、Job2、CronJob六、GCKubernetes(k8s)工作负载一、Workloads什么是工作负载(Workloads)工作负载是运行在Kubernetes上的一个应用程序。一个应用很复杂,可能由单个组件或者多个组件共同完成。无论怎样我们可以用一组Pod来表示一个应用,也就是一个工作负载Pod又是一组容器(Containers)所以关系又像是这样工作负载(Workloads)控制一组PodPod控制
前言 前端时间PHP项目部署升级需要,需要把Laravel开发的项目部署K8s上,下面以laravel项目为例,讲解采用yaml文件方式部署项目。一、部署步骤1.创建Dockerfile文件Dockerfile是一个用来构建镜像的文本文件,在容器运行时,需要把项目文件和项目运行所必须的组件安装其中。#基础镜像FROMphp:7.4-fpm#时区ARGTZ=Asia/Shanghai#更换容器时区RUNcp"/usr/share/zoneinfo/$TZ"/etc/localtime&&echo"$TZ">/etc/timezone#替换成阿里apt-get源RUNsed-i"s@http
目录前言安装containerd解压安装配置成systemd任务安装runc编辑安装cni配置containerd镜像源containerd基本使用拓展阅读nerdctl工具安装及使用整体脚本总结写在后面前言上一篇文章,我们介绍了虚拟机的基础环境以及基础的网络配置,还有一些k8s节点要用到基础环境配置。本文将带领大家把containerd给安装了containerd的项目官方地址https://github.com/containerd/containerdcontainerd的发布版本地址如下https://github.com/containerd/containerd/releases
文章目录一.k8s集群修改config1.1备份当前k8s集群配置文件1.2删除当前k8s集群的apiserver的cert和key1.3生成新的apiserver的cert和key1.4刷新admin.conf1.5重启apiserver1.6刷新.kube/config二.安装kubectl2.1下载kubectl2.2配置kubectl三.使用kubernetes-client操作k8s集群3.1依赖3.2注意(可忽略)3.3创建StatefulSet3.4运行shell命令3.5删除StatefulSet3.6线上运行注意一.k8s集群修改config因为默认的是内网IP,复制出来后,
gitclonehttp:www.git.com.cn........ 克隆git项目gitbranch 查看分支gitbranch-r查看远程分支gitpushorigin--delete分支名 删除远程分支tmpgitcheckout切换分支gitcheckout-b切换并创建分支gitcheckout-b分支名origin/分支名(如果远程分支已存在最好用此命令,在创建分支时会把远程分支最新代码一并拉下来,不会把原分支代码带过来)gitbranch-D删除分支gitpushorigin--delete分支名gitpush--set-upstreamorigin分支名 推送本地分支到远端g
k8sissue: error:Readinessprobefailed:HTTPprobefailedwithstatuscode:503explanation:Kubernetes为准备和活动探测返回HTTP503错误的事实意味着到后端的连接可能有问题。有趣的是,这不是重点。这些探针不是用来执行HTTP流的端到端测试的。探测只用于验证它们所监视的服务是否响应。简单地说,好的是自己设置的readiness探针(probe)起作用了,不好的是,自己的配置文件可能有一些其他方面的问题。具体是什么方面的问题呢?就是创建出来的container里的报错信息Read-onlyfilesystem/xx
日志收集介绍日志收集的目的:分布式日志数据统一收集,实现集中式查询和管理故障排查安全信息和事件管理报表统计及展示功能日志收集的价值:日志查询、问题排查、故障恢复和故障自愈应用日志分析,错误报警性能分析,用户行为分析k8s常用的日志收集方式:在节点上进行收集,基于daemonset部署日志收集容器,实现json-file类型(标准输出/dev/stdout,错误输出/dev/stderr)日志收集使用sidecar容器收集当前Pod内一个或多个业务容器的日志,通常基于emptyDir实现业务容器与sidecar容器之间的日志共享在容器内内置日志收集进程ES集群部署使用主机如下:IP主机名角色19
文章目录概述认证认证插件基于静态token的认证服务实践基于X509证书认证实践基于webhook认证实践鉴权k8s中RBAC的使用授权实践准入场景配额管理实践插件插件开发限流APIPriorityandFairnessAPF中的排队FlowSchema与PriorityLevelConfiguration(队列权重配置)调试命令概述kube-apiserver是k8s最重要的控制组件之一,主要提供以下功能:提供集群管理的RESTAPI接口,包括认证授权、数据校验以及集群状态变更等k8s中所有模块与etcd的数据交互都需要走APIServer,禁止直接和etcd通信APIServer请求流程概