文章目录
kubectl version

kubectl api-resources

kubectl cluster-info

配置kubectl自动补全
source <(kubectl completion bash)
注意:此时命令补全功能切换环境后是不生效的,如果要使切换环境后也生效需要配置全局环境变量
vim /etc/bashrc
.....
source <(kubectl completion bash) #在底部添加
source /etc/bashrc

journalctl -u kubelet -f
或者直接查看日志
cat /var/log/messages

K8S核心组件日志怎么看
kubeadm部署的 kubectl logs -f pod 组件名 -n kube-system 或者journalctl -u kubelet -f
二进制部署的 journalctl -u kubelet -f #对应节点
kubectl get <resource> [-o wide | json | yaml] [-n namespace]
kubectl get componentstatuses
kubectl get cs

命令空间的作用:用于允许不同 命令空间的相同类型的资源重名
kubectl get namespace
kubectl get ns

kubectl get all [-n default]

kubectl create ns yan
kubectl get ns

kubectl delete ns yan
kubectl get ns

例:在命名空间kube-public 创建副本控制器( deployment) 来启动Pod (nginx-yun)
kubectl create deployment nginx-yun --image=nginx -n kube-public

描述某个资源的详细信息
kubectl get pods -n kube-public
kubectl describe deployment nginx-yun -n kube-public
kubectl describe pod nginx-yun-546d5454d7-vvlm8 -n kube-public

kubectl get pods -n kube-public

kubectl exec 登录容器
kubectl exec可以跨主机登录容器,docker exec 只能在容器所在主机上登录
kubectl exec -it nginx-yun-546d5454d7-vvlm8 bash -n kube-public

由于存在deployment/rc之类的副本控制器,删除pod也会重新拉起来
kubectl delete pod nginx-yun-546d5454d7-vvlm8 -n kube-public

若pod无法删除,总是处于terminate状态, 则要强行删除pod
kubectl delete pod <pod-name> -n <namespace> --force --grace-period=0
#grace-period表示过渡存活期,默认30s,在删除pod之前允许POD慢慢终止其上的容器进程,
从而优雅退出,0表示立即终止pod
语法 : 命令字 操作指令 主控制器 pod—name 副本集数量 -n 名称空间
kubectl scale deployment nginx-yun --replicas=3 -n kube-public #调整副本集
kubectl scale deployment nginx-yun --replicas=1 -n kube-public #缩容


kubectl autoscale rc foo --max5 --cpu-precent=80
使用foo设定,使其pod的数量介于1和5之前,CPU使用率维持在80%
##首先,怎么查控制器?
kubectl get all -A |grep nginx

kubectl delete deployment nginx-yun -n kube-public 或者
kubectl delete deployment/nginx-yun -n kube-public

pod"生命周期的操作过程":创建–>发布–>更新–>回滚–>删除
pod生命周期:指的是pod在从创建到删除过程中,所包含、经历过的状态(running error ImagepullbackOFF)
##启动 nginx 实例,暴露容器端口80,设置副本数 3
kubectl create deployment nginx --image=nginx:1.15 --replicas=3 --port=80
kubectl get pods
kubectl get all

kubectl expose --help
为deployment(无状态部署)的nginx创建service, 并通过Service的80端口转发至容器的80端口上,Service的名称为nginx-service, 类型为NodePort
kubectl expose deployment nginx --port=80 --target-port=80 --name=nginx-service --type=NodePort


Kubernetes之所以需要Service, 一方面是因为Pod的IP 不是固定的(Pod可能会重建),另一方面则是因为一组Pod实例之间总会有负载均衡的需求。
Service通过label Selector实现的对一组的Pod的访问。
对于容器应用而言,Kubernetes 提供了基于VIP (虚拟IP)的网桥的方式访问 Service, 再由Service 重定向到相应的Pod。
service的类型:
1、ClusterIP:提供一个集群内部的虚拟IP以供Pod访问( service默认类型
ps:主要用于k8s内部通讯
2、NodePort:在每个Node.上打开一个端口以供外部访问,Kubernetes将会在每个Node.上打开一个端口并且每个Node的端口都是一样的,通过NodeIp:NodePort的方式Kubernetes集群外部的程序可以访问Service。
ps:每个端口只能是一种服务,端口范围只能是30000-32767
端口不够用做联邦
3、LoadBalancer:通过外部的负载均衡器来访问,通常在云平台部署LoadBalancer还需要额外的费用。
4、externalName:将service名称映射到一个DNS域名上,相当于DNS服务的CNAME记录,用于让pod去访问集群外部的资源,它本身没有绑定任何的资源
pod两种类型
kubectl get pods,svc -o wide

kubectl get endpoints

kubectl describe svc nginx-service

更改现有应用资源一些信息
查看帮助信息--help
kubectl set --help
kubectl set image --help

curl -I http://192.168.116.140:30577

kubectl set image deployment/nginx nginx=nginx:1.21


对资源进行回滚管理
kubectl rollout --help

kubectl rollout history deployment/nginx

kubectl rollout undo deployment/nginx

kubectl rollout undo deployment/nginx --to-revision=2
-revision=2:指定的是上方history里面的第几个

kubectl rollout status deployment/nginx

kubectl delete deployment/nginx

kubectl delete svc/nginx-service

Deployment控制器支持自定义控制更新过程中的滚动节奏,如“暂停(pause)”或“继续(resume)”更新操作。比如等待第一批新的Pod资源创建完成后立即暂停更新过程,此时,仅存在一部分新版本的应用,主体部分还是旧的版本。然后,再筛选一小部分的用户请求路由到新版本的Pod应用,继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的Pod资源滚动更新,否则立即回滚更新操作。这就是所谓的金丝雀发布
kubectl set image deployment/nginx nginx=nginx:1.21 && kubectl rollout pause deployment/nginx

kubectl rollout status deployment/nginx
#观察更新状态

监控更新的过程,可以看到已经新增了一个资源,但是并未按照预期的状态去删除一个旧的资源, 就是因为使用了pause暂停命令
kubectl get pods -o wide

kubectl rollout resume deployment/nginx

kubectl get pods -W

YAML,即 YAML Ain’t a Markup Language(YAML 不是一种标记语言)的递归缩写。YAML 其实意思是 Yet Another Markup Language(仍是一种标记语言)。它主要强度这种语言是以数据为中心,而不是以标记为中心,而像 XML 语言就使用了大量的标记。
YAML 可读性高,易于理解,用来表达数据序列化的格式。它的语法和其他高级语言类似,还可以简单表达数组、散列表,标量等数据形态。它使用空白符号缩进和大量依赖外观的特色,特别适合用来表达或编辑数据结构、各种配置文件。
YAML 配置文件后缀为.yml,例如application.yml
yaml 和 json 的主要区别:
大小写敏感
以空格的方式缩进标识层级关系
通常开头缩进两个空格(统一层级对应即可)
不支持制表符“tab”缩进,只使用空格缩进
关键词字符后缩进一个空格,比如冒号,逗号后面需要缩进一个字符
“---”表示YAML格式,一个文件的开始
支持以“#”表示注释

字段说明:
| apiVersion | API版本 |
|---|---|
| kind | 资源类型 |
| metadata | 资源元数据 |
| spec | 资源规格 |
| replicas | 副本数量 |
| selector | 标签选择器 |
| template | pod模板 |
| metadata | pod元数据 |
| spec | pod规格 |
| container | 容器配置 |
K8S—apiVersion对照表:
https://blog.csdn.net/weixin_36455036/article/details/104873928?spm=1001.2101.3001.6650.2&utm_medium=distribute.pc_relevant.none-task-blog-2defaultCTRLISTdefault-2.no_search_link&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2defaultCTRLISTdefault-2.no_search_link
kubectl api-versions

如果是业务场景,一般首选使用 apps/v1(apps/v1 从 v1.9 版本开始提供 API)。
在 k8s v1.16 版本之前使用的是 extensions/v1beta1,extensions/v1beta1 从 v1.20 版本开始不再提供 Ingress 资源。
带有 beta 字样的代表的是测试版本,不用在生产环境中。

mkdir /opt/demo
cd /opt/demo/
参考模板:
vim nginx-deployment.yaml
apiVersion: apps/v1 #指定api版本标签
kind: Deployment #定义资源的类型/角色,deployment 为副本控制器,
此处资源类型可以是Deployment、Job、 Ingress、 Service等
metadata: #定义资源的元数据信息,比如资源的名称、namespace、标签等信息
name: nginx-deployment #定义资源的名称,在同一个namespace空间中必须是唯一的
labels: #定义资源标签(Pod的标签)
app: nginx
spec: #定义deployment资源需要的参数属性,诸如是否在容器失败时重新启动容器的属性
replicas: 3 #定义副本数量
selector : #定义标签选择器
matchLabels: #定义匹配标签
app: nginx #匹配上面的标签,需与上面的标签定义的app保持一致
template: #定义业务模板,如果有多个副本,所有副本的属性会按照模板的相关配置进行匹配
metadata:
labels:
app: nginx
spec:
containers: #定义容器属性
- name: nginx #定义一个容器名,一个- name: 定义一个容器
image: nginx:1.15.4 #定义容器使用的镜像以及版本
ports:
- containerPort: 80 #定义容器的对外的端口
实例:
vim nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
namespace: kube-public
labels:
name: nginx-deployment
spec:
replicas: 3
selector:
matchLabels:
app: nginx-demo1
template:
metadata:
labels:
app: nginx-demo1
spec:
containers:
- name: nginx
image: nginx:1.15.4
ports:
- name: http
containerPort: 80

kubectl create -f nginx-deployment.yaml
或者
kubectl apply -f nginx-deployment.yaml

kubectl get pods -o wide -n kube-public
kubectl get deploy -n kube-public


vim nginx-service.yaml
apiVersion: v1
kind: Service
metadata:
name: nginx-demo1
namespace: kube-public
labels:
name: nginx-demo1
spec:
type: NodePort
ports:
- port: 8080
targetPort: 80
nodePort: 31111
selector:
app: nginx-demo1
kubectl apply -f nginx-service.yaml
kubectl get svc -n kube-public



port是k8s集群内部访问service的端口,即通过clusterIP: port可以从Pod所在的Node. 上访问到service
nodePort是外部访问k8s集群中service的端口,通过nodeIP: nodePort 可以从外部访问到某个service
targetPort是Pod的端口,从port或nodePort来的流量经过kube-proxy 反向代理负载均衡转发到后端Pod的targetPort上,最后进入容器
containerPort是Pod内部容器的端口,targetPort 映射到containerPort
kubectl run --dry-run 打印相应的API 对象 而不执行创建
--dry-run:试运行
kubectl run nginx-test --image=nginx --port=80 --dry-run
–dry-run 表示试运行,不真正执行命令(测试命令是否正确),即并不会真的创建出 pod 和 deployment 实例,去掉该参数后即可真正执行命令

查看生成yaml格式
使用 –dry-run 试运行可不触发生成命令,然后通过 -o yaml 可实现对其 yaml 资源配置清单的查看
kubectl run nginx-test --image=nginx --port=80 --dry-run -o yaml

查看生成json格式
可通过 -o json 查看该命令产生的 json 配置清单
kubectl run nginx-test --image=nginx --port=80 --dry-run -o json

kubectl run nginx-test --image=nginx --port=80 --dry-run -o yaml > nginx-test.ymal
kubectl create deployment nginx-test1 --image=nginx --port=80 --replicas=3 --dry-run=client -o yaml > nginx-test1.yaml

kubectl apply -f nginx-test1.yaml
kubectl get pod,deploy

kubectl get deploy/nginx-test1 -o yaml
kubectl get deploy/nginx-test1 -o yaml > nginx-test11.yaml

explain 可一层层的查看相关资源对象的帮助信息
kubectl explain deployments.spec.template.spec.containers
kubectl explain pods.spec.containers


没有相关资源,使用 run 命令 --dry-run 选项
kubectl run dryrun-test --image=nginx --port=80 --replicas=3 --dry-run -o yaml > nginx-test.yaml
已有相关资源,使用 get 命令 --export 选项
kubectl get deploy nginx-test --export -o yaml > nginx-test.yaml
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)是一个用于管理容器化应用程序的开源平台,可以帮助开发人员更轻松地部署、管理和扩展应用程序。在Kubernetes中,集群划分是一种重要的概念,可以帮助我们更好地组织和管理集群中的节点和资源。本文将介绍如何使用Kubernetes对集群进行划分,并提供详细的操作示例,希望能够帮助读者更好地了解和使用Kubernetes平台。Node划分Node划分是将集群中的节点按照一定的规则进行划分。在Kubernetes中,可以使用NodeSelector和Affinity机制来实现Node划分。NodeSelectorNodeSelector是一种将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,复制出来后,
本文导读一、前言二、Ingress和pod有什么关系三、使用Ingress对外暴露应用1.创建应用并使用NodePort暴露端口2.应用Ingress(1)部署IngressController(2)创建Ingress规则(3)在Windows系统的hosts文件添加域名访问规则一、前言在以往的操作过程中,我们都是将某端口号对外暴露,然后再使用IP+端口号进行访问服务,这是通过Service中的NodePort实现的。但是NodePort有着明显的缺陷:NodePort会在每一个node节点都启用一个端口,也就是说在集群中的任何一个node节点中,使用节点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