matlab中cricshift,破剑七式：OpenShift4故障诊断

分享OCP4中常用的7个故障诊断的七招剑法。

1.查看节点和pod的真实CPU利用率：

oc adm top node：

显示每个节点的当前CPU和内存使用情况。这些是实际使用数量，不是OpenShift调度程序认为是节点的可用和已使用容量的资源请求。

root@lb.weixinyucluster ~]# oc adm top pods -n myapp

NAME              CPU(cores)   MEMORY(bytes)

jenkins-1-gb2hj   21m          527Mi

myapp-1-sd8ls     39m          433Mi

2.显示OpenShift节点的日志

OCP的理念是：RHCOS是不可变基础架构，因此不要频繁直接ssh访问OCP的node，而且也很麻烦，尽量通过OCP集群角度去运维和管理OCP的节点。

红帽企业版Linux CoreOS中的大多数系统服务都是作为容器运行的。主要的例外是CRI-O容器引擎和Kubelet，它们是Systemd单元。要查看这些日志，请使用oc adm node-logs命令，如以下示例，我们查看master-1节点上的crio的日志：

[root@lb.weixinyucluster ~]#  oc adm node-logs -u crio master-1

我们查看master-1节点上的crio的日志：

#oc adm node-logs -u kubelet master-1

如果想查看节点所有的日志：

oc adm node-logs master-1

3.在OpenShift节点上打开Shell提示符

oc debug node命令提供了一种在群集的任何节点中打开Shell提示符的方法。该提示来自一个专用工具容器，该容器将节点根文件系统安装在/host文件夹中，并允许您检查节点中的所有文件。

要在oc调试节点会话中直接从节点运行本地命令，必须在/host文件夹中启动chroot shell。然后，您可以检查节点的本地文件系统，其systemd服务的状态，并执行其他需要SSH会话的任务。

例如我们查看master-1上crio进程状态：

[root@lb.weixinyucluster ~]# oc debug node/master-1

Starting pod/master-1-debug ...

To use host binaries, run `chroot /host`

cPod IP: 192.168.91.11

If you don't see a command prompt, try pressing enter.

sh-4.2# chroot /host (这条命令必须执行)

sh-4.4# systemctl status crio

4.对容器进行故障排除

查看OCP节点上容器的状态

[root@lb.weixinyucluster ~]# oc debug node/master-1

Starting pod/master-1-debug ...

To use host binaries, run `chroot /host`

Pod IP: 192.168.91.11

If you don't see a command prompt, try pressing enter.

sh-4.2# chroot /host

sh-4.4# crictl ps

5.检查pod是否可以正常部署和运行

从deployments中创建一个pod，但以root用户身份运行，从而证明该部署引用了一个容器映像，该容器映像并非旨在在OpenShift的默认安全策略下运行：

[root@lb.weixinyucluster ~]# oc debug deployment/migrator -n openshift-kube-storage-version-migrator  --as-root

Starting pod/migrator-debug, command was: migrator --alsologtostderr --v=2

Pod IP: 10.128.2.16

If you don't see a command prompt, try pressing enter.

sh-4.2# ls

bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

如果pod不能正常运行，可以就可以看相关的日志。

6.更改正在运行的容器

尽管在停止容器时会放弃对本地容器文件系统的任何更改，但是有时可以方便地将文件上传到正在运行的容器中。在开发过程中使用动态脚本语言的例子就是。通过能够修改容器中的代码，可以在重建映像之前修改应用程序以测试更改。

除了将文件上传到正在运行的容器中之外，您可能还希望能够下载文件。在开发过程中，这些文件可能是应用程序创建的数据文件或日志文件。

登录pod：

oc rsh my-pod-name

将本地文件复制到Pod内的某个位置。您还可以反转参数并将文件从Pod内部复制到本地文件系统。

oc cp/local/pathmy-pod-name:/container/path

oc rsync命令以一次复制多个文件。

oc rsync :/remote/dir/filename ./local/dir

创建从本地端口到Pod本地端口的TCP隧道。只要您保持oc端口转发运行，隧道就可以运行。这使您可以通过网络访问Pod，而无需通过路由公开它。因为隧道始于您的本地主机，所以其他计算机无法访问它。

oc port-forward my-pod-name local-port:remote-port

我们查看几个具体的示例：

在OCP中创建一个应用，用于测试:

#oc new-app openshiftkatacoda/blog-django-py --name blog

登录pod查看文件，下图标红是sql数据文件，我们后边把这个文件从容器下载出来：

要将文件从容器复制到本地计算机，可以使用oc rsync命令。

将单个文件从容器复制到本地计算机：

$ oc rsync $POD:/opt/app-root/src/db.sqlite3 .

要将文件从本地计算机复制到容器，使用oc rsync命令。，命令的形式为：

oc rsync ./local/dir :/remote/dir

与从容器复制到本地计算机不同，没有用于复制单个文件的形式。要仅复制选定的文件，您将需要使用--exclude和--include选项来过滤从指定目录复制的内容。

为了说明复制单个文件的过程，请考虑以下情况：您已经部署了一个网站并且没有包含robots.txt文件，但是需要快速停止正在抓取您的网站的Web robots文件。

首先创建文件：echo "This is WeiXinyu testing" >robots.txt

将文件传入容器：

oc rsync . $POD:/opt/app-root/src/htdocs --exclude=* --include=robots.txt --no-perms

如前所述，不可能复制单个文件，因此我们指示应复制当前目录，但是使用--exclude = *选项首先要指出执行复制时应忽略所有文件。然后，通过使用--include = robots.txt文件，仅对robots.txt文件覆盖该模式，确保复制了robots.txt文件。

将文件复制到容器时，要求存在将文件复制到的目录，并且该目录对于运行该容器的用户或组是可写的。在建立镜像的过程中，应设置目录和文件的权限。

在上面的命令中，也使用--no-perms选项，因为尽管容器中的目标目录可以由运行容器的组写入，但由该容器运行的用户拥有。这意味着尽管可以将文件添加到目录中，但是不能更改现有目录的权限。--no-perms选项告诉oc rsync不要尝试更新权限，以免失败并返回错误。

确认文件上传成功：

上文我们部署的pod是一个web应用，因此通过curl可以访问，从而实现我在文件中注入的内容：

curl http://blog-myproject.2886795294-80-host04nc.environments.katacoda.com/robots.txt

如果要复制一个完整的目录而不是复制一个文件，请不要使用--include和--exclude选项。要将当前目录的完整内容复制到容器中的htdocs目录，请运行：

oc rsync . $POD:/opt/app-root/src/htdocs --no-perms

除了可以选择手动上传或下载文件外，还可以将oc rsync命令设置为在本地计算机和容器之间执行文件的实时同步。也就是说，将监视本地计算机的文件系统是否有文件更改。文件更改后，更改后的文件将自动复制到容器中。如果需要，也可以以相反的方向运行相同的过程，将容器中所做的更改自动复制回本地计算机。

在应用程序开发过程中，将更改从本地计算机自动复制到容器中可能有用的一个示例。

对于脚本编程语言(例如PHP，Python或Ruby)，不需要单独的编译阶段，前提是可以在不导致容器退出的情况下手动重启Web服务器，或者如果Web服务器始终重新加载已修改的代码文件，您可以使用OpenShift内部运行的应用程序进行实时代码开发。

为了演示此功能，请为您已经部署的Web应用程序克隆Git存储库。

git clone https://github.com/openshift-katacoda/blog-django-py

现在运行以下命令，以使oc rsync执行代码的实时同步，将所有更改从blog-django-py目录复制到容器。

oc rsync blog-django-py/. $POD:/opt/app-root/src --no-perms --watch &

最初运行oc rsync命令时，您会看到它复制了文件，因此本地和远程目录是同步的。现在，对本地文件所做的任何更改都将自动复制到远程目录中。

在进行更改之前，请使用以下网址在单独的浏览器窗口中打开已部署的Web应用程序：

http://blog-myproject.2886795294-80-host04nc.environments.katacoda.com/

您应该看到网站标题横幅的颜色是红色。

让我们通过运行以下命令来更改横幅颜色：

echo "BLOG_BANNER_COLOR = 'blue'" >> blog-django-py/blog/context_processors.py

这是因为对于Python，任何代码更改都由正在运行的进程缓存，并且有必要重新启动Web服务器应用程序进程。

对于此部署，使用了WSGI服务器mod_wsgi-express。要触发Web服务器应用程序进程的重新启动，请运行：

oc rsh $POD kill -HUP 1

7.对OpenShift CLI命令进行故障排除

有时，您无法理解oc命令为何失败，并且需要对它的低级操作进行故障排除以找到原因。也许您需要了解oc命令的特定调用在后台执行的操作，所以您可以使用发出OpenShift和Kubernetes API请求的自动化工具(例如，使用k8s模块的Ansible Playbooks)来复制行为。

--loglevel级别选项显示从级别6开始的OpenShift API请求。随着级别的增加，最多增加10个，有关这些请求的更多信息，例如它们的HTTP请求标头和响应主体。级别10还包括一个curl命令，用于复制每个请求。

您可以在任何项目中尝试这两个命令，然后比较它们的输出。

oc get pod --loglevel 6

oc get pod --loglevel 10