BusyBox

⒈含义 　　探针是由各个节点的kubelet对容器执行的定期诊断。要执行诊断，kubelet 调用由容器实现的Handler【处理程序】。有三种类型的处理程序： 　　　　>ExecAction：在容器内执行指定命令。如果命令退出时返回码为0则认为诊断成功。 　　　　>TCPSocketAction:对指定端口上的容器的IP地址进行TCP检查。如果端口打开，则诊断被认为是成功的。 　　　　>HTTPGetAction:对指定的端口和路径上的容器的IP地址执行HTTPGet请求。如果响应的状态码大于等于200且小于400【2xx：成功，3xx：跳转】，则诊断被认为是成功的 　　每次探测都将获得以下三种结果之一： 　　　　>成功：容器通过了诊断。 　　　　>失败：容器未通过诊断。 　　　　>未知：诊断失败，因此不会采取任何行动【这将导致容器挂死，因为探针不执行成功的话，容器会一直在等待】 ⒉探测方式 　　livenessProbe【存活指针或叫存活探针】:指示容器是否正在运行。如果存活探测失败，则kubelet会杀死容器，并且容器将受到其重启策略的影响。如果容器不提供存活探针，则默认状态为Success 　　readinessProbe【就绪指针或叫就绪探针】:指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与Pod 匹配的所有Service的端点中删除该Pod的IP地址

容器简介 什么是 Linux 容器 Linux容器是与系统其他部分隔离开的一系列进程，从另一个镜像运行，并由该镜像提供支持进程所需的全部文件。 容器提供的镜像包含了应用的所有依赖项，因而在从开发到测试再到生产的整个过程中，它都具有可移植性和一致性。 更加详细地来说，请您假定您在开发一个应用。您使用的是一台笔记本电脑，而且您的开发环境具有特定的配置。其他开发人员身处的环境配置可能稍有不同。您正在开发的应用依赖于您当前的配置，还要依赖于某些特定文件。 与此同时，您的企业还拥有标准化的测试和生产环境，且具有自身的配置和一系列支持文件。 您希望尽可能多在本地模拟这些环境，而不产生重新创建服务器环境的开销。 因此，您要如何确保应用能够在这些环境中运行和通过质量检测，并且在部署过程中不出现令人头疼的问题，也无需重新编写代码和进行故障修复？答案就是使用容器。 容器可以确保您的应用拥有必需的配置和文件，使得这些应用能够在从开发到测试、再到生产的整个流程中顺利运行，而不出现任何不良问题。这样可以避免危机，做到皆大欢喜。 虽然这只是简化的示例，但在需要很高的可移植性、可配置性和隔离的情况下，我们可以利用 Linux 容器通过很多方式解决难题。 无论基础架构是在企业内部还是在云端，或者混合使用两者，容器都能满足您的需求。 容器不就是虚拟化吗 是，但也不竟然。我们用一种简单方式来思考一下：

在学习嵌入式开发的过程中，尤其是开始入门时，包括各种各样的教程，都是在讲学习linux，很少讲如何利用linux来开发属于自己的嵌入式项目，也就是没有一个全局的概念，简单理解，大概流程如下： 一、建立开发环境 操作系统当然是LInux，或者在win系统下安装虚拟机，通过网络下载相应的GCC交叉编译器进行安装，或者安装产品厂家提供的交叉编译器。 这一步，就相当于在win系统下，要安装一个IDE开发环境，如MDK，IAR等。 二、配置开发主机 主要是配置minicom，也就是串口助手，minicom软件是作为调试嵌入式开发板信息输出的监视器和键盘输入工具，是一个非常方便的工具，我们开发其他嵌入式程序时，其实很多时候也采用串口调试，所以最终原理都是相通的。 配置网络，主要是配置NFS网络文件系统，这个主要是用于下载程序，当然不配置也可以，有很多别的办法。 三、建立引导装在程序的bootloader 常用的bootloader主要有u-boot、vivi等，貌似主流的就是u-boot，这个根据自己具体的芯片进行移植修改。有些芯片是没有内置引导加载程序的，这就需要编写开发板上的Flash的少些程序，当然也可以用windows下的通过JTAG并口和仿真器少些Flash芯片程序，也有linux下的公开源代码的J-Flash程序，所以在设计自己的硬件时，可以预留多种方式。 简单的讲

容器化部署越来越多的用于企业的生产环境中，如何构建可靠、安全、最小化的 Docker 镜像也就越来越重要。本文将针对该问题，通过原理加实践的方式，从头到脚帮你撸一遍。 构建镜像 手动构建 手动构建 Docker 镜像的流程图，如下： 现在依次按照流程采用命令行的方式手动构建一个简单的 Docker 镜像。 创建容器并增加文件 取 BusyBox 作为本次试验的基础镜像，因为它足够小，大小才 1.21MB。 $: docker run -it busybox:latest sh / # touch /newfile / # exit 通过以上的操作，我们完成了流程图的前三步。创建了一个新容器，并在该容器上创建了一个新问题。只是，我们退出容器后，容器也不见了。当然容器不见了，并不表示容器不存在了，Docker 已经自动保存了该容器。如果在创建时，未显示设置容器名称，可以通过以下方式查找该消失的容器。 # 列出最近创建的容器 $: docker container ls -l CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES c028c091f964 busybox:latest "sh" 13 minutes ago Exited (0) 27 seconds ago upbeat_cohen # 查询容器的详情 $:

文章目录 1 编译驱动程序 2 编译应用测试程序 3 运行测试 1 编译驱动程序 和前面章节中驱动测试程序一样需要一个Makefile文件，只是将obj-m的值改为beep_misc.o，Makefile文件内容如下： 然后执行“make”命令编译模块，编译完成生成beep_misc.ko模块文件。 2 编译应用测试程序 输入如下命令编译应用测试程序： arm-linux-gnueabihf-gcc -o beep_misc_test beep_misc_test.c 编译完成后，会生成beep_misc_test可执行文件。 3 运行测试 启动开发板，将编译好的beep_misc.ko模块文件和beep_misc_test应用程序拷贝到/lib/modules/4.1.15目录下（检查开发板根文件系统中有没有“/lib/modules/4.1.15”这个目录，如果没有的话需要自行创建一下。开发板中使用的是光盘资料里面提供的busybox文件系统，光盘资料的“i.MX6UL终结者光盘资料\08_开发板系统镜像\03_文件系统镜像\01_Busybox文件系统”目录下）。输入下面命令加载模块： 驱动加载成功后，可以在/sys/class/misc 这个目录下看到一个名为“miscbeep”的子目录，如图所示： 所有的 misc 设备都属于同一个类，/sys/class/misc

用户在使用 Docker 部署业务一段时间后，可能会发现宿主节点的磁盘容量持续增长，甚至将磁盘空间耗尽进而引发宿主机异常，进而对业务造成影响。 本文先对 Docker 的空间分析与清理进行说明，然后对容器的磁盘容量限制与使用建议做简要说明。 典型问题场景 用户发现 Docker 宿主机的磁盘空间使用率非常高。通过 du 逐层分析，发现是 Volume 或 overlay2 等目录占用了过高空间。示例如下： # 根据使用的存储驱动的不同，相应目录会有所不同： [root@node3 docker] # du -h --max-depth=1 |sort 104K ./network 13M ./image 20K ./plugins 24G ./overlay2 # 这个目录占用了非常高的磁盘磁盘空间 25G . 283M ./volumes 4.0K ./swarm 4.0K ./tmp 4.0K ./trust 518M ./containers 空间使用分析 遇到此类问题，可以参阅如下步骤进行空间分析，定位占用过高空间的业务来源。 分析 Docker 空间分布 Docker 的内置 CLI 指令 docker system df ，可用于查询镜像（Images）、容器（Containers）和本地卷（Local Volumes）等空间使用大户的空间占用情况。 示例输出如下：

[toc] Kubernetes之（十二）存储卷 简介 为了保证数据的持久性，必须保证数据在外部存储在docker容器中，为了实现数据的持久性存储，在宿主机和容器内做映射，可以保证在容器的生命周期结束，数据依旧可以实现持久性存储。但是在k8s中，由于pod分布在各个不同的节点之上，并不能实现不同节点之间持久性数据的共享，并且，在节点故障时，可能会导致数据的永久性丢失。为此，k8s就引入了外部存储卷的功能。 k8s的存储卷类型： [root@master ~]# kubectl explain pods.spec.volumes. emptyDir <Object> # 临时目录。pod删除数据也被删除,用于数据的临时存储。 hostPath <Object> #宿主机目录映射 和docker的一样 #以上两种都不能满足持久性存储 本地传统存储： - SAN(iSCSI,FC) - NAS(nfs,cifs,http) 分布式存储： - glusterfs - cephfs 云存储： - EBS,Azure Disk persistentVolumeClaim -->PVC(存储卷创建申请) 当你需要创建一个存储卷时，只需要进行申请对应的存储空间即可使用，这就是PVC。其关联关系如图： （图片来源： https://www.cnblogs.com/linuxk/）

安装部署一个私有的Docker Registry是引入、学习和使用Docker这门技术的必经之路之一。尤其是当Docker被所在组织接受，更多人、项目和产品开始接触和使用Docker时，存储和分发自制的Docker image便成了刚需。Docker Registry一如既往的继承了“Docker坑多”的特点，为此这里将自己搭建”各类”Registry过程中执行的步骤、遇到的问题记录下来，为己备忘，为他参考。 Docker在2015年推出了distribution项目，即Docker Registry 2。相比于old registry，Registry 2使用Go实现，在安全性、性能方面均有大幅改进。Registry设计了全新的Rest API，并且在image存储格式等方面不再兼容于old Registry。去年8月份，docker官方hub使用Registriy 2.1替代了原先的old Registry。如果你要与Registry2交互，你的Docker版本至少要是Docker 1.6。 Docker的开发者也一直在致力于改善Registry安装和使用的体验，通过提供官方Registry Image以及Docker Compose工具等来简化Registry的配置。不过在本文中，我们只是利用Docker以及Registry的官方Image来部署Registry