在测试环境配置中，会经常使用到docker-compose，当配置文件被挂载到宿主机后，修改配置文件后不能生效就成了问题，鉴于此，我们使用supervisor和inotifywait来使“在宿主机修改配置文件，容器内生效”的作用supervisor和inotifywait说明supervisorsu
2023-07-16
延用之前的supervisor和inotify，这次加入ENV环境变量，主要配合compose做参数传递构建顺序我做了一个docker createrepo示例，并用了nginx和ngx-fancyindex模块，这样一来，这个过程就需要如下几步才能完成一个镜象的制作：1，选择基础镜象2，构建过程整
2023-07-16
容器中的nginx优化在物理机上配置Nginx时通常会将Nginx的worker进程数配置为CPU核心数并且会将每个worker绑定到特定CPU上，这可以有效提升进程的Cache命中率，从而减少内存访问损耗。在Nginx配置中一般指定worker_processes指令的参数为auto，来自动检测系
2023-07-16
由于一些需要，我在编辑一个redis镜象，出于一些考虑，需要传递一些变量来做简单的修改，以便于使用，只修改部分参数。有些机器并不是单独跑一个业务，这就不能使用固定的配置文件，缺少灵活度。这就又需要改变，我使用一个变量的传递加shell的判断来做，那么我至少要满足以下三点：通过变量修改部分配置文件中的
2023-07-16
出现状态：只读文件系统,如下，系统不能正常使用/usr/bin/xauth: error in locking authority file /root/.Xauthority Could not set property: 连接超时 Could not set property: Activat
2023-07-16
本次环境都在kebernetes v1.11.2，准备了四台使用centos7.5机器来做kubernetes的测试，有三台节点ip段均为10.10.240.0/24段(这意味着其他ip段无法加入)，pod网络使用172.16.0.0/16，server网络使用默认10.96.0.0/12其中分别使
2023-07-16
在之前的一章中简单的介绍了Yum安装kubernetes的方式，这次的笔记记录kubernetes的一些基础入门的一些操作，更多的是关乎于kubectl的一些使用，如：创建pod，scv，动态的增删，回滚，以及简单的网络等kubectlkubectl其实就是kubernetes的一个客户端程序，他通
2023-07-16
创建资源中，apiserver只接受JSON格式的资源定义，此前使用的run命令，只不过是自动转换成JSON格式而已。但是JSON太过于重量，使用YAML格式来提供配置清单，apiserver会自动将yaml无损转换为JSON模式，并且不需要多余的信息，而后在提交执行而后会通过资源配置清单，创建一个
2023-07-16
此前，使用centos以及ubuntu为容器基础镜像。后来为了缩减镜像的大小，使用alpine。这次，使用google的“Distroless”基本image做进一步的限制，这有助于我们构建更精简和更安全的镜像。介绍从三个方面来考虑是否使用 Distroless：安全性Distroless镜像仅包含
2023-07-16
在之前的资源清单中，其中需要遵循几个字段：apiversion(group/version)，kind，metadata(name,namespace,labels,annotations,.....)，spec，status。在上一篇的资源清单中有提到过在pod资源中，spec.container
2023-07-16
为了方便归类和管理，在kubernetes中标签管理也至为重要labels标签管理一个资源可以拥有多个标签，同一个标签可以被添加到多个对象，标签可以在创建资源时指定，并且可以在之后进行添加和删除，以及修改 labels: www: linuxea-com如上所示，类型key=value，其
2023-07-16
对于一个Pod而言，从开始到结束,要经过很多点初始化则在其中，而初始化也需要一定的时间，如：Dockerfile中的ENTRYPOINT脚本，此脚本也需要运行时间，所谓的秒级启动，可能不包含这些，简述pod什么周期，如下图其中，在容器内通常运行一个进程，而在pod中通常运行一个容器。在pod中的主容
2023-07-16
在之前的pod生命周期介绍中,容器启动并不是单纯的up起来就能完成工作，这期间需要做一系列的配置预热才可以更好的被使用。存活状态liveness probe探针类型有三种,ExecAction,TCPSocketAction,HTTPGetAction ExecAction: 容器探测failure
2023-07-16
pod被"正式的使用"之前需要做一些简单的检测pod的服务可用性，就此，readiness probe就派上用场readiness probe当使用kubectl get pods，在READY中的1/1,右边的1是POD内容器数量，而左边的1是就绪的个数。倘若不定义，那么在启动时候，就会立刻就绪[
2023-07-16
在之前，使用kubectl run的pod中，当pod被删除后会自动创建。而在kubectl create使用-f指定yaml文件时候，在删除则不会被创建。在kubectl run的pod是被控制器管理的，pod控制会严格管控pod资源符合用户期望的目标状态，如：定义了3个pod资源，一旦缺少必然会
2023-07-16
在前面一篇中提到过ReplicaSet，而ReplicaSet很多时候是无法满足现状，ReplicaSet确保在任何给定时间运行指定数量的pod副本。但是，Deployment是一个更高级别的概念replicaset本身仅仅并不是直接被控制，在replicaset之上是由Deployment来控制，
2023-07-16
集群节点中的每一个节点，或者选择器节点，运行“某个”指定的POD副本，通常用来实现系统级的管理功能，或者后台任务，可以将节点上的某个目录作为存储卷关联至POD中，让pod实现某些管理功能。并且在新加入的node节点自动添加此类的pod副本，其中也需要标签选择器的使用。并且daemonSet也支持滚动
2023-07-16
pod是有生命周期的，为了给对应的客户端提供一个固定的访问端点。在客户端与服务pod之间提供一个中间层Service，service严重依赖kubernetes(1.11.2)之上的附件CoreDNS(kube-dns)kubernetes的名称解析，强依赖于CoreDNS，在kubernetes中
2023-07-16
在之前的一些章节中，有hostNetwork和hostport,以及Nodeport三种服务暴露方式，nodeport跳过了service的cluster IP直接暴露出去，范围从30000-32767，不设置则动态分配，参考service第一章和hostNetwork创建pod资源在创建nodep
2023-07-16
在之前的Nodeport和hostNetwork中，大致了解了暴露的用法，此后有Ingress Controller的用法。之前不管那种方式，对于调用前端而言是不清楚后端pod的ip地址的。但是，有一些有状态的应用程序就需要清楚的联系到每个容器的ip地址，直接与容器通信。那就是Service的No
2023-07-16