monitor

source/gluster/deploy/centos/deploy_centos7_gluster11_lvm_mdadm_raid6.rst

@@ -8,6 +8,8 @@
 
    根据 :ref:`deploy_centos7_gluster11` 迭代改进部署方案
 
+**待续**
+
 准备工作
 ===========
 

source/kernel/process/index.rst

@@ -7,6 +7,8 @@
 .. toctree::
    :maxdepth: 1
 
+   process_vs_thread.rst
+   thread_count.rst
    utils/index
 
 .. only::  subproject and html

source/kernel/process/process_vs_thread.rst

@@ -0,0 +1,53 @@
+.. _process_vs_thread:
+
+======================
+process vs. thread
+======================
+
+进程是程序执行时的一个实例，即它是程序已经执行到何种程度的数据结构的汇集。从内核的观点看，进程的目的就是担当分配系统资源（CPU时间、内存等）的基本单位。
+
+线程是进程的一个执行流，是CPU调度和分派的基本单位，它是比进程更小的能独立运行的基本单位。一个进程由几个线程组成（拥有很多相对独立的执行流的用户程序共享应用程序的大部分数据结构），线程与同属一个进程的其他的线程共享进程所拥有的全部资源。
+
+进程有独立的地址空间，一个进程崩溃后，在保护模式下不会对其它进程产生影响，而线程只是一个进程中的不同执行路径。线程有自己的堆栈和局部变量，但线程没有单独的地址空间，一个线程死掉就等于整个进程死掉，所以多进程的程序要比多线程的程序健壮，但在进程切换时，耗费资源较大，效率要差一些。但对于一些要求同时进行并且又要共享某些变量的并发操作，只能用线程，不能用进程。
+
+进程和线程两个模型的差异在于， 进程更安全，一个进程完全不会影响另外的进程。所以这也是 unix 哲学里推荐的编程方法； 但是进程间通信比线程间通信的性能差很多，尤其是，如果这个是系统的关键部分，而又有大量数据的时候，所有的进程间通信方法都比线程间的通信慢很多。
+
+所以通常情况下推荐多进程程序，就像 :ref:`nginx` ，一个 master 多个 worker，进程间只进行有限的通信（传递命令而非数据）。多线程的典型例子是 ``unbound`` ，一个开源的递归 dns 服务器。它使用线程的理由也很充分：程序需要不停地向后方的授权 dns 请求数据，并传回给前方的模块。这个数据通信量大，性能要求又高，所以必须用多线程，如果是多个进程，那就要慢许多了。
+
+使用线程的理由
+================
+
+使用多线程的理由之一是和进程相比，它是一种非常 "节俭" 的多任务操作方式。我们知道，在Linux系统下，启动一个新的进程必须分配给它独立的地址空间，建立众多的数据表来维护它的代码段、堆栈段和数据段，这是一种"昂贵"的多任务工作方式。
+
+而运行于一个进程中的多个线程，它们彼此之间使用相同的地址空间，共享大部分数据，启动一个线程所花费的空间远远小于启动一个进程所花费的空间，而且，线程间彼此切换所需的时间也远远小于进程间切换所需要的时间。据统计，总的说来，一个进程的开销大约是一个线程开销的30倍左右，当然，在具体的系统上，这个数据可能会有较大的区别。
+
+使用多线程的理由之二是线程间方便的通信机制。对不同进程来说，它们具有独立的数据空间，要进行数据的传递只能通过通信的方式进行，这种方式不仅费时，而且很不方便。线程则不然，由于同一进程下的线程之间共享数据空间，所以一个线程的数据可以直接为其它线程所用，这不仅快捷，而且方便。当然，数据的共享也带来其他一些问题，有的变量不能同时被两个线程所修改，有的子程序中声明为static的数据更有可能给多线程程序带来灾难性的打击，这些正是编写多线程程序时最需要注意的地方。
+
+除了以上所说的优点外，不和进程比较，多线程程序作为一种多任务、并发的工作方式，天然有以下的优点：
+
+- 提高应用程序响应。这对图形界面的程序尤其有意义，当一个操作耗时很长时，整个系统都会等待这个操作，此时程序不会响应键盘、鼠标、菜单的操作，而使用多线程技术，将耗时长的操作（time consuming）置于一个新的线程，可以避免这种尴尬的情况。
+- 使多CPU系统更加有效。操作系统会保证当线程数不大于CPU数目时，不同的线程运行于不同的CPU上。
+- 改善程序结构。一个既长又复杂的进程可以考虑分为多个线程，成为几个独立或半独立的运行部分，这样的程序会利于理解和修改。
+
+对比说明
+==========
+
+从函数调用上来说，进程创建使用 ``fork()`` 操作；线程创建使用 ``clone()`` 操作。
+
+Richard Stevens大师这样说过(大意):
+
+- fork开销很大，内存从父进程复制到子进程，所有的描述符都需要在子进程复制，以此类推。目前fork的实现使用一种 **写时复制** 的技术，该技术避免将父进程的数据空间复制到子进程，直到子进程需要自己的副本。但是不论怎样优化，fork都是昂贵的开销
+- 在fork之后，父进程和子进程之间的通信需要采用IPC(进程间通讯): 在fork之前父进程传递给子进程信息非常容易，这是因为子进程从父进程数据空间复制了一个副本，并且也复制了所有父进程的描述符。但是反过来，子进程要向父进程返回信息就需要大量的工作。
+
+线程有助于解决上述2个问题:
+
+- 线程有时候被称为轻量级进程，线程的创建速度比进程创建快10到100倍
+- 一个进程的所有线程共享相同的全局内存，这使得线程间信息共享很容易，但是这种简单性带来的问题是同步问题
+
+参考
+======
+
+- `Linux多线程编程（不限Linux） <http://www.cnblogs.com/skynet/archive/2010/10/30/1865267.html>`_
+- `Linux 线程实现机制分析 <https://www.ibm.com/developerworks/cn/linux/kernel/l-thread/>`_
+- `Linux 线程模型的比较：LinuxThreads 和 NPTL <http://www.ibm.com/developerworks/cn/linux/l-threading.html>`_
+- `知乎：Linux中进程和线程的开销基本一样啊，为什么还要多线程呢？ <https://www.zhihu.com/question/19903801>`_

source/kernel/process/thread_count.rst

@@ -0,0 +1,51 @@
+.. _thread_count:
+
+====================
+线程数量统计
+====================
+
+快速起步
+==========
+
+在系统监控时，我们需要关注一个进程的线程数量以及操作系统的线程总量，可以采用如下简便的方法:
+
+- 获取一个指定 ``pid`` 的所有线程数量:
+
+.. literalinclude:: thread_count/ps_pid_thread
+   :caption: 获取指定pid的所有线程的数量
+
+注意，这里会直接返回一个进程的所有线程总数(直接返回数字)，原因是这里参数 ``nlwp`` 表示 ``Number of LightWeight Processes`` ，也就是线程数量
+
+举例 我的 :ref:`kvm` 虚拟机 ``z-b-data-1`` 的进程PID是 ``7410`` ，则可以通过以下命令检查::
+
+   ps -o nlwp 7410
+
+输出结果::
+
+   9
+
+表明有9个线程
+
+其实，这个线程数量可以从 ``/proc/<pid>/status`` 中查看::
+
+   cat /proc/7410/status
+
+输出案例:
+
+.. literalinclude:: thread_count/proc_status_output
+   :caption: 检查进程对应的状态(线程数量)
+   :emphasize-lines: 35
+
+- 获取整个操作系统的线程数量(非常有用的监控命令):
+
+.. literalinclude:: thread_count/linux_os_threads_number
+   :caption: 获取Linux操作系统所有线程总数
+
+参考
+=====
+
+- `How to get (from terminal) total number of threads (per process and total for all processes) <https://askubuntu.com/questions/88972/how-to-get-from-terminal-total-number-of-threads-per-process-and-total-for-al>`_ 
+- `Thread count of a process in Linux <https://www.site24x7.com/learn/linux/linux-threads.html#:~:text=This%20is%20found%20in%20the,threads%20created%20for%20a%20process.>`_ 这篇文章更为详细，待学习
+- `Maximum Number of Threads per Process in Linux <https://www.baeldung.com/linux/max-threads-per-process#:~:text=How%20to%20Retrieve%20Maximum%20Thread,%2Fkernel%2Fthreads%2Dmax.&text=Here%2C%20the%20output%2063704%20indicates,a%20maximum%20of%2063%2C704%20threads.>`_ 操作系统对每个进程的线程数量是有限制的
+- `Maximum number of threads per process in Linux? <https://stackoverflow.com/questions/344203/maximum-number-of-threads-per-process-in-linux>`_
+- `Solved: Check thread count per process in Linux [5 Methods] <https://www.golinuxcloud.com/check-threads-per-process-count-processes/>`_

source/kernel/process/thread_count/linux_os_threads_number

@@ -0,0 +1 @@
+ps -eo nlwp | tail -n +2 | awk '{ num_threads += $1 } END { print num_threads }'

source/kernel/process/thread_count/proc_status_output

@@ -0,0 +1,57 @@
+Name:	qemu-system-x86
+Umask:	0002
+State:	S (sleeping)
+Tgid:	7410
+Ngid:	7418
+Pid:	7410
+PPid:	1
+TracerPid:	0
+Uid:	64055	64055	64055	64055
+Gid:	108	108	108	108
+FDSize:	128
+Groups:	20 108 64055
+NStgid:	7410
+NSpid:	7410
+NSpgid:	7409
+NSsid:	7409
+VmPeak:	17678804 kB
+VmSize:	17675976 kB
+VmLck:	16777088 kB
+VmPin:	       0 kB
+VmHWM:	16838564 kB
+VmRSS:	16825184 kB
+RssAnon:	16805424 kB
+RssFile:	   19756 kB
+RssShmem:	       4 kB
+VmData:	17135716 kB
+VmStk:	     136 kB
+VmExe:	    6084 kB
+VmLib:	   13916 kB
+VmPTE:	   33600 kB
+VmSwap:	       0 kB
+HugetlbPages:	       0 kB
+CoreDumping:	0
+THP_enabled:	1
+Threads:	9
+SigQ:	0/1546799
+SigPnd:	0000000000000000
+ShdPnd:	0000000000000000
+SigBlk:	0000000010002240
+SigIgn:	0000000000001000
+SigCgt:	0000000100004243
+CapInh:	0000000000000000
+CapPrm:	0000000000000000
+CapEff:	0000000000000000
+CapBnd:	000001ffffffffff
+CapAmb:	0000000000000000
+NoNewPrivs:	1
+Seccomp:	2
+Seccomp_filters:	1
+Speculation_Store_Bypass:	thread force mitigated
+SpeculationIndirectBranch:	conditional force disabled
+Cpus_allowed:	ffff,ffffffff
+Cpus_allowed_list:	0-47
+Mems_allowed:	00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000003
+Mems_allowed_list:	0-1
+voluntary_ctxt_switches:	32359118
+nonvoluntary_ctxt_switches:	66982

source/kernel/process/thread_count/ps_pid_thread

@@ -0,0 +1 @@
+ps -o nlwp <pid>

source/kubernetes/arm/arm_k8s.rst → source/kubernetes/arm/arm_k8s_plan.rst

@@ -1,7 +1,7 @@
-.. _arm_k8s:
+.. _arm_k8s_plan:
 
 ======================
-ARM部署Kubernetes
+ARM部署Kubernetes规划
 ======================
 
 概述

source/kubernetes/arm/index.rst

@@ -1,4 +1,4 @@
-.. _kubernetes_arm:
+.. _arm_k8s:
 
 ======================
 ARM架构Kubernetes
@@ -13,6 +13,6 @@ ARM架构Kubernetes
    :maxdepth: 1
 
    multi_arch_k8s.rst
-   arm_k8s.rst
+   arm_k8s_plan.rst
    arm_k8s_deploy.rst
    perfmance_arm_x86.rst

source/kubernetes/concepts/configuration/taints_and_tolerations.rst

@@ -8,11 +8,78 @@ Node affinity(节点亲和性)是设置pod优先分配到一组nodes(例如性
 
 taints和tolerations结合起来使用可以确保pod不会调度到不合适到节点。当一个或多个taints被应用到节点，则会标记节点不接受任何不容忍瑕疵的pods (not accept any pods that do not tolerate the tains)。当tolerations（容忍）被应用到节点，则允许（但不强求）pod调度到匹配瑕疵(taints)的节点上。
 
+这个概念在pod调度中非常有用，很多希望专门用途的服务器，可以通过 ``taints`` 设置为只让高优先级( ``tolerations`` )的用户使用。在多租户场景、异构Kubernetes集群( :ref:`arm_k8s` / :ref:`gpu_k8s` )，结合使用污点(taints)和容忍(tolerations)能够将应用容器放到不同的节点组，实现复杂的调度。
+
+
 .. note::
 
    ``taints`` 和 ``tolerations`` 是结合使用的：从字面意思上就是 ``瑕疵`` 和 ``容忍`` 。当节点被标记为瑕疵( ``taints`` )，则默认不会调度到该节点。除非pod被标记为容忍( ``tolerations`` )这个瑕疵，则带有容忍这种瑕疵的节点才会被调度到对应有瑕疵的节点上。
 
+污点(taints)和容忍(tolerations)的概念
+========================================
+
+在节点(node)上添加污点(taints)可以排斥所有pod，除了那些能够容忍(toleration)污点的pods。一个节点可以有一个或多个关联的污点。
+
+举例:
+
+- 管控平面的节点(master)通常会被主动污点，以便只有管控pods能够调度到master节点，普通用户部署的应用pods就不会调度到master节点，以便专用.
+- 服务器首次导入集群，为了能够完成一系列初始化工作，此时需要屏蔽工作负载调度到还没有完成初始化的节点，就可以使用 ``taint``
+
+一个 ``taint`` 可以有3种可能的影响:
+
+- ``NoSchedule`` - Kubernetes调度器只允许将对污点有容忍的pod调度到该节点
+- ``PreferNoSchedule`` - Kubernetes调度器将 ``尝试避免`` 将 **没有配置容忍的** pod调度到该节点(但不能保证，假如没有更好的可用节点)
+- ``NoExecute`` - 如果pod对污点节点没有容忍度，则Kubernetes会立即驱逐正在运行的pod
+
+.. figure:: ../../../_static/kubernetes/concepts/configuration/article-k8s-capacity-taint-tollerations.svg
+
+污点(taints)和容忍(tolerations)的案例
+=======================================
+
+- 对于需要为特定用户准备的工作节点，可以在节点上添加 ``taint`` :
+
+.. literalinclude:: taints_and_tolerations/taint_dedicated_group
+   :caption: 为节点添加 ``taint`` 用于特定 ``groupName`` 用户组
+
+然后该组用户的pod中添加 ``taint`` 对应的 ``toleration`` ，就能在这些节点运行。
+
+此外，为了确保这些用户的 pods **仅** 在该组 ``taint`` 节点上运行，还应该在该组节点添加标签，例如 ``dedicated=groupName`` ，然后在部署 pods 的时候使用 ``NodeSelector`` 将用户组的pod绑定到节点上，避免运行到其他地方。
+
+- 特殊硬件的节点(例如 :ref:`arm` 或者 :ref:`nvidia_gpu` )
+
+.. literalinclude:: taints_and_tolerations/taint_special_hardware
+   :caption: 为特殊硬件的节点添加 ``taint`` 以便只有使用特定硬件pod才能调度到该节点
+
+基于污点(taints)的驱逐(evict)
+================================
+
+如果 pod 对污点没有容忍度，则具有 ``NoExecute`` 效果的污点会将正在运行的 pod 从节点中逐出(evict)。 在某些场景下，Kubernetes 节点控制器会自动将这种污点添加到节点上，以便 **立即驱逐 pod** ，并 :ref:`drain_node` （驱逐所有 pod）。
+
+举例:
+
+- 如果网络中断导致控制器无法访问某个节点，此时最好将所有pod移出故障节点，以便能够重新调度到其他节点
+
+Kubernetes内建的tains
+-----------------------
+
+- ``node.kubernetes.io/not-ready`` 节点没有就绪，对应于 ``NodeCondition`` 的 ``Ready`` 属性是 ``False``
+- ``node.kubernetes.io/unreachable`` 节点不能从控制器访问，对应于 ``NodeCondition`` 的 ``Ready`` 属性是 ``Unknown``
+- ``node.kubernetes.io/memory-pressure`` 节点内存压力高
+- ``node.kubernetes.io/disk-pressure`` 节点磁盘IO压力高，此时会影响应用性能，建议重新分布pods
+- ``node.kubernetes.io/pid-pressure`` 节点PID压力高，进程ID是一种有限资源，过饱和可能会导致应用程序停机，因此最好将Pod重新定位到其他地方
+- ``node.kubernetes.io/network-unavailable`` 节点网络不可访问，此时建议将pod调度出去
+- ``node.kubernetes.io/unschedulable`` 节点不可调度，这是控制节点调度的常用taint，例如需要做集群缩容，节点需要删除
+
+污点(taints)和容忍(tolerations)的实践
+======================================
+
+- 查询集群的taints配置
+
+.. literalinclude:: taints_and_tolerations/get_nodes_taints
+   :caption: 查询集群中节点的taints设置
+
 参考
 ======
 
-- `Kubernetes Documentation - Concepts: Taints and Tolerations <https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/>`_
+- `Kubernetes Documentation - Concepts: Taints and Tolerations <https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/>`_ 中文文档:  `Kubernetes 文档>概念>调度、抢占和驱逐>污点和容忍度 <https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/>`_
+- `Kubernetes Tains & Tolerations <https://www.densify.com/kubernetes-autoscaling/kubernetes-taints/>`_ 一个不错的简明教程，比官方文档更清晰易懂，推荐阅读

source/kubernetes/concepts/configuration/taints_and_tolerations/get_nodes_taints

@@ -0,0 +1 @@
+kubectl get nodes -o=custom-columns=NodeName:.metadata.name,TaintKey:.spec.taints[*].key,TaintValue:.spec.taints[*].value,TaintEffect:.spec.taints[*].effect

source/kubernetes/concepts/configuration/taints_and_tolerations/taint_dedicated_group

@@ -0,0 +1 @@
+kubectl taint nodes nodename dedicated=groupName:NoSchedule

source/kubernetes/concepts/configuration/taints_and_tolerations/taint_special_hardware

@@ -0,0 +1 @@
+kubectl taint nodes nodename special=true:NoSchedule

source/kubernetes/monitor/grafana/grafana_behind_reverse_proxy_sub-path.rst

@@ -0,0 +1,23 @@
+.. _grafana_behind_reverse_proxy_sub-path:
+
+=======================================
+在反向代理后面运行Grafana (sub-path)
+=======================================
+
+在配合 :ref:`prometheus_startup_centos7` ，也采用了相似的 ``sub-path`` 反向代理：
+
+- 在 :ref:`install_grafana` 完成后，对于反向代理，需要修订 ``/etc/grafana/grafana.ini`` 配置文件:
+
+  - 访问域名 ``domain``
+  - 访问url ``root_url``
+
+配置修订位于 ``[server]`` 部分如下:
+
+.. literalinclude:: grafana_behind_reverse_proxy_sub-path/grafana.ini
+   :caption: 修订 ``/etc/grafana/grafana.ini`` 配置访问域名以及访问路径
+
+
+- 在NGINX服务器上 配置 ``/etc/nginx/conf.d/onesre-core.conf`` 设置反向代理:
+
+.. literalinclude:: grafana_behind_reverse_proxy_sub-path/sub-path_nginx.conf
+   :caption: nginx反向代理，grafana用sub-path模式 ``/etc/nginx/conf.d/onesre-core.conf``

source/kubernetes/monitor/grafana/grafana_behind_reverse_proxy_sub-path/grafana.ini

@@ -0,0 +1,4 @@
+[server]
+domain = onesre.cloud-atlas.io
+root_url = %(protocol)s://%(domain)s:%(http_port)s/grafana/
+serve_from_sub_path = true

source/kubernetes/monitor/grafana/grafana_behind_reverse_proxy_sub-path/sub-path_nginx.conf

@@ -0,0 +1,14 @@
+upstream grafana {
+    server 192.168.8.151:3000;
+}
+
+server {
+    listen 80;
+
+    server_name onesre onesre.cloud-atlas.io;
+
+    location / {
+        include proxy_params;
+        proxy_pass http://grafana;
+    }
+}

source/kubernetes/monitor/grafana/index.rst

@@ -8,9 +8,11 @@ Grafana通用可视分析平台
    :maxdepth: 1
 
    install_grafana.rst
+   install_grafana_centos7.rst
    grafana_config_startup.rst
    run_grafana_in_k8s.rst
    grafana_behind_reverse_proxy.rst
+   grafana_behind_reverse_proxy_sub-path.rst
    grafana_reset_admin_password.rst
 
 推荐阅读:

source/kubernetes/monitor/grafana/install_grafana_centos7.rst

@@ -0,0 +1,31 @@
+.. _install_grafana_centos7:
+
+=====================
+CentOS 7安装Grafana
+=====================
+
+.. note::
+
+   和 :ref:`prometheus_startup_centos7` 一样，在生产环境CentOS 7操作系统上部署Grafana。实践验证，实际上安装步骤和 :ref:`install_grafana` 一致，原因是Grafana提供了非常完善的软件仓库，支持CentOS 7系列。本文实践中添加了 ``sub-path`` :ref:`grafana_behind_reverse_proxy` 配置部分
+
+在CentOS7上安装
+====================
+
+安装方法和 RHEL/Fedora 没有区别:
+
+- 添加仓库GPG密钥以及创建仓库配置文件:
+
+.. literalinclude:: install_grafana/rhel_install_grafana
+   :caption: 在RHEL/Fedora上安装Grafana
+
+- 启动服务(和Debian/Ubuntu相同):
+
+.. literalinclude:: install_grafana/ubuntu_start_grafana
+   :caption: 启动Grafana
+
+
+
+参考
+=====
+
+- `Install on Debian or Ubuntu <https://grafana.com/docs/grafana/latest/installation/debian/>`_

source/kubernetes/monitor/prometheus/index.rst

@@ -11,6 +11,8 @@ Prometheus监控
 
    introduce_prometheus.rst
    prometheus_startup.rst
+   prometheus_startup_centos7.rst
+   prometheus_behind_reverse_proxy.rst
    prometheus_exporters/index
    run_prometheus_in_k8s.rst
    run_prometheus_in_k8s_arm.rst