K8s基础

K8s介绍

首先，他是一个全新的基于容器技术的分布式架构领先方案。Kubernetes(k8s)是Google开源的容器集群管理系统（谷歌内部:Borg）。在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。

K8s官方代码

Kubernetes是一个完备的分布式系统支撑平台，具有完备的集群管理能力，多扩多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和发现机制、內建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制以及多粒度的资源配额管理能力。同时Kubernetes提供完善的管理工具，涵盖了包括开发、部署测试、运维监控在内的各个环节。

Kubernetes中，Service是分布式集群架构的核心，一个Service对象拥有如下关 键特征：

• 拥有一个唯一指定的名字
• 拥有一个虚拟IP（Cluster IP、Service IP、或VIP）和端口号
• 能够体统某种远程服务能力
• 被映射到了提供这种服务能力的一组容器应用上

Service的服务进程目前都是基于Socket通信方式对外提供服务，比如Redis、Memcache、MySQL、Web Server，或者是实现了某个具体业务的一个特定的TCP Server进程，虽然一个Service通常由多个相关的服务进程来提供服务，每个服务进程都有一个独立的Endpoint（IP+Port）访问点，但Kubernetes能够让我们通过服务连接到指定的Service上。有了Kubernetes内奸的透明负载均衡和故障恢复机制，不管后端有多少服务进程，也不管某个服务进程是否会由于发生故障而重新部署到其他机器，都不会影响我们队服务的正常调用，更重要的是这个Service本身一旦创建就不会发生变化，意味着在Kubernetes集群中，我们不用为了服务的IP地址的变化问题而头疼了。

容器提供了强大的隔离功能，所有有必要把为Service提供服务的这组进程放入容器中进行隔离。为此，Kubernetes设计了Pod对象，将每个服务进程包装到相对应的Pod中，使其成为Pod中运行的一个容器。为了建立Service与Pod间的关联管理，Kubernetes给每个Pod贴上一个标签Label，比如运行MySQL的Pod贴上name=mysql标签，给运行PHP的Pod贴上name=php标签，然后给相应的Service定义标签选择器Label Selector，这样就能巧妙的解决了Service于Pod的关联问题。

在集群管理方面，Kubernetes将集群中的机器划分为一个Master节点和一群工作节点Node，其中，在Master节点运行着集群管理相关的一组进程kube-apiserver、kube-controller-manager和kube-scheduler，这些进程实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理能力，并且都是全自动完成的。Node作为集群中的工作节点，运行真正的应用程序，在Node上Kubernetes管理的最小运行单元是Pod。Node上运行着Kubernetes的kubelet、kube-proxy服务进程，这些服务进程负责Pod的创建、启动、监控、重启、销毁以及实现软件模式的负载均衡器。

在Kubernetes集群中，它解决了传统IT系统中服务扩容和升级的两大难题。你只需为需要扩容的Service关联的Pod创建一个Replication Controller简称（RC），则该Service的扩容及后续的升级等问题将迎刃而解。在一个RC定义文件中包括以下3个关键信息。

• 目标Pod的定义
• 目标Pod需要运行的副本数量（Replicas）
• 要监控的目标Pod标签（Label）

在创建好RC后，Kubernetes会通过RC中定义的的Label筛选出对应Pod实例并实时监控其状态和数量，如果实例数量少于定义的副本数量，则会根据RC中定义的Pod模板来创建一个新的Pod，然后将新Pod调度到合适的Node上启动运行，知道Pod实例的数量达到预定目标，这个过程完全是自动化。

Kubernetes优势:

• 容器编排

• 轻量级

• 开源

• 弹性伸缩

• 负载均衡

K8s特性

• 自我修复
  在节点故障时，重新启动失败的容器，替换和重新部署，保证预期的副本数量；杀死健康检查失败的容器，并且在未准备好之前不会处理客户端请求，确保线上服务不中断。

• 弹性伸缩
  使用命令、UI或者基于CPU使用情况自动快速扩容和缩容应用实例，保证应用业务高峰并发时的高可用性；业务低谷时回收资源，以最小成本运行服务。

• 自动部署与回滚
  K8S采用滚动更新应用，一次更新一个Pod，而不是同时删除所有的Pod，如果更新过程中出现问题，将回滚更改，确保升级不影响业务。

• 服务发现和负载均衡
  K8S为多个容器提供一个统一访问入口，并且负载均衡关联的所有容器，使得用户无需考虑容器IP网络问题。

• 机密和配置管理
  管理机密数据和应用程序配置，而不需要把敏感数据暴露在镜像里，提高安全性。并且可以将一些常用的配置存储在K8S当中，方便应用程序使用。
  容器化应用程序的最大问题在于我们配置容器内的应用程序比较困难。基于镜像启动一个容器后，如果期望容器中的应用程序换一个配置该怎么办呢?如果我们定义一个entrypoint的脚本，而这个脚本可以接受用户传入的变量参数，把变量的值转换为容器内的应用程序可读取的配置,从而能完成容器化应用程序的配置。
  之所以这么麻烦是因为早期的应用程序不是面向云原生而开发的，所以那些应用程序要通过读取配置文件来获取配置，而云原生开发的应用程序可以基于环境变量来获取配置。
  这种配置方式使得一个镜像能满足用户在不同环境下运行同一个镜像为不同配置的容器的需求。但是在编排工具当中，这种配置方式会存在一些问题,比如配置信息保存到哪里?如果我们用编排平台让容器启动自动化了，但每次启动容器时我们还要手工去传递环境变量的值,这是一个很麻烦的事,所以我们需要一个外部的组件保存这些配置信息于外部，当镜像启动为容器时，只需要让镜像去加载外部的配置中心中的配置信息，就能完成应用程序的配置。

• 存储编排
  挂载外部存储系统，无论是来自本地存储、公有云(AWS)、还是网络存储(NFS,Ceph,GFS)都作为集群资源的一部分使用，极大提高存储使用的灵活性。把存储卷实现动态供给，当容器需要存储卷时，根据容器自身的需求创建能够满足其需要的存储卷。

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

K8s架构与组件

K8s就是一个组合多台主机的资源整合成一个大的资源池，并同意对外进行计算、存储等能力的集群。

架构示意图：

1.Master

k8s集群的管理节点，负责管理集群，提供集群的资源数据访问入口。拥有Etcd存储服务（可选），运行Api Server进程，Controller Manager服务进程及Scheduler服务进程，关联工作节点Node。Kubernetes API server提供HTTP Rest接口的关键服务进程，是Kubernetes里所有资源的增、删、改、查等操作的唯一入口。也是集群控制的入口进程；Kubernetes Controller Manager是Kubernetes所有资源对象的自动化控制中心；Kubernetes Schedule是负责资源调度（Pod调度）的进程

API Server ：负责接收并处理请求
Scheduler： 调度容器创建的请求
Controller： 确保已创建的容器处于健康状态
Controller Manager： 确保后端节点上的控制器处于健康状态

2.Node

Node是Kubernetes集群架构中运行Pod的服务节点（亦叫agent或minion）。Node是Kubernetes集群操作的单元，用来承载被分配Pod的运行，是Pod运行的宿主机。关联Master管理节点，拥有名称和IP、系统资源信息。运行docker eninge服务，守护进程kunelet及负载均衡器kube-proxy.

每个Node节点都运行着以下一组关键进程
kubelet：负责对Pod对于的容器的创建、启停等任务
kube-proxy：实现Kubernetes Service的通信与负载均衡机制的重要组件
Docker Engine（Docker）：Docker引擎，负责本机容器的创建和管理工作
　　Node节点可以在运行期间动态增加到Kubernetes集群中，默认情况下，kubelet会想master注册自己，这也是Kubernetes推荐的Node管理方式，kubelet进程会定时向Master汇报自身情报，如操作系统、Docker版本、CPU和内存，以及有哪些Pod在运行等等，这样Master可以获知每个Node节点的资源使用情况，冰实现高效均衡的资源调度策略。、

• kubelet
  kubelet是Master在Node节点上的Agent，管理本机运行容器的生命周期，比如创建容器、Pod挂载数据卷、下载Secret、获取容器节点状态工作。kubelet将每个Pod转换成一组容器。
• kube-proxy
  在node节点上实现Pod网络代理，维护网络规则和四层负载均衡工作
• docker或rocket
  容器引擎，运行容器。

K8s专业术语

pod

pod是K8s的最小调度逻辑单元，pod可以理解为是容器的外壳,它为容器做了一层抽象的封装。pod内部主要是用来放容器的，pod的特点是可以将多个容器加入到同一个网络名称空间中，一个pod中可以包含多个容器，同一个pod中的不同容器可以共享存储卷。一个pod上无论是有一个容器还是有多个容器，一旦将此pod调度到某node上运行时，这一个pod内的所有容器只能运行在同一个node上。

运行于Node节点上，若干相关容器的组合。Pod内包含的容器运行在同一宿主机上，使用相同的网络命名空间、IP地址和端口，能够通过localhost进行通。Pod是Kurbernetes进行创建、调度和管理的最小单位，它提供了比容器更高层次的抽象，使得部署和管理更加灵活。一个Pod可以包含一个容器或者多个相关容器。

Pod其实有两种类型：普通Pod和静态Pod，后者比较特殊，它并不存在Kubernetes的etcd存储中，而是存放在某个具体的Node上的一个具体文件中，并且只在此Node上启动。普通Pod一旦被创建，就会被放入etcd存储中，随后会被Kubernetes Master调度到摸个具体的Node上进行绑定，随后该Pod被对应的Node上的kubelet进程实例化成一组相关的Docker容器冰启动起来，在。在默认情况下，当Pod里的某个容器停止时，Kubernetes会自动检测到这个问起并且重启这个Pod（重启Pod里的所有容器），如果Pod所在的Node宕机，则会将这个Node上的所有Pod重新调度到其他节点上。

node

node是k8s集群中的工作节点,负责运行由master指派的各种任务。而最核心的任务就是以pod形式运行容器。

node可以是任何形式的计算设备，只要此设备上能够有传统意义上的CPU、内存、存储空间,并且能装上k8s的集群代理程序，它都可以作为整个k8s集群一个成员。

标签选择器

当大量的pod运行在一个集群当中时，如何实现分类管理?比如想删除某一类pod，比如想让控制器去管理一部分pod，它怎么进行管理?如何挑选、检测出来这些pod呢?值得肯定的是，这么多的pod，我们不能通过pod的名称来识别容器，因为pod随时都会被创建和删除，当一个pod发生故障被删除后，重新生成的pod的名称与被删除的pod名称肯定是不一样的,只不过其内部运行的程序是一样的，所以我们不能靠pod的名称来识别。同时我们有可能要将一类pod归组，比如创建4个nginx的pod,期望使用一个控制器对其进行统一管理，删除一个控制器就把这4个pod都删了，控制器还要保证这4个pod都处于运行状态，缺—个要补一个，多一个要多杀一个，精确符合我们期望的4个pod才行。

为了能够实现pod识别，需要在pod之上附加一些元数据，类似dockerfle中的label标签的方式，比如在创建pod时为其附加一个名为app的key，然后将其值设为nginx，那么当我们在批量进行pod调度管理时，可以检查pod中是否有app这个key，且其值是否为nginx，通过此种方法来识别pod是否是我们想要控制的pod。

标签是在k8s上管理大规模pod资源并且能够分类识别和管理的一个非常重要的途径。

那么怎么从众多的pod中筛选出我们想要的pod呢?通过标签选择器组件我们可以实现这个功能标签选择器就是一种根据标签来过滤符合条件的资源对象的机制。

K8s基础概念

pod分类

1. 自助式pod

• 自我管理的pod，创建以后仍然需要提交给apiserver，由apiserver接收以后借助于调度器将其调度至指定的node节点，由node启动此pod
• 如果此pod出现故障,需要重启容器则由kubelet来完成
• 如果node节点故障了，那么此pod将会消失。其无法实现全局调度。所以不推荐使用此种pod

2. 控制器管理的pod

• 常见的pod控制器
  • ReplicationController（复制控制器）
    当启动一个pod时,这个pod如果不够用可以再启一个副本，而后由控制器来管理同一类pod的各种副本与对象。一旦副本少了就会自动增加。采取多退少补的规则，精确符合我们所定义的期望。
    支持滚动更新
  • ReplicaSet
    由一个名叫Deployment的声明式更新的控制器来管理
  • Deployment
    Deployment只能管理无状态的应用
  • StateFulSet
    有状态副本集，可以管理有状态的应用
  • DaemonSet
    如果需要在每个node上运行一个副本的时候可以用DaemonSet
  • Job
  • Cronjob
  • 以上每种控制器都是用来实现一种特定的应用管理的

核心组件

1. HPA

• Deployment还支持二级控制器
• HPA(HorizontalPodAutoscaler，水平pod自动伸缩控制器)
• 一般情况下我们可以确保一个node上有2个pod在运行，万一用户访问流量增加，2个pod不足以承载这么多访问量怎么办?此时我们就应该要增加pod资源，那么到底应该加几个?
  HPA控制器可自动监控pod、自动进行扩展。

2. service

• 假如有2个pod，pod有其生命周期，万一pod所在的节点宕机，那么此pod将应该要在其他的节点上重建，而重建完的pod与原来的pod已经不是同一个pod了，只是两者都是运行的同一个服务而已。且每个容器都有其IP地址，重建的pod中的容器其IP地址与之前的pod中容器的IP地址是不一样的，如此—来就会存在一个问题，客户端如何访问这些pod中的容器呢?
• 服务发现 （集贸市场例子：注册摊位、声明地址）
• pod是有生命周期的，一个pod随时都有可能离去，随时都有可能会有其他pod加进来，假如它们提供的是同一种服务，客户端是无法通过固定的手段来访问这些pod的，因为pod本身是不固定的，它们随时可能被替换掉,无论使用主机名还是IP地址，都随时会被替换掉。
• 为了尽可能的降低客户端与pod间协调的复杂度，k8s为每一组提供同类服务的pod和其客户端之间添加了一个中间层，这个中间层是固定的，这个中间层就叫service
• service只要不被删除，其地址与名称皆是固定的，当客户端需要在其配置文件中写上访问某个服务时，它不再需要自动发现，只需要在配置文件中写明service的名称即可，而这个service是个调度器，其不但能够提供一个稳定的访问入口，还可以做反向代理,当service接收到客户端的请求后，会将其代理到后端的pod之上，一旦pod宕机了会立即新建一个pod，这个新建的pod会立即被service关联上，作为service后端的可用pod之一
• 客户端程序访问服务都是通过IP+端口或者主机名+端口的方式来实现的。而service关联后端的pod不是靠它的IP和主机名，而是靠pod的标签选择器。只要创建的pod的label是统一的，无论P地址和主机如何改变，其都能被service所识别。如此一来，只要pod属于标签选择器，只要其在service的管理范围之内，则其就会被关联到service中，当这个动态的pod关联到service中之后，再进行动态的探测此pod的IP地址、端口，再将其作为自己后端可调度的可用服务器主机对象。因此，客户端的请求发送到service，然后由service代理到后端真实的pod中的容器进行响应。
• service不是一个程序，也不是一个组件，它只是一个iptables的dnat规则
• service作为k8s的对象,有其自身的名称，而service的名称相当于服务的名称，而这个名称可以被解析。

AddOne附件

1. dns pod

• 装完k8s后第一件事就需要在k8s集群上部署一个dns pod，以确保各service的名称能够被解析
• 可以动态改变，包括动态创建、动态删除、动态修改
• 比如把service的名称改了，dns pod会自动触发，将dns解析记录中的名称也给改掉；假如我们手动把service的ip地址给改了，改完以后会自动触发，将dns服务中的解析记录给改掉
• 如此一来，客户端去访问pod资源的时候可以直接访问service的名称，然后由集群中专用的dns服务来负责解析

2. 这种pod是k8s自身的服务就需要用到的pod，所以我们把它称为基础性的系统架构级的pod对象，而且它们也被称为集群附件

K8s网络模型

• 节点网络
• service集群网络
• pod网络
• k8s的三种网络模型分属于三个网段，由此延伸出来三个问题
  • 同一pod内的多个容器间如何通信？
    • lop网卡
  • 各pod之间如何通信？
    • 物理桥桥接，规模大的情况下会产生广播风暴（很少用这种方式）
    • Overlay Network，通过隧道的方式转发报文（基本上都会用这个方式）
  • pod与service之间如何通信？

Kubectl管理工具

kuberconfig配置文件

kubectl使用kubeconfig认证文件连接k8s集群，使用kubectl config指令生成kubeconfig文件。

kubeconfig连接k8s认证文件：

集群

apiVersion:v1
kind:Config
clusters:
- cluster:
   certificate-authority-data:
   server:https://192.168.31.61:6443
name:kubernetes

上下文

contexts:
- context:
  cluster:kubernetes
  user:kubernetes-admin
name:kubernetes-admin@kubernetes

当前上下文

currnet-context:kubernetes-admin@kubernetes

客户端认证

users:
- name:kubernetes
  user:
    client-certificate-data:
    client-key-data:

kubectl管理命令概述

类型	命令	概述
基础命令	create	通过文件名或标准输入创建资源
	expose	为Deployment，Pod创建Service
	run	在集群中运行一个特定的镜像
	set	在对象上设置特定的功能
	explain	文档参考资料
	get	显示一个或多个资源
	edit	使用系统编辑一个资源
	delete	通过文件名、标准输入、资源名称或标签选择器来删除资源
部署命令	rollout	管理Deployment，Daemonset资源的发布（例如状态、发布记录、回滚等）
	rolling-update	滚动升级，仅限ReplicationController
	scale	对Deployment、ReplicaSet、RC或Job资源扩容或收缩Pod数量
	autoscale	为Deploy，RS，RC配置自动伸缩规则（依赖metrics-server和hpa）
集群管理命令	certificate	修改证书资源
	cluster-info	显示集群信息
	top	查看资源利用率（依赖metrics-server）
	cordon	标记节点不可调度
	uncordon	标记节点可调度
	drain	驱逐节点上的应用，准备下线维护
	taint	修改节点taint标记

run

启动一个nginx pod

[root@master ~]# kubectl run nginx --image nginx
podinx created
[root@master ~]# kubectl get pods
NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          2m52s

[root@master ~]# kubectl get pods -o wide
NAME    READY   STATUS    RESTARTS   AGE     IP            NODE                NOMINATED NODE   READINESS GATES
nginx   1/1     Running   0          3m43s   10.244.2.11   node2.example.com   <none>           <none>

暴露端口号

[root@master ~]# kubectl run nginx --image nginx --port 80
podinx created

加标签

[root@master ~]# kubectl run nginx --image nginx --labels "app=nginx,env=prod"
podinx created

干跑模式（只是干跑一下，不会真的去跑）

[root@master ~]# kubectl run nginx --image nginx --dry-run server
W1219 20:00:28.790987 1379634 helpers.go:553] --dry-run is deprecated and can be replaced with --dry-run=client.
podinx created (dry run)
[root@master ~]# kubectl get pods
No resources found in default namespace.

describe

描述pod信息

[root@master ~]# kubectl describe pod nginx

Kubectl命令的使用

Kubectl命令入门

create

创建一个来源一个文件或标准输入的资源

[root@master ~]# kubectl create deployment b1 --image busybox
deployment.apps/b1 created

创建好后查看，发现b1状态是ContainerCreating，表示正在拉镜像，如果你的镜像早早拉下来了，那它就直接启动了

[root@master ~]# kubectl get pods
NAME                     READY   STATUS              RESTARTS   AGE
b1-68578fbb6c-gzhn2      0/1     ContainerCreating   0          10s

过了一会再查看b1，发现是CrashLoopBackOff，表示已经退掉了，退掉了并不代表没运行，它是运行了，运行之后退出了；因为busybox默认是打开/bin程序，而/bin一执行就退出了，跟容器里面一样的，一启动就退出了。

[root@master ~]# kubectl get pods
NAME                     READY   STATUS              RESTARTS   AGE
b1-68578fbb6c-gzhn2      0/1     CrashLoopBackOff    3          102s

再创建一个b2，在命令后面加上一个-- date，过一会查看状态，发现也挂掉了，因为-- date命令也是一样的一执行就没了

[root@master ~]# kubectl create deployment b2 --image busybox -- date
deployment.apps/b2 created
[root@master ~]# kubectl get pods
NAME                     READY   STATUS              RESTARTS   AGE
b1-68578fbb6c-gzhn2      0/1     CrashLoopBackOff    7          14m
b2-75d5678b7f-76zpc      0/1     CrashLoopBackOff    7          12m

再创建一个b3，还是在创建b1的命令后，加上-- sleep 6000，过了一会发现，运行起来了

[root@master ~]# kubectl create deployment b3 --image busybox -- sleep 6000
deployment.apps/b3 created
[root@master ~]# kubectl get pods
NAME                     READY   STATUS             RESTARTS   AGE
b1-68578fbb6c-gzhn2      0/1     CrashLoopBackOff   7          14m
b2-75d5678b7f-76zpc      0/1     CrashLoopBackOff   7          13m
b3-84d7f7d4bf-lbcnh      1/1     Running            0          47s

由此发现b3里面有任务，就可以运行的，而前面两个是没有任务的，或者说任务一执行就没了，就会挂掉

一下启动三个pods，用kubectl create <TYPE NAME> <POD NAME>--image <镜像> --replicas <启动pod的数量>，这里我们创建的是deployment无状态）类型的，replicas是用来设置要启动多少pods

[root@master ~]# kubectl create deployment myapp --image nginx --replicas 3
deployment.apps/myapp created
[root@master ~]# kubectl get pods
NAME                     READY   STATUS              RESTARTS   AGE
myapp-6d8d776547-chght   1/1     Running            0          4m1s
myapp-6d8d776547-dc7jb   1/1     Running            0          4m1s
myapp-6d8d776547-qb7pt   1/1     Running            0          4m1s
nginx-6799fc88d8-kwd2b   1/1     Running            0          24h

暴露端口号，用-- port <端口号>

[root@master ~]# kubectl create deployment myapp1 --image nginx --port 80
deployment.apps/myapp1 created
[root@master ~]# kubectl get pods
NAME                      READY   STATUS              RESTARTS   AGE
myapp-6d8d776547-chght    1/1     Running            0          8m18s
myapp-6d8d776547-dc7jb    1/1     Running            0          8m18s
myapp-6d8d776547-qb7pt    1/1     Running            0          8m18s
myapp1-677f4bf9bf-cf8ln   1/1     Running            0          102s

get

获取node节点、pod、service信息

列出所有的pod，在ps终端中打印出来

[root@master ~]# kubectl get pods

显示pods的详细信息

[root@master ~]# kubectl get pods -o wide

列出单replication的控制器的指定名称

[root@master ~]# kubectl get deployment myapp
NAME    READY   UP-TO-DATE   AVAILABLE   AGE
myapp   3/3     3            3           15m

一起列出replication的控制器和服务显示

[root@master ~]# kubectl get svc
[root@master ~]# kubectl get service

expose

暴露端口号，--target-port表示暴露目标端口号

创建一个服务，这个服务在它的80端口号连接它的时候用容器的8000，用外面的80访问容器里的8000

## 把80映射到8000，因为它的类型是ClusterIP，表示这个service只能在集群中能访问到；NodePort则表示是在真机上可以访问的
[root@master ~]# kubectl expose deployment myapp --port 80 --target-port 8000
service/myapp exposed
[root@master ~]# kubectl get svc
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
myapp        ClusterIP   10.110.171.169   <none>        80/TCP         3s
nginx        NodePort    10.111.4.86      <none>        80:30859/TCP   41h

delete

删除pod和service相同的名字，删除的时候指定你要删除的类型，你用哪个类型创建的就用哪个类型来删除

## 因为b1属于deployment类型的控制器，我们是通过控制器来管理的，而不是通过pod自身，而pod有两种类型，一种是自助式pod，一种是控制器管理的pod；我们现在用的是控制器管理的pod，所有要用控制器来管理它
[root@master ~]# kubectl delete deployment b1
deployment.apps "b1" deleted
[root@master ~]# kubectl get pods
No resources found in default namespace.

[root@master ~]# kubectl delete svc myapp
service "myapp" deleted 

[root@master ~]# kubectl delete pods nginx
pod "nginx" deleted
[root@master ~]# kubectl get pods
No resources found in def
ault namespace.

edit

使用默认编辑器编辑服务器上定义的资源

[root@master ~]# kubectl describe pod nginx
Name:         nginx
Namespace:    default
Priority:     0
Node:         node1.example.com/192.168.235.172
Start Time:   Mon, 20 Dec 2021 22:14:38 +0800
Labels:       app=nginx
   ································          
[root@master ~]# kubectl get pods
NAME                     READY   STATUS    RESTARTS   AGE
nginx                     1/1     Running   0          87s


...
  labels:
    app: test		//将原本的nginx改为test
  name: nginx
[root@master ~]# kubectl describe pod nginx
...
Labels:       app=test

scale

扩容或缩容 Deployment、ReplicaSet、Replication Controller或 Job 中Pod数量

将名为nginx中的pod副本数量设置为3

[root@master ~]# kubectl get deployment
NAME    READY   UP-TO-DATE   AVAILABLE   AGE
nginx   1/1     1            1           8m30s
[root@master ~]# kubectl scale --replicas 3 deployment/nginx
deployment.apps/nginx scaled
[root@master ~]# kubectl get deployment
NAME    READY   UP-TO-DATE   AVAILABLE   AGE
nginx   1/3     3            1           8m56s
[root@master ~]# kubectl get pod
NAME                     READY   STATUS    RESTARTS   AGE
nginx-6799fc88d8-5tsjt   1/1     Running   0          16s
nginx-6799fc88d8-dwrsh   1/1     Running   0          9m5s
nginx-6799fc88d8-sn82p   1/1     Running   0          15s

如果当前副本数为3，则将其扩展至5

[root@master ~]# kubectl scale --current-replicas 3 --replicas 5 deployment/nginx
deployment.apps/nginx scaled
[root@master ~]# kubectl get pod
NAME                     READY   STATUS              RESTARTS   AGE
nginx-6799fc88d8-5tsjt   1/1     Running             0          62s
nginx-6799fc88d8-dwrsh   1/1     Running             0          9m51s
nginx-6799fc88d8-jkmln   0/1     ContainerCreating   0          2s
nginx-6799fc88d8-qm5ld   0/1     ContainerCreating   0          2s
nginx-6799fc88d8-sn82p   1/1     Running             0          61s
[root@master ~]# kubectl get deployment
NAME    READY   UP-TO-DATE   AVAILABLE   AGE
nginx   4/5     5            4           9m58s
[root@master ~]# 

autoscale

自动扩展，给定一个范围，自动根据业务的访问量增加或减少

设定nginx这个deployment的副本数最少为1，最多为5

[root@master ~]# kubectl autoscale --min 1 --max 5 deployment/nginx
horizontalpodautoscaler.autoscaling/nginx autoscaled
[root@master ~]# kubectl get hpa
NAME    REFERENCE          TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
nginx   Deployment/nginx   <unknown>/80%   1         5         0          8s

cluster-info

显示标签为 kubernetes.io/cluster-service=true 的控制平面和服务的地址。要进一步调试和诊断集群问题，请使用“kubectl cluster-info dump”

[root@master ~]# kubectl cluster-info
Kubernetes control plane is running at https://192.168.235.179:6443
KubeDNS is running at https://192.168.235.179:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

describe

查看特定资源或资源组的详细信息

查看名为nginx 的pod的详细信息

[root@master ~]# kubectl describe pod nginx
Name:         nginx-6799fc88d8-5tsjt
Namespace:    default
Priority:     0
Node:         node1.example.com/192.168.235.172
Start Time:   Mon, 20 Dec 2021 22:23:28 +0800
Labels:       app=nginx
              pod-template-hash=6799fc88d8
Annotations:  <none>
Status:       Running
IP:           10.244.1.5
IPs:
  IP:           10.244.1.5
Controlled By:  ReplicaSet/nginx-6799fc88d8
Containers:
  nginx:
    Container ID:   docker://5a331ad8c751b41bfa7fd98f4f73e1c97cbc9f8aa76aada48f0be3fe22c10097
    Image:          nginx
    Image ID:       docker-pullable://nginx@sha256:9522864dd661dcadfd9958f9e0de192a1fdda2c162a35668ab6ac42b465f0603
    Port:           <none>
    Host Port:      <none>
    State:          Running
      Started:      Mon, 20 Dec 2021 22:23:37 +0800
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-n67dr (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True 
Volumes:
  default-token-n67dr:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-n67dr
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                 node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  8m9s  default-scheduler  Successfully assigned default/nginx-6799fc88d8-5tsjt to node1.example.com
  Normal  Pulling    8m8s  kubelet            Pulling image "nginx"
  Normal  Pulled     8m    kubelet            Successfully pulled image "nginx" in 7.583042375s
  Normal  Created    8m    kubelet            Created container nginx
  Normal  Started    8m    kubelet            Started container nginx

logs

输出pod或指定资源中容器的日志。如果pod中只有一个容器，则容器名是可选的

// 查看nginx的日志
[root@master ~]# kubectl logs deployment/nginx
Found 5 pods, using pod/nginx-6799fc88d8-dwrsh
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
/docker-entrypoint.sh: Configuration complete; ready for start up
2021/12/20 14:14:43 [notice] 1#1: using the "epoll" event method
2021/12/20 14:14:43 [notice] 1#1: nginx/1.21.4
2021/12/20 14:14:43 [notice] 1#1: built by gcc 10.2.1 20210110 (Debian 10.2.1-6) 
2021/12/20 14:14:43 [notice] 1#1: OS: Linux 4.18.0-257.el8.x86_64
2021/12/20 14:14:43 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 1048576:1048576
2021/12/20 14:14:43 [notice] 1#1: start worker processes
2021/12/20 14:14:43 [notice] 1#1: start worker process 32
2021/12/20 14:14:43 [notice] 1#1: start worker process 33

attach

连接到一个正在运行的容器

//获取正在运行中的pod nginx的输出，默认连接到pod中的第一个容器

[root@master ~]# kubectl attach nginx
Defaulting container name to nginx.
Use 'kubectl describe pod/nginx -n default' to see all of the containers in this pod.
If you don't see a command prompt, try pressing enter.

exec

在容器内执行命令

//默认在pod/nginx的第一个容器中运行date并打印输出
[root@master ~]# kubectl exec deployment/nginx date
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
Mon Dec 20 14:38:25 UTC 2021

port-forward

将一个或多个本地端口转发到pod

//将容器中的80端口随即映射到本机的端口

[root@master ~]# kubectl port-forward nginx-6799fc88d8-5tsjt :80
Forwarding from 127.0.0.1:46459 -> 80
Forwarding from [::1]:46459 -> 80

[root@master ~]# curl 127.0.0.1:46459
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
[root@master ~]#

cp

将文件和目录复制到容器或者从容器中拷贝

//将本地的anaconda-ks.cfg文件传输到pod/nginx的/tmp目录下
[root@master ~]# kubectl cp anaconda-ks.cfg nginx-6799fc88d8-5tsjt:/tmp
[root@master ~]# kubectl exec pod/nginx-6799fc88d8-5tsjt -- ls -l /tmp
total 4
-rw------- 1 root root 1252 Dec 20 14:48 anaconda-ks.cfg

label

更新（增加、修改或删除）资源上的 label（标签）。

• label 必须以字母或数字开头，可以使用字母、数字、连字符、点和下划线，最长63个字符。
• 如果–overwrite 为 true，则可以覆盖已有的 label，否则尝试覆盖 label 将会报错。
• 如果指定了–resource-version，则更新将使用此资源版本，否则将使用现有的资源版本。

//更改标签
[root@master ~]# kubectl describe deployment/nginx
Name:                   nginx
Namespace:              default
CreationTimestamp:      Mon, 20 Dec 2021 22:14:38 +0800
Labels:                 app=nginx
Annotations:            deployment.kubernetes.io/revision: 1
Selector:               app=nginx
Replicas:               5 desired | 5 updated | 5 total | 5 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=nginx
  Containers:
   nginx:
    Image:        nginx
    Port:         <none>
    Host Port:    <none>
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Progressing    True    NewReplicaSetAvailable
  Available      True    MinimumReplicasAvailable
OldReplicaSets:  <none>
NewReplicaSet:   nginx-6799fc88d8 (5/5 replicas created)
Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  37m   deployment-controller  Scaled up replica set nginx-6799fc88d8 to 1
  Normal  ScalingReplicaSet  29m   deployment-controller  Scaled up replica set nginx-6799fc88d8 to 3
  Normal  ScalingReplicaSet  28m   deployment-controller  Scaled up replica set nginx-6799fc88d8 to 5

//追加标签
[root@master ~]# kubectl label deployment/nginx user=yaya
deployment.apps/nginx labeled
[root@master ~]# kubectl describe deployment/nginx
Name:                   nginx
Namespace:              default
CreationTimestamp:      Mon, 20 Dec 2021 22:14:38 +0800
Labels:                 app=nginx
                        user=yaya

api-resources

在服务器上打印支持的 API 资源

//查看所有资源
[root@master ~]# kubectl api-resources
NAME                              SHORTNAMES   APIVERSION                             NAMESPACED   KIND
bindings                                       v1                                     true         Binding
componentstatuses                 cs           v1                                     false        ComponentStatus
configmaps                        cm           v1                                     true         ConfigMap

api-versions

在服务器上以’组/版本’的形式打印支持的api版本

[root@master ~]#  kubectl api-versions
admissionregistration.k8s.io/v1
admissionregistration.k8s.io/v1beta1
apiextensions.k8s.io/v1
apiextensions.k8s.io/v1beta1
apiregistration.k8s.io/v1
apiregistration.k8s.io/v1beta1
apps/v1
authentication.k8s.io/v1
authentication.k8s.io/v1beta1
authorization.k8s.io/v1
authorization.k8s.io/v1beta1
autoscaling/v1
autoscaling/v2beta1
autoscaling/v2beta2
batch/v1