命令行: kubectl命令行工具

优点: 90%以上的场景都可以满足对资源的增，删，查比较方便，对改不是很友好

缺点:命令比较冗长，复杂，难记声明式

声明式：K8S当中的yaml文件来实现资源管理

GUI：图形化工具的管理

kubectl命令的详解

查看  部署  查看pod的情况（详细信息和日志，发布和回滚）

Kubernetes kubectl 命令表 _ Kubernetes(K8S)中文文档_Kubernetes中文社区

查看k8s版本信息

kubectl version

查看K8S资源当中，所有资源对象的名称以及简写

kubectl api-resources

查看K8S集群信息

kubectl cluster-info

source <(kubectl completion bash)

查看MASTER节点的状态（基本信息查看）

kubectl get cs

查看默认命名空间default内的pod的信息

kubectl get pod

查看当前集群所有的命名空间

kubectl get ns

查看指定命名空间内的pod，需要加 -n+命名空间的名称

kubectl get pod -n kube-system

查看默认命名空间内pod的详细信息

kubectl get pod -o wide

查询节点信息和状态

kubectl get node

查看node节点的详细信息

kubectl get node -o wide

查看已经部署好的pod的详细信息

kubectl get pod

kubectl describe pod nginx-6799fc88d8-f9c8g

kubectl describe pod -n kube-system etcd-master01

查看pod输出的日志

kubectl logs nginx-6799fc88d8-f9c8g    一次性查看

kubectl logs -f nginx-6799fc88d8-f9c8g  动态查看

kubectl logs -f etcd-master0l -n kube-system

创建一个命名空间

kubectl create ns abc

查看命名空间

kubectl get ns

删除命名空间

kubectl delete ns abc

kubectl delete pod nginx-6799fc88d8-f9c8g -n 命名空间

kubectl get pod会发现nginx-6799fc88d8-f9c8g没有被删除（基于deployment进行部署的原因）

pod的部署：

deployment的部署pod

陈述式部署：命令行

声明式：yaml文件部署

滚动更新：不是一次性的把所有pod全部部署，而是一个个来。pod的更新时使用。逐步的引入新的pod，逐步的减少旧的pod

自我修复：如果有pod节点发生故障，deployment会自动更新新的pod来进行代替

回滚：如果更新有问题，deployment会提供还原点，可以手动的还原到未更新前的状态

扩容和缩容：deployment可以随时调整pod的数量，以适应流量的变化

上述的功能必须是基于deployment创建的服务才可以

daemonset不能通过命令行创建，只能通过yaml文件中定义这种创建方式

后台运行创建，在每个节点上都创建一个相同方式的、相同版本的容器运行的pod

一般都是依赖环境和重要组件，一般也不会对这些资源进行操作

如果基于deployment方式创建的pod，或者daemonset方式创建的pod，是由控制器创建的pod，使用delete是删不掉的，相当于重启pod

kubectl delete deployments.apps nginx-fmh -n abc

#基于deployment方式创建pod，一旦删除deployment，基于deployment创建的pod都会被删除。慎用

不是基于控制器创建的，会被直接删除

kubectl delete pod nginx-dn-6d6cd9c7c5-j7ffr --force --grace-period=0

grace-period:表示过度存活期。默认30秒。可以让pod优雅的结束容器内的进程，然后退出pod

grace-period=0表示立刻终止pod。必须要force

主要是用于结束卡在销毁状态的pod

对deployment创建的pod进行扩缩容

kubectl scale deployment nginx-fmh --replicas=3  扩容

kubectl scale deployment nginx-fmh --replicas=1  缩容

创建pod时并没有指定副本数，后续也可以对他的副本数进行修改

如何把服务的service进行发布？

kubectl get pod

service类型

kubectl get service/svc

kubectl delete svc nginx  删除service

kubectl get svc -n kube-system

TYPE类型：

ClusterIP  创建service的默认类型，提供一个集群内部的虚拟IP地址，这是service的默认类型。通过这个虚拟ip可以直接访问pod的资源，无法对外提供访问。

NodePort：会在每个node节点上开放相同的端口。外部可以通过node的本机IP+端口，访问pod资源。集群外部访问service资源的一种方式。四层代理的方式

nodeip：nodeport。随即指派，也可以指定（端口范围30000 --- 32767）

基于deployment创建的pod可以使用这种方式

kubectl deployment nginx --port=80 ==target-port=80 --name=nginx-service --type=NodePort

10.96.232.240 集群内部的ip地址，外部是不可以访问这个ip地址的.

80:对应的是内部的service的端口

32436: 和内部的service的80端口做映射

LoadBalancer: 如果service的类型设定为LoadBalancer映射地址(云平台提供LoadBalancer的地址) 这种用法仅用于公有云服务供应商在云台上设置的service的场景。外部来访问实现负载均衡。LoadBalancer这个是地址是要付费的。

创建好了service，指定类型为LoadBalancer，会给你提供一个地址来带代理pod内部的ip地址

ExternalName: DNS映射，给service分配一个域名，通过域名来访问后端pod资源。ExternalName的service类型不能提供负载均衡。必须要设置一个LoadBalancer的地址才可以实现

数字的大小决定了距离上次操作的远近，数字越大，就是你最近的一次操作

kubectl set image deployment nginxl nginx=nginx:1.15 --record

kubectl rollout history deployment nginxl