k8s基础命令及Linux上用Kubectl(k8s)部署Nginx

k8s基础命令及Linux上用Kubectl(k8s)部署Nginx

不懂K8s搭建的可以看我这篇文章 Linux上部署Kubectl(k8s)

1.k8s简介

1.1 Kubernetes 概念

在 k8s 上进行部署前，首先需要了解一个基本概念 Deployment

Deployment 译名为 部署。在k8s中，通过发布 Deployment，可以创建应用程序 (docker image) 的实例 (docker container)，这个实例会被包含在称为 Pod 的概念中，Pod 是 k8s 中最小可管理单元。

在 k8s 集群中发布 Deployment 后，Deployment 将指示 k8s 如何创建和更新应用程序的实例，master 节点将应用程序实例调度到集群中的具体的节点上。

创建应用程序实例后，Kubernetes Deployment Controller 会持续监控这些实例。如果运行实例的 worker 节点关机或被删除，则 Kubernetes Deployment Controller 将在群集中资源最优的另一个 worker 节点上重新创建一个新的实例。这提供了一种自我修复机制来解决机器故障或维护问题。

在容器编排之前的时代，各种安装脚本通常用于启动应用程序，但是不能够使应用程序从机器故障中恢复。通过创建应用程序实例并确保它们在集群节点中的运行实例个数，Kubernetes Deployment 提供了一种完全不同的方式来管理应用程序

1.1.1 Node

Kubernetes集群是指Kubernetes协调一个高可用计算机集群，每个计算机作为独立单元互相连接工作。

一个Kubernetes集群包含两种类型的资源：

• Master：负责管理整个集群。协调集群中的所有活动，例如调度应用、维护应用的所需状态、应用扩容以及推出新的更新。
• Node：用于托管正在运行的应用。可以是一个虚拟机或者物理机，它在Kubernetes集群中充当工作机器的角色，每个Node都有Kubelet，它管理Node而且是Node与Master通信的代理，Node还具有用于处理容器操作的工具，例如Docker或rkt。

1.1.2 Deployment

Deployment负责创建和更新应用程序的实例。创建Deployment后，Kubernetes Master 将应用程序实例调度到集群中的各个节点上。如果托管实例的节点关闭或被删除，Deployment控制器会将该实例替换为群集中另一个节点上的实例。这提供了一种自我修复机制来解决机器故障维护问题。

可以使用Kubernetes命令行界面Kubectl创建和管理Deployment。Kubectl使用Kubernetes API与集群进行交互。

1.1.3 Pod

Pod相当于逻辑主机的概念，负责托管应用实例。包括一个或多个应用程序容器（如 Docker），以及这些容器的一些共享资源（共享存储、网络、运行信息等）。

1.1.4 Service

Service是一个抽象层，它定义了一组Pod的逻辑集，并为这些Pod支持外部流量暴露、负载平衡和服务发现。

尽管每个Pod 都有一个唯一的IP地址，但是如果没有Service，这些IP不会暴露在群集外部。Service允许您的应用程序接收流量。Service也可以用在ServiceSpec标记type的方式暴露，type类型如下：

• ClusterIP（默认）：在集群的内部IP上公开Service。这种类型使得Service只能从集群内访问。
• NodePort：使用NAT在集群中每个选定Node的相同端口上公开Service。使用<NodeIP>:<NodePort>从集群外部访问Service。是ClusterIP的超集。
• LoadBalancer：在当前云中创建一个外部负载均衡器(如果支持的话)，并为Service分配一个固定的外部IP。是NodePort的超集。
• ExternalName：通过返回带有该名称的CNAME记录，使用任意名称（由spec中的externalName指定）公开Service。不使用代理。

1.2 Kubernetes 功能

• 服务发现和负载均衡

  Kubernetes 可以通过 DNS 名称或 IP 地址暴露容器的访问方式。并且可以在同组容器内分发负载以实现负载均衡

• 存储编排

  Kubernetes可以自动挂载指定的存储系统，例如 local stroage/nfs/云存储等

• 自动发布和回滚

  您可以在 Kubernetes 中声明您期望应用程序容器应该达到的状态，Kubernetes将以合适的速率调整容器的实际状态，并逐步达到最终期望的结果。请参考 声明式的配置

• 自愈

  Kubernetes提供如下自愈能力：

  • 重启已经停机的容器
  • 替换、kill 那些不满足自定义健康检查条件的容器
  • 在容器就绪之前，避免调用者发现该容器

• 密钥及配置管理

  Kubernetes可以存储和管理敏感信息（例如，密码、OAuth token、ssh密钥等）。您可以更新容器应用程序的密钥、配置等信息，而无需：

  • 重新构建容器的镜像
  • 在不合适的地方暴露密码信息

2.使用kubectl部署 nginx Deployment

1.创建文件 nginx-deployment.yaml，内容如下：

apiVersion: apps/v1	#与k8s集群版本有关，使用 kubectl api-versions 即可查看当前集群支持的版本
kind: Deployment	#该配置的类型，我们使用的是 Deployment
metadata:	        #译名为元数据，即 Deployment 的一些基本属性和信息
  name: nginx-deployment	#Deployment 的名称
  labels:	    #标签，可以灵活定位一个或多个资源，其中key和value均可自定义，可以定义多组，目前不需要理解
    app: nginx	#为该Deployment设置key为app，value为nginx的标签
spec:	        #这是关于该Deployment的描述，可以理解为你期待该Deployment在k8s中如何使用
  replicas: 1	#使用该Deployment创建一个应用程序实例
  selector:	    #标签选择器，与上面的标签共同作用，目前不需要理解
    matchLabels: #选择包含标签app:nginx的资源
      app: nginx
  template:	    #这是选择或创建的Pod的模板
    metadata:	#Pod的元数据
      labels:	#Pod的标签，上面的selector即选择包含标签app:nginx的Pod
        app: nginx
    spec:	    #期望Pod实现的功能（即在pod中部署）
      containers:	#生成container，与docker中的container是同一种
      - name: nginx	#container的名称
        image: nginx:1.7.9	#使用镜像nginx:1.7.9创建contain

2.应用 YAML 文件

kubectl apply -f nginx-deployment.yaml

3.查看部署结果

# 查看 Deployment
kubectl get deployments

# 查看 Pod
kubectl get pods

可分别查看到一个名为 nginx-deployment 的 Deployment 和一个名为 nginx-deployment-xxxxxxx 的 Pod

3.发布应用程序 Kubernetes Service（服务）

3.1概述

事实上，Pod（容器组）有自己的 生命周期 (opens new window)。当 worker node（节点）故障时，节点上运行的 Pod（容器组）也会消失。然后，Deployment (opens new window)可以通过创建新的 Pod（容器组）来动态地将群集调整回原来的状态，以使应用程序保持运行。

举个例子，假设有一个图像处理后端程序，具有 3 个运行时副本。这 3 个副本是可以替换的（无状态应用），即使 Pod（容器组）消失并被重新创建，或者副本数由 3 增加到 5，前端系统也无需关注后端副本的变化。由于 Kubernetes 集群中每个 Pod（容器组）都有一个唯一的 IP 地址（即使是同一个 Node 上的不同 Pod），我们需要一种机制，为前端系统屏蔽后端系统的 Pod（容器组）在销毁、创建过程中所带来的 IP 地址的变化。

Kubernetes 中的 Service（服务） 提供了这样的一个抽象层，它选择具备某些特征的 Pod（容器组）并为它们定义一个访问方式。Service（服务）使 Pod（容器组）之间的相互依赖解耦（原本从一个 Pod 中访问另外一个 Pod，需要知道对方的 IP 地址）。一个 Service（服务）选定哪些 Pod（容器组） 通常由 LabelSelector(标签选择器) 来决定。

在创建Service的时候，通过设置配置文件中的 spec.type 字段的值，可以以不同方式向外部暴露应用程序：

• ClusterIP（默认）

  在群集中的内部IP上公布服务，这种方式的 Service（服务）只在集群内部可以访问到

• NodePort

  使用 NAT 在集群中每个的同一端口上公布服务。这种方式下，可以通过访问集群中任意节点+端口号的方式访问服务 <NodeIP>:<NodePort>。此时 ClusterIP 的访问方式仍然可用。

• LoadBalancer

  在云环境中（需要云供应商可以支持）创建一个集群外部的负载均衡器，并为使用该负载均衡器的 IP 地址作为服务的访问地址。此时 ClusterIP 和 NodePort 的访问方式仍然可用。

Service是一个抽象层，它通过 LabelSelector 选择了一组 Pod（容器组），把这些 Pod 的指定端口公布到到集群外部，并支持负载均衡和服务发现。

• 公布 Pod 的端口以使其可访问
• 在多个 Pod 间实现负载均衡
• 使用 Label 和 LabelSelector

3.2 服务和标签

下图中有两个服务Service A(黄色虚线)和Service B(蓝色虚线) Service A 将请求转发到 IP 为 10.10.10.1 的Pod上， Service B 将请求转发到 IP 为 10.10.10.2、10.10.10.3、10.10.10.4 的Pod上。

Service 将外部请求路由到一组 Pod 中，它提供了一个抽象层，使得 Kubernetes 可以在不影响服务调用者的情况下，动态调度容器组（在容器组失效后重新创建容器组，增加或者减少同一个 Deployment 对应容器组的数量等）。

Service使用 Labels、LabelSelector(标签和选择器) (opens new window)匹配一组 Pod。Labels（标签）是附加到 Kubernetes 对象的键/值对，其用途有多种：

• 将 Kubernetes 对象（Node、Deployment、Pod、Service等）指派用于开发环境、测试环境或生产环境
• 嵌入版本标签，使用标签区别不同应用软件版本
• 使用标签对 Kubernetes 对象进行分类

下图体现了 Labels（标签）和 LabelSelector（标签选择器）之间的关联关系

• Deployment B 含有 LabelSelector 为 app=B 通过此方式声明含有 app=B 标签的 Pod 与之关联
• 通过 Deployment B 创建的 Pod 包含标签为 app=B
• Service B 通过标签选择器 app=B 选择可以路由的 Pod

Labels（标签）可以在创建 Kubernetes 对象时附加上去，也可以在创建之后再附加上去。任何时候都可以修改一个 Kubernetes 对象的 Labels（标签）

3.3 使用Kubectl创建

创建文件 nginx-service.yaml

vim nginx-service.yaml

文件内容如下：

apiVersion: v1
kind: Service
metadata:
  name: nginx-service	#Service 的名称
  labels:     	#Service 自己的标签
    app: nginx	#为该 Service 设置 key 为 app，value 为 nginx 的标签
spec:	    #这是关于该 Service 的定义，描述了 Service 如何选择 Pod，如何被访问
  selector:	    #标签选择器
    app: nginx	#选择包含标签 app:nginx 的 Pod
  ports:
  - name: nginx-port	#端口的名字
    protocol: TCP	    #协议类型 TCP/UDP
    port: 80	        #集群内的其他容器组可通过 80 端口访问 Service
    nodePort: 32600   #通过任意节点的 32600 端口访问 Service
    targetPort: 80	#将请求转发到匹配 Pod 的 80 端口
  type: NodePort	#Serive的类型，ClusterIP/NodePort/LoaderBalancer

执行命令

kubectl apply -f nginx-service.yaml

检查执行结果

kubectl get services -o wide

访问服务

curl <任意节点的 IP>:32600

http://192.168.1.28:32600/

http://192.168.1.119:32600/

http://192.168.1.183:32600/

ps:如果您的集群在云上，您可能通过云服务商的安全组开放 32600 端口的访问

4.Kubernetes Pods/Nodes

在 部署第一个应用程序 中创建 Deployment 后，k8s创建了一个 Pod（容器组） 来放置应用程序实例（container 容器）。

4.1 Pods概述(相当于一个或多个容器)

Pod 容器组 是一个k8s中一个抽象的概念，用于存放一组 container（可包含一个或多个 container 容器，即图上正方体)，以及这些 container （容器）的一些共享资源。这些资源包括：

• 共享存储，称为卷(Volumes)，即图上紫色圆柱
• 网络，每个 Pod（容器组）在集群中有个唯一的 IP，pod（容器组）中的 container（容器）共享该IP地址
• container（容器）的基本信息，例如容器的镜像版本，对外暴露的端口等

Pod（容器组）是 k8s 集群上的最基本的单元。当我们在 k8s 上创建 Deployment 时，会在集群上创建包含容器的 Pod (而不是直接创建容器)。每个Pod都与运行它的 worker 节点（Node）绑定，并保持在那里直到终止或被删除。如果节点（Node）发生故障，则会在群集中的其他可用节点（Node）上运行相同的 Pod（从同样的镜像创建 Container，使用同样的配置，IP 地址不同，Pod 名字不同）。

重要：

• Pod 是一组容器（可包含一个或多个应用程序容器），以及共享存储（卷 Volumes）、IP 地址和有关如何运行容器的信息。
• 如果多个容器紧密耦合并且需要共享磁盘等资源，则他们应该被部署在同一个Pod（容器组）中。

4.2Node（节点）

下图显示一个 Node（节点）上含有4个 Pod（容器组）

Pod（容器组）总是在 Node（节点） 上运行。Node（节点）是 kubernetes 集群中的计算机，可以是虚拟机或物理机。每个 Node（节点）都由 master 管理。一个 Node（节点）可以有多个Pod（容器组），kubernetes master 会根据每个 Node（节点）上可用资源的情况，自动调度 Pod（容器组）到最佳的 Node（节点）上。

每个 Kubernetes Node（节点）至少运行：

• Kubelet，负责 master 节点和 worker 节点之间通信的进程；管理 Pod（容器组）和 Pod（容器组）内运行的 Container（容器）。
• 容器运行环境（如Docker）负责下载镜像、创建和运行容器等。

4.3 kubectl基础用法

4.3.1 get操作

# kubectl get 资源类型

#获取类型为Deployment的资源列表
kubectl get deployments

 # 列出当前NS中所有service资源
kubectl get services  

# 查询所有pod信息
kubectl get pods

# 更多信息
kubectl get pods -o wide


# 查看所有名称空间的 Deployment
kubectl get deployments -A
kubectl get deployments --all-namespaces

# 查看 kube-system 名称空间的 Deployment
kubectl get deployments -n kube-system


# JSON格式显示Pod的完整信息
kubectl get pod pod名字  --output json

# YAML方式显示Pod的完整信息
kubectl get pod pod名字  --output yaml

#查看 RC 和 service 列表， -o wide 查看详细信息
 kubectl get svc -o wide

#获取类型为Node的资源列表
kubectl get nodes


# JSON格式显示Pod的完整信息
kubectl get pod pod名字  --output json

# YAML方式显示Pod的完整信息
kubectl get pod pod名字  --output yaml

4.3.2 delete操作

# 暴力删除node（操作需谨慎）
kubectl delete node node_xxx

#删除deployment
kubectl delete deployment  deployment名字

#删除node
kubectl delete node  node名字

#用create创建的pod 删除
kubectl delete -f pod_xxx.yaml

#删除svc网络
 kubectl delete svc svc网络名称
 
 # 删除所有pod O(∩_∩)O
kubectl delete pod --all

4.3.3 scale（进行副本的扩容）操作

# 设置副本数量，增加到3个  xxx是指deployments名字

kubectl scale deployments/xxx --replicas=3

4.3.4 创建资源操作

## 使用 apply 命令通过文件创建资源
kubectl apply -f xxx.yaml 

#这个也可以 创建pod，定义号pod_xxx.yaml 不过一般用apply好

kubectl create -f pod_xxx.yaml 

4.3.5 cp操作（文件传输）

# Usage:

kubectl cp <file-spec-src> <file-spec-dest> [options]

# Examples:  

kubectl cp /tmp/foo_dir pod名称:/tmp/bar_dir                 # 拷贝宿主机本地文件夹到pod
kubectl cp 空间名称/pod名称:/tmp/foo /tmp/bar        # 指定namespace的拷贝pod文件到宿主机本地目录

4.3.6 describe操作

显示有关资源的详细信息

# kubectl describe 资源类型 资源名称

#查看名称为nginx-XXXXXX的Pod的信息
kubectl describe pod nginx-XXXXXX	

#查看名称为nginx的Deployment的信息
kubectl describe deployment nginx	

# 查看单个pod状态和生命周期
kubectl describe pod pod名字

#查看名称为nginx-service的
 kubectl describe svc nginx-service
  

4.3.7 replace操作

# 更新pod
kubectl replace -f pod_xxx.yaml

# 重建pod，Pod的很多属性没办法修改，比如容器镜像，这时候可以采用--force参数
kubectl replace --force -f pod_xxx.yaml

4.3.8 log操作

# Usage:

 kubectl logs [-f] [-p] (POD | TYPE/NAME) [-c CONTAINER] [options]

# Examples: 

kubectl logs my-pod                              

# 输出一个单容器pod my-pod的日志到标准输出

kubectl logs nginx-78f5d695bd-czm8z -c nginx     

# 输出多容器pod中的某个nginx容器的日志

kubectl logs -l app=nginx                        

# 输出所有包含app-nginx标签的pod日志

kubectl logs -f my-pod                           

# 加上-f参数跟踪日志，类似tail -f

kubectl logs my-pod  -p                          

# 输出该pod的上一个退出的容器实例日志。在pod容器异常退出时很有用

kubectl logs my-pod  --since-time=2018-11-01T15:00:00Z

# 指定时间戳输出日志            

kubectl logs my-pod  --since=1h 

# 指定时间段输出日志，单位s/m/h

# kubectl logs Pod名称

#查看名称为nginx-pod-XXXXXXX的Pod内的容器打印的日志
#本案例中的 nginx-pod 没有输出日志，所以您看到的结果是空的
kubectl logs -f nginx-pod-XXXXXXX
  

例如：

 kubectl logs -f nginx-deployment-7c479fcb56-d44nl

4.3.9 exec操作（进入容器组）

# Usage:

kubectl exec POD [-c CONTAINER] -- COMMAND [args...] [options]

# Examples:

kubectl exec my-pod ls                         # 对my-pod执行ls命令
kubectl exec -t -i nginx-78f5d695bd-czm8z bash # 进入pod的shell，并打开伪终端和标准输入

kubectl exec - 在pod中的容器环境内执行命令(和命令docker exec 类似)

# kubectl exec Pod名称 操作命令

# 在名称为nginx-pod-xxxxxx的Pod中运行bash
kubectl exec -it nginx-pod-xxxxxx /bin/bas

例如：kubectl exec -it nginx-deployment-7c479fcb56-d44nl /bin/bash

4.3.10 svc操作

查看 RC 和 service 列表， -o wide 查看详细信息

 kubectl get svc -o wide

删除svc网络

 kubectl delete svc nginx-service-nodeport

4.3.11 run 命令

# 示例，运行一个名称为nginx，标签为app=example，镜像为nginx:1.10 端口为80

标签的作用在于后面申请服务端口的时候可以对应

kubectl run nginx  --labels="app=nginx" --image=nginx:1.10 --port=80

ps：这里建议还是用yaml配置文件去拉取镜像，因为可以把容器的数据映射到宿主机。

4.3.12 set 命令

# 更新镜像 
kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1

# 将deployment的nginx容器cpu限制为“200m”，将内存设置为“512Mi”
$ kubectl set resources deployment nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi

# 删除nginx中容器的计算资源值
$ kubectl set resources deployment nginx --limits=cpu=0,memory=0 --requests=cpu=0,memory=0

4.3.13 其他操作

# 暂停节点
kubectl cordon node_xxx

# 恢复节点
kubectl uncordon node_xxx

# 温和的驱除节点(操作需谨慎)
kubectl drain node_xxx

# 查看默认命名空间 pod 资源（cpu/内存）使用情况，并按照 cpu 倒序排序
kubectl top pod --sort-by cpu -n default

# 查看默认命名空间 pod 资源（cpu/内存）使用情况，并按照内存倒序排序
kubectl top pod --sort-by memory -n default

#查看过程及结果
watch kubectl get pods -l app=nginx


#创建命名空间
kubectl create namespace 空间名字

#删除命名空间 
kubectl delete ns 空间名字

#查看命名空间
kubectl get namespace


#切换到指定命名空间下,不然的话每次执行操作都要加-n namespace名字
kubectl config set-context --current --namespace=namespace名字

个人搭建项目代码地址：
https://github.com/hongjiatao/spring-boot-anyDemo

欢迎收藏点赞三连。谢谢！有问题可以留言博主会24小时内无偿回复。