文章目录

Kubernetes

容器技术的核心概念是容器、镜像、仓库，使用这三大基本要素可以轻松地完成应用的打包、分发工作，实现“一次开发，到处运行”。

在服务器集群里大规模实施的时候，却会发现容器技术的创新只是解决了运维部署工作中一个很小的问题。现实生产环境的复杂程度实在是太高了，除了最基本的安装，还会有各式各样的需求，比如服务发现、负载均衡、状态监控、健康检查、扩容缩容、应用迁移、高可用等等。

容器之上的管理、调度工作，就是这些年最流行的词汇：“容器编排”（Container Orchestration）。

Kubernetes 就是一个生产级别的容器编排平台和集群管理系统，不仅能够创建、调度容器，还能够监控、管理服务器，它凝聚了 Google 等大公司和开源社区的集体智慧，从而让中小型公司也可以具备轻松运维海量计算节点——也就是“云计算”的能力。

minikube

快速搭建 Kubernetes 环境的工具，在官网（https://kubernetes.io/zh/docs/tasks/tools/）上推荐的有两个：kind 和 minikube（“迷你”版本的 Kubernetes），它们都可以在本机上运行完整的 Kubernetes 环境。

搭建环境

curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube

root@yuping:/home/yuping# minikube version
minikube version: v1.28.0
commit: 986b1ebd987211ed16f8cc10aed7d2c42fc8392f

minikube 只能够搭建 Kubernetes 环境，要操作 Kubernetes，还需要另一个专门的客户端工具 kubectl 。

kubectl 的作用有点类似之前我们学习容器技术时候的工具“docker”，它也是一个命令行工具，作用也比较类似，同样是与 Kubernetes 后台服务通信，把我们的命令转发给 Kubernetes，实现容器和集群的管理功能。

kubectl 是一个与 Kubernetes、minikube 彼此独立的项目，所以不包含在 minikube 里，但 minikube 提供了安装它的简化方式，执行下面的这条命令：

minikube kubectl

在 minikube 环境里，会用到两个客户端：minikube 管理 Kubernetes 集群环境，kubectl 操作实际的 Kubernetes 功能，和 Docker 比起来有点复杂。

验证 minikube 环境

如果在 root 账号下执行需要--force，并切换到国内镜像，易于下载

minikube start --kubernetes-version=v1.23.3 --image-mirror-country='cn' --force

yuping@yuping:~$ minikube start --kubernetes-version=v1.23.3
😄  Ubuntu 22.04 上的 minikube v1.28.0
🆕  Kubernetes 1.25.3 is now available. If you would like to upgrade, specify: --kubernetes-version=v1.25.3
✨  根据现有的配置文件使用 docker 驱动程序
👍  Starting control plane node minikube in cluster minikube
🚜  Pulling base image ...
🏃  Updating the running docker "minikube" container ...
❗  This container is having trouble accessing https://k8s.gcr.io
💡  To pull new external images, you may need to configure a proxy: https://minikube.sigs.k8s.io/docs/reference/networking/proxy/
🐳  正在 Docker 20.10.20 中准备 Kubernetes v1.23.3…
🔎  Verifying Kubernetes components...
    ▪ Using image docker.io/kubernetesui/dashboard:v2.7.0
    ▪ Using image docker.io/kubernetesui/metrics-scraper:v1.0.8
    ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
💡  Some dashboard features require the metrics-server addon. To enable all features please run:

	minikube addons enable metrics-server	

🌟  Enabled addons: storage-provisioner, default-storageclass, dashboard
💡  kubectl not found. If you need it, try: 'minikube kubectl -- get pods -A'
🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default

yuping@yuping:~$ minikube status
minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

yuping@yuping:~$ minikube node list
minikube	192.168.49.2

也可以用 ssh 登录

yuping@yuping:~$ minikube ssh
docker@minikube:~$ 
docker@minikube:~$ uname -a
Linux minikube 5.15.0-58-generic #64-Ubuntu SMP Thu Jan 5 11:43:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
docker@minikube:~$ exit
logout
ssh: Process exited with status 127

yuping@yuping:~$ minikube kubectl -- version
Client Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.3", GitCommit:"816c97ab8cff8a1c72eccca1026f7820e93e0d25", GitTreeState:"clean", BuildDate:"2022-01-25T21:25:17Z", GoVersion:"go1.17.6", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.3", GitCommit:"816c97ab8cff8a1c72eccca1026f7820e93e0d25", GitTreeState:"clean", BuildDate:"2022-01-25T21:19:12Z", GoVersion:"go1.17.6", Compiler:"gc", Platform:"linux/amd64"}

虚拟机重启后，需要重新开启 minikube：minikube start --kubernetes-version=v1.23.3。

简化命令

原因：使用 minikube 自带的 kubectl 有一点形式上的限制，要在前面加上 minikube 的前缀，后面再有个 –

编辑 ~/.bashrc文件：

alias kubectl="minikube kubectl --"
source <(kubectl completion bash)

yuping@yuping:~$ source ~/.bashrc
yuping@yuping:~$ kubectl version --short
Client Version: v1.23.3
Server Version: v1.23.3

举例运行 Nginx 应用

在 Kubernetes 里运行一个 Nginx 应用，命令与 Docker 一样，也是run，不过形式上有点区别，需要用 --image 指定镜像，然后 Kubernetes 会自动拉取并运行：

yuping@yuping:~$ kubectl run ngx --image=nginx:alpine
pod/ngx created
yuping@yuping:~$ kubectl get pod
NAME   READY   STATUS              RESTARTS   AGE
ngx    0/1     ContainerCreating   0          22s
yuping@yuping:~$ kubectl get pod
NAME   READY   STATUS    RESTARTS   AGE
ngx    1/1     Running   0          47s

Pod，可以暂时把它理解成是“穿了马甲”的容器，查看 Pod 列表：kubectl get pod，效果类似 docker ps。可以看到在 Kubernetes 集群里就有了一个名字叫 ngx 的 Pod 正在运行，表示这个单节点 minikube 环境已经搭建成功。

Kubernetes工作机制

Kubernetes 能够在集群级别管理应用和服务器，可以认为是一种集群操作系统。它使用“控制面 / 数据面”的基本架构，Master 节点实现管理控制功能，Worker 节点运行具体业务。大致如下

yuping@yuping:~$ kubectl get node
NAME       STATUS   ROLES                  AGE    VERSION
minikube   Ready    control-plane,master   161m   v1.23.3

当前的 minikube 集群里只有一个 Master，这是因为 Master 和 Node 的划分不是绝对的。当集群的规模较小，工作负载较少的时候，Master 也可以承担 Node 的工作，就像搭建的 minikube 环境，它就只有一个节点，这个节点既是 Master 又是 Node。

Kubernetes 采用了现今流行的“控制面 / 数据面”架构，集群里的计算机被称为“节点”（Node），可以是实机也可以是虚机，少量的节点用作控制面来执行集群的管理维护工作，其他的大部分节点都被划归数据面，用来跑业务应用。

master node

Master 里有 4 个组件，分别是 apiserver、etcd、scheduler、controller-manager。

  • apiserver 是 Master 节点——同时也是整个 Kubernetes 系统的唯一入口，它对外公开了一系列的 RESTful API，并且加上了验证、授权等功能，所有其他组件都只能和它直接通信，可以说是 Kubernetes 里的联络员
  • etcd 是一个高可用的分布式 Key-Value 数据库，用来持久化存储系统里的各种资源对象和状态，相当于 Kubernetes 里的配置管理员。注意它只与 apiserver 有直接联系，也就是说任何其他组件想要读写 etcd 里的数据都必须经过 apiserver
  • scheduler 负责容器的编排工作，检查节点的资源状态，把 Pod 调度到最适合的节点上运行，相当于部署人员。因为节点状态和 Pod 信息都存储在 etcd 里，所以 scheduler 必须通过 apiserver 才能获得
  • controller-manager 负责维护容器和节点等资源的状态，实现故障检测、服务迁移、应用伸缩等功能，相当于监控运维人员。同样地，它也必须通过 apiserver 获得存储在 etcd 里的信息，才能够实现对资源的各种操作在这里插入图片描述4 个组件也都被容器化了，运行在集群的 Pod 里，用 kubectl 来查看它们的状态
yuping@yuping:~$ kubectl get pod -n kube-system
NAME                               READY   STATUS    RESTARTS       AGE
coredns-64897985d-snnsv            1/1     Running   0              176m
etcd-minikube                      1/1     Running   0              176m
kube-apiserver-minikube            1/1     Running   0              176m
kube-controller-manager-minikube   1/1     Running   0              176m
kube-proxy-rqjdt                   1/1     Running   0              176m
kube-scheduler-minikube            1/1     Running   0              176m
storage-provisioner                1/1     Running   1 (176m ago)   176m

worker node

Master 里的 apiserver、scheduler 等组件需要获取节点的各种信息才能够作出管理决策，这些信息来自 Node 里的 3 个组件了，分别是 kubelet、kube-proxy、container-runtime。

  • kubelet 是 Node 的代理，负责管理 Node 相关的绝大部分操作，Node 上只有它能够与 apiserver 通信，实现状态报告、命令下发、启停容器等功能，相当于是 Node 上的一个“小管家”
  • kube-proxy 的作用有点特别，它是 Node 的网络代理，只负责管理容器的网络通信，简单来说就是为 Pod 转发 TCP/UDP 数据包，相当于是专职的“小邮差”
  • container-runtime 是容器和镜像的实际使用者，在 kubelet 的指挥下创建容器，管理 Pod 的生命周期，是真正干活的“苦力”

只有 kube-proxy 被容器化了，而 kubelet 因为必须要管理整个节点，容器化会限制它的能力，所以它必须在 container-runtime 之外运行。

使用 minikube ssh 命令登录到节点后，可以用 docker ps 看到 kube-proxy：

yuping@yuping:~$ minikube ssh
Last login: Wed Jan 25 05:15:15 2023 from 192.168.49.1
docker@minikube:~$ 
docker@minikube:~$ docker ps |grep kube-proxy
db2216cd1354   9b7cc9982109           "/usr/local/bin/kube…"   3 hours ago         Up 3 hours                   k8s_kube-proxy_kube-proxy-rqjdt_kube-system_b657daa6-3240-4913-ae21-ab510b4857a3_0
cfc83d2306aa   k8s.gcr.io/pause:3.6   "/pause"                 3 hours ago         Up 3 hours                   k8s_POD_kube-proxy-rqjdt_kube-system_b657daa6-3240-4913-ae21-ab510b4857a3_0

#  而 kubelet 用 docker ps 是找不到的，需要用操作系统的 ps 命令：
docker@minikube:~$ docker ps |grep kubelet   
docker@minikube:~$ ps -ef|grep kubelet    
root        1695    1599  3 03:31 ?        00:06:17 kube-apiserver --advertise-address=192.168.49.2 --allow-privileged=true --authorization-mode=Node,RBAC --client-ca-file=/var/lib/minikube/certs/ca.crt --enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota --enable-bootstrap-token-auth=true --etcd-cafile=/var/lib/minikube/certs/etcd/ca.crt --etcd-certfile=/var/lib/minikube/certs/apiserver-etcd-client.crt --etcd-keyfile=/var/lib/minikube/certs/apiserver-etcd-client.key --etcd-servers=https://127.0.0.1:2379 --kubelet-client-certificate=/var/lib/minikube/certs/apiserver-kubelet-client.crt --kubelet-client-key=/var/lib/minikube/certs/apiserver-kubelet-client.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --proxy-client-cert-file=/var/lib/minikube/certs/front-proxy-client.crt --proxy-client-key-file=/var/lib/minikube/certs/front-proxy-client.key --requestheader-allowed-names=front-proxy-client --requestheader-client-ca-file=/var/lib/minikube/certs/front-proxy-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=8443 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/var/lib/minikube/certs/sa.pub --service-account-signing-key-file=/var/lib/minikube/certs/sa.key --service-cluster-ip-range=10.96.0.0/12 --tls-cert-file=/var/lib/minikube/certs/apiserver.crt --tls-private-key-file=/var/lib/minikube/certs/apiserver.key
root        1933       1  1 03:31 ?        00:03:34 /var/lib/minikube/binaries/v1.23.3/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --config=/var/lib/kubelet/config.yaml --container-runtime=docker --hostname-override=minikube --kubeconfig=/etc/kubernetes/kubelet.conf --node-ip=192.168.49.2

工作流程

Kubernetes 的大致工作流程：

  1. 每个 Node 上的 kubelet 会定期向 apiserver 上报节点状态，apiserver 再存到 etcd 里
  2. 每个 Node 上的 kube-proxy 实现了 TCP/UDP 反向代理，让容器对外提供稳定的服务
  3. scheduler 通过 apiserver 得到当前的节点状态，调度 Pod，然后 apiserver 下发命令给某个 Node 的 kubelet，kubelet 调用 container-runtime 启动容器
  4. controller-manager 也通过 apiserver 得到实时的节点状态，监控可能的异常情况，再使用相应的手段去调节恢复。

插件 Addon

查看插件列表

yuping@yuping:~$ minikube addons list
|-----------------------------|----------|--------------|--------------------------------|
|         ADDON NAME          | PROFILE  |    STATUS    |           MAINTAINER           |
|-----------------------------|----------|--------------|--------------------------------|
| ambassador                  | minikube | disabled     | 3rd party (Ambassador)         |
| auto-pause                  | minikube | disabled     | Google                         |
| cloud-spanner               | minikube | disabled     | Google                         |
| csi-hostpath-driver         | minikube | disabled     | Kubernetes                     |
| dashboard                   | minikube | disabled     | Kubernetes                     |
| default-storageclass        | minikube | enabled ✅   | Kubernetes                     |
| efk                         | minikube | disabled     | 3rd party (Elastic)            |
| freshpod                    | minikube | disabled     | Google                         |
| gcp-auth                    | minikube | disabled     | Google                         |

举例：

  • DNS，它在 Kubernetes 集群里实现了域名解析服务，能够让我们以域名而不是 IP 地址的方式来互相通信，是服务发现和负载均衡的基础。由于它对微服务、服务网格等架构至关重要，所以基本上是 Kubernetes 的必备插件。

  • Dashboard 就是仪表盘，为 Kubernetes 提供了一个图形化的操作界面，非常直观友好，虽然大多数 Kubernetes 工作都是使用命令行 kubectl，但有的时候在 Dashboard 上查看信息也是挺方便的。

只要在 minikube 环境里执行一条简单的命令，就可以自动用浏览器打开 Dashboard 页面，而且还支持中文：

uping@yuping:~$ minikube dashboard
🤔  正在验证 dashboard 运行情况 ...
🚀  Launching proxy ...
🤔  正在验证 proxy 运行状况 ...
🎉  Opening http://127.0.0.1:42781/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/ in your default browser...
Gtk-Message: 15:06:43.935: Not loading module "atk-bridge": The functionality is provided by GTK natively. Please try to not load it.

小结：

YAML

声明式与命令式

Docker 命令和 Dockerfile 就属于“命令式”，大多数编程语言也属于命令式，特点是交互性强，注重顺序和过程，必须“告诉”计算机每步该做什么，所有的步骤都列清楚。

“声明式”，在 Kubernetes 出现之前比较少见，它与“命令式”完全相反，不关心具体的过程，更注重结果。不需要“教”计算机该怎么做，只要告诉它一个目标状态，它自己就会想办法去完成任务，相比起来自动化、智能化程度更高。

yaml 语法

YAML 的官网（https://yaml.org/）

YAML 是 JSON 的超集，支持整数、浮点数、布尔、字符串、数组和对象等数据类型。任何合法的 JSON 文档也都是 YAML 文档。

  • 使用空白与缩进表示层次（有点类似 Python），可以不使用花括号和方括号
  • 可以使用 # 书写注释，比起 JSON 是很大的改进
  • 对象（字典）的格式与 JSON 基本相同，但 Key 不需要使用双引号
  • 数组（列表）是使用 - 开头的清单形式（有点类似 MarkDown）
  • 表示对象的 : 和表示数组的 - 后面都必须要有空格
  • 可以使用 — 在一个文件里分隔多个 YAML 对象，也就是说一个 yaml 中可定义多个 pod

API 对象

Kubernetes 归纳总结了 Google 多年的经验，在理论层面抽象出了很多个概念，用来描述系统的管理运维工作，这些概念就叫做“API 对象”，来源于 Kubernetes 组件 apiserver。

使用 kubectl api-resources 来查看当前 Kubernetes 版本支持的所有对象：

kubectl api-resources

加上一个参数 --v=9，它会显示出详细的命令执行过程，清楚地看到发出的 HTTP 请求，比如：

kubectl get pod --v=9

举例：ngx-pod.yml

运行 Nginx 的命令 kubectl run，和 Docker 一样是“命令式”的：

kubectl run ngx --image=nginx:alpine

改写成“声明式”的 YAML:

apiVersion: v1
kind: Pod
metadata:
  name: ngx-pod
  labels:
    env: demo
    owner: yuping
spec:
  containers:
  - image: nginx:alpine
    name: ngx
    ports:
    - containerPort: 80

因为 API 对象采用标准的 HTTP 协议，为了方便理解，借鉴一下 HTTP 的报文格式，把 API 对象的描述分成“header”和“body”两部分，“header”包含的是 API 对象的基本信息，有三个字段：apiVersion、kind、metadata。

  • apiVersion 表示操作这种资源的 API 版本号，由于 Kubernetes 的迭代速度很快，不同的版本创建的对象会有差异，为了区分这些版本就需要使用 apiVersion 这个字段，比如 v1、v1alpha1、v1beta1 等等
  • kind 表示资源对象的类型，这个应该很好理解，比如 Pod、Node、Job、Service 等等
  • metadata 这个字段顾名思义，表示的是资源的一些“元信息”，也就是用来标记对象，方便 Kubernetes 管理的一些信息

和 HTTP 协议一样，“header”里的 apiVersion、kind、metadata 这三个字段是任何对象都必须有的，而“body”部分则会与对象特定相关，每种对象会有不同的规格定义，在 YAML 里就表现为 spec 字段（即 specification），表示我们对对象的“期望状态”（desired status）。

使用 kubectl apply、kubectl delete，再加上参数 -f，创建或者删除对象：

kubectl apply -f ngx-pod.yml
kubectl delete -f ngx-pod.yml

编写yaml

查询 Kubernetes 的官方参考文档（https://kubernetes.io/docs/reference/kubernetes-api/）

技巧1

kubectl api-resources 显示出资源对象相应的 API 版本和类型，比如 Pod 的版本是“v1”，Ingress 的版本是“networking.k8s.io/v1”，照着它写。

技巧2，kubectl explain，它相当于是 Kubernetes 自带的 API 文档，会给出对象字段的详细说明。比如想要看 Pod 里的字段该怎么写，就可以这样：

kubectl explain pod
kubectl explain pod.metadata
kubectl explain pod.spec
kubectl explain pod.spec.containers

技巧3

kubectl 的两个特殊参数 –dry-run=client 和 -o yaml，前者是空运行，后者是生成 YAML 格式，结合起来使用就会让 kubectl 不会有实际的创建动作，而只生成 YAML 文件。例如：

yuping@yuping:~/kubernetes$ kubectl run ngx --image=nginx:alpine --dry-run=client -o yaml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: ngx
  name: ngx
spec:
  containers:
  - image: nginx:alpine
    name: ngx
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

或者

export out="--dry-run=client -o yaml"
kubectl run ngx --image=nginx:alpine $out

或者重定向到一个文件

kubectl run ngx --image=nginx:alpine --dry-run=client -o yaml  >> generate_file.yaml

Pod

概念

Pod 是一种包含了很多组件、成员的一种结构。

背景：多个容器需要协作时，相互的隔离性，对于某些相互作用，带有一定的不便。

为了解决这样多应用联合运行的问题，同时还要不破坏容器的隔离，就需要在容器外面再建立一个“收纳舱”，让多个容器既保持相对独立，又能够小范围共享网络、存储等资源，而且永远是“绑在一起”的状态。

在 Pod 的 YAML 里，“spec.containers”字段其实是一个数组，里面允许定义多个容器。

Pod 是对容器的“打包”，里面的容器是一个整体，一起调度、一起运行，不会出现分离的情况，且 Pod 属于 Kubernetes，可以在不触碰下层容器的情况下任意定制修改。

Kubernetes 让 Pod 去编排处理容器，把 Pod 作为应用调度部署的最小单位，基于 Pod 可以构建出更多更复杂的业务形态。

以 Pod 为中心的 Kubernetes 资源对象关系图：
在这里插入图片描述

YAML 描述 Pod

Pod 也是 API 对象，所以它也必然具有 apiVersion、kind、metadata、spec 这四个基本组成部分。

“apiVersion”和“kind”这两个字段很简单，对于 Pod 来说分别是固定的值 v1 和 Pod，而一般来说，“metadata”里应该有 name 和 labels 这两个字段。

举例

下面这段 YAML 代码就描述了一个简单的 Pod，名字是“busy-pod”，再附加上一些标签：

apiVersion: v1
kind: Pod
metadata:
  name: busy-pod
  labels:
    owner: chrono
    env: demo
    region: north
    tier: back

“spec”字段由于需要管理、维护 Pod 这个 Kubernetes 的基本调度单元，里面有非常多的关键信息。

里面的“containers”是一个数组，里面的每一个元素又是一个 container 对象，也就是容器。

编写“busy-pod”的 spec 部分，添加 env、command、args 等字段：

spec:
  containers:
  - image: busybox:latest
    name: busy
    imagePullPolicy: IfNotPresent
    env:
      - name: os
        value: "ubuntu"
      - name: debug
        value: "on"
    command:
      - /bin/echo
    args:
      - "$(os), $(debug)"

这里为 Pod 指定使用镜像 busybox:latest，拉取策略是 IfNotPresent ，然后定义了 os 和 debug 两个环境变量，启动命令是 /bin/echo，参数里输出刚才定义的环境变量。

YAML 在 spec.containers 字段里用“声明式”把容器的运行状态描述得非常清晰准确，要比 docker run 那长长的命令行要整洁的多，对人、对机器都非常友好。

kubectl 操作 Pod

前面提到，使用 kubectl apply、kubectl delete，再加上参数 -f，创建或者删除对象：

kubectl apply -f ngx-pod.yml
kubectl delete -f ngx-pod.yml

  1. 先启动 minikube

    minikube start --kubernetes-version=v1.23.3 --image-mirror-country='cn' --force

    minikube start --kubernetes-version=v1.23.3

  2. 生成一个 YAML 样板文件，用来创建 Pod

    kubectl run ngx --image=nginx:alpine --dry-run=client -o yaml  >> ngx-pod.yml

  3. 运行一个 pod

    kubectl apply -f ngx-pod.yml

    yuping@yuping:~/kubernetes$ kubectl apply -f ngx-pod.yml 
pod/ngx-pod created

  4. 查看 Pod 列表和运行状态

    kubectl get pod

    yuping@yuping:~/kubernetes$ kubectl get pod
NAME      READY   STATUS    RESTARTS   AGE
ngx-pod   1/1     Running   0          16s

  5. 删除 pod

    因为我们在 YAML 里定义了“name”字段，所以也可以在删除的时候直接指定名字来删除

    kubectl delete pod ngx-pod

    yuping@yuping:~/kubernetes$ kubectl delete pod ngx-pod
pod "ngx-pod" deleted

  6. 查看输出信息

    kubectl logs ngx-pod

    yuping@yuping:~/kubernetes$ kubectl logs ngx-pod
/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
2023/02/04 06:07:45 [notice] 1#1: using the "epoll" event method
2023/02/04 06:07:45 [notice] 1#1: nginx/1.23.3
2023/02/04 06:07:45 [notice] 1#1: built by gcc 12.2.1 20220924 (Alpine 12.2.1_git20220924-r4) 
2023/02/04 06:07:45 [notice] 1#1: OS: Linux 5.15.0-58-generic
2023/02/04 06:07:45 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 104857

  7. 检查详细信息

    kubectl describe pod ngx-pod

    yuping@yuping:~/kubernetes$ kubectl describe pod ngx-pod
Name:         ngx-pod
Namespace:    default
Priority:     0
Node:         minikube/192.168.49.2
Start Time:   Sat, 04 Feb 2023 14:07:44 +0800
Labels:       env=demo
              owner=chrono
Annotations:  <none>
Status:       Running
IP:           172.17.0.2
IPs:
  IP:  172.17.0.2
Containers:
  ngx:
    Container ID:   docker://10435597863f739e26616ab72b13249d8b6a043665df3bd96009892134604240
    Image:          nginx:alpine
    Image ID:       docker-pullable://nginx@sha256:659610aadb34b7967dea7686926fdcf08d588a71c5121edb094ce0e4cdbc45e6
    Port:           80/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Sat, 04 Feb 2023 14:07:45 +0800
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-xmm57 (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             True

  8. 拷贝文件

    kubectl 也提供与 docker 类似的 cp 和 exec 命令，kubectl cp 可以把本地文件拷贝进 Pod，kubectl exec 是进入 Pod 内部执行 Shell 命令，用法也差不多。

    kubectl cp testfile my-pod:/path

    yuping@yuping:~/kubernetes$ kubectl cp test_cp.txt ngx-pod:/tmp

    kubectl exec 的命令格式与 Docker 有一点小差异，需要在 Pod 后面加上 --，把 kubectl 的命令与 Shell 命令分隔开。

    kubectl exec -it my-pod -- sh

    yuping@yuping:~/kubernetes$ kubectl exec -it ngx-pod -- sh
/ # cat /tmp/test_cp.txt 
test cp command with kubectl.
# kubernetes # docker # 容器
Logo
Cloudpods

开源、云原生的融合云平台

更多推荐

面向未来的 IT 基础设施管理架构——融合云（Unified IaaS）

随着数字化时代的到来，IT系统已成为人类社会正常运转不可或缺的组成部分。不远的未来，智能制造，5G和人工智能等技术将成为推动生产力发展的重要引擎，人类社会将面临前所未有的全面彻底的数字化浪潮。IT基础设施作为IT系统运行的平台和载体，是实现数字化的基石。在这场数字化浪潮中，企业必须积极拥抱云计算技术，采用符合技术发展趋势、面向未来的IT基础构架，才能在未来的竞争中赢得先机。 一、云计算历经十余年

avatar Cloudpods

Cloudpods负载均衡的功能介绍

作者:周有松 今天的内容会从以下几个方面展开： 负载均衡产品简介。主要介绍负载均衡作为一个云上产品，它的功能模型是怎样的，日常使用中会遇到的业务词汇负载均衡的功能与典型应用场景。这部分主要结合业务词汇，对负载均衡服务中常见的一些功能选项进行介绍，并举例介绍一些典型的应用场景最后，我们做一下总结，讨论一下负载均衡产品相比传统方式的优点 一、产品简介​ 1. 以NGINX为例​ 提到负载均衡，我们以

avatar Cloudpods

使用Linux vfio将Nvidia GPU透传给QEMU虚拟机

Linux 上虚拟机 GPU 透传需要使用 vfio 的方式。主要是因为在 vfio 方式下对虚拟设备的权限和 DMA 隔离上做的更好。但是这么做也有个缺点，这个物理设备在主机和其他虚拟机都不能使用了。 qemu 直接使用物理设备本身命令行是很简单的，关键在于事先在主机上对系统、内核和物理设备的一些配置。 单纯从 qemu 的命令行来看，其实和普通虚拟机启动就差了最后那个-device的选项。这

avatar Cloudpods