mischen520的博客

Docker 容器的数量受到宿主机的资源限制，包括CPU、内存和存储空间等。具体的容器数量取决于宿主机的硬件配置和资源使用情况。在实际操作中，创建过多的容器可能会导致资源竞争和性能问题，所以你应当根据宿主机的实际情况合理安排容器的数量。为了评估能创建多少容器，你需要考虑到每个容器的资源需求，并根据宿主机的总资源进行合理规划。B. 和宿主机的cpu/memory 资源有关系。宿主机上运行的其他应用程序和服务的资源占用情况。宿主机的CPU核心数量和每个核心的线程能力。宿主机的内存大小和是否有足够的交换空间。

此外，‌对于需要确保每一台机器都能运行指定Pod的任务，‌DaemonSet是一个合适的选择，‌因为它可以确保集群内每一个（‌或者一些）‌节点都运行一组相同的Pod。‌然而，‌需要注意的是，‌DaemonSet并不直接提供任务失败后的自动重试功能。‌因此，‌正确设置Pod的重启策略是确保任务能够在失败后自动重试的关键。当任务偶尔失败时，‌通过设置restartPolicy为OnFailure，‌可以确保任务在失败后自动重新启动，‌从而尝试重新执行直到成功。3、Never：当容器终止退出，从不重启容器。

‌这意味着，‌如果某个 Pod 由于某种原因未能成功启动，‌DaemonSet 不会尝试重新启动该 Pod 多次以达到指定的重试次数后停止尝试。‌这意味着，‌虽然 DaemonSet 可以确保 Pod 在节点上运行，‌但它不提供错误处理和重试机制，‌这对于需要确保服务高可用性的场景可能是一个限制。DaemonSet 是 Kubernetes 中的一个资源对象，‌用于确保在集群中的每个节点上运行一个 Pod 的副本。‌它的主要功能包括：‌。跟踪集群节点状态，‌保证新加入的节点自动创建对应的 Pod。

比如当用户的资源足够，且更注重发布过程中的可用性，可设置 MaxUnavailable 较小、MaxSurge 较大。但如果用户的资源比较紧张，可以设置 MaxSurge 较小，甚至设置为 0，这里要注意的是 MaxSurge 和 MaxUnavailable 不能同时为 0。两者同时为 0 的话，MaxSurge 保证不能新扩 Pod，而 MaxUnavailable 不能保证 ReplicaSet 中有 Pod 是 available 的，这样就会产生问题。所以说这两个值不能同时为 0。

当你更新Deployment时，Kubernetes会创建一个新的ReplicaSet来替换旧的，并逐渐增加新ReplicaSet的Pod数量，逐步减少旧的ReplicaSet的Pod数量。这里需要注意的是，只有更新 Deployment template 中的 label 和 image，才会创建一个新的 revision，而扩缩容不会创建 revision，所以回退历史 revision 时，只有 Deployment 中的 template 部分才会回退。由此可知，D也是错误的。

‌Deployment可以实现的功能包括应用扩缩容、‌应用发布回滚、‌应用副本数量维持等，‌但唯独不包括应用重启。‌这意味着，‌虽然Deployment可以管理和控制应用的部署和更新，‌但它不直接涉及应用的重启操作。‌在Kubernetes中，‌如果需要重启应用，‌通常需要通过其他方式实现，‌比如使用Kubernetes的Job或者其他控制器来触发应用的重启。‌它通过控制ReplicaSet来实现对Pod的管理，‌确保应用按照指定的副本数运行，‌并在需要时进行滚动升级或回滚操作。

‌如果worker尝试执行耗时的操作，‌如调用其他耗时的web服务并等待返回，‌这会导致资源利用效率低下，‌因为controller需要快速响应和处理事件，‌而不是等待外部服务的响应。‌这样的操作不仅会降低controller的整体性能，‌还可能导致其他重要的任务被延迟处理，‌从而影响系统的稳定性和可靠性。在controller中，‌worker最不适合执行的操作是调用其他耗时的web服务并等待返回（‌占用资源低效）‌。D. 调用其他耗时的web 服务并等待返回。C. 更新资源对象的 status。

Sidecar通常与主应用程序共享相同的生命周期，一起创建和退出，它可以在不修改主应用程序代码的情况下添加多种功能，如负载平衡、服务注册、服务发现、流量管理等。在微服务的架构中，一个主要的服务实例可能只负责核心业务逻辑，而与之关联的 sidecar 则负责提供一些辅助功能，例如日志记录、监控、安全性、通信、或其他横切关注点。“Sidecar 模式” 是一种微服务架构中常见的模式，它指的是将辅助性质的服务（通常被称为 sidecar）与主要的服务实例部署在一起，以提供一些额外的功能、能力或支持。

容器的“单进程”模型的具体含义是指容器的生命周期等同于PID=1的进程（‌容器应用进程）‌的生命周期，‌而不是说容器里不能创建多进程。‌这个PID=1的进程就是应用本身，‌它代表了容器的入口点。‌由于容器不具备管理多个进程的能力，‌因此PID=1的进程通常不会具有像操作系统中的init进程或systemd进程管理的功能。‌这意味着，‌虽然容器内部可以运行多个进程，‌但这些进程都是PID=1进程的子进程，‌而PID=1的进程本身是容器应用的主体，‌负责协调和管理这些子进程的执行。

以下哪个 docker 命令可以用来创建一个使用宿主机主机名的容器？

在容器内部，无法通过 kill -9 PID 方式杀死进程，只能是退出状态，要想杀死进程，可以在容器外面，docker kill 命令就是在容器外通过发送SIGKILL杀死容器的，因为在宿主机上，这个init进程的ID已经不再是 1了。已知容器 Init 进程 PID，在宿主机上通过 kill -9 PID 的方式结束该进程，容器当前的状态是什么？

1、集群形式RabbitMQ是用Erlang语言开发的，集群非常方便，因为Erlang天生就是一门分布式语言，但其本身并不支持负载均衡。RabbitMQ集群中节点包括内存节点（RAM）、磁盘节点（Disk，消息持久化），集群中至少有一个Disk节点。普通模式（默认）对于普通模式，集群中各节点有相同的队列结构，但消息只会存在于集群中的一个节点。对于消费者来说，若消息进入A节点的Queue中，当从B节点拉取时，RabbitMQ会将消息从A中取出，并经过B发送给消费者。应用场景：该模式适合于消息无需持久

ElasticSearch集群1.集群原理ElasticSearch是天生支持集群的，他不需要依赖其他的服务发现和注册的组件，如zookeeper这些，因为他内置了一个名字叫ZenDiscovery的模块，是ElasticSearch自己实现的一套用于节点发现和选主等功能的组件，所以ElasticSearch做起集群来非常简单，不需要太多额外的配置和安装额外的第三方组件。1、单节点A.一个运行中的ElasticSearch实例称为一个节点，而集群是由一个或者多个拥有相同的cluster.name配置

今天在部署es集群的时候，发现它报了下面这样的一个错误："Caused by: java.lang.IllegalArgumentException: unknown setting [discovery.send_hosts] please check that any required plugins are installed, or check the breaking changes documentation for removed settings","at org.elasticsear

今天在部署es集群的时候，发现它报了下面这样的一个错误：uncaught exception in thread [main]java.lang.IllegalArgumentException: unknown setting [discovery.send_hosts] please check that any required plugins are installed, or check the breaking changes documentation for removed settin

今天在运行ElasticSearch集群的时候，发现报了下面的错误，{"type": "deprecation", "timestamp": "2022-01-26T07:58:54,866Z", "level": "WARN", "component": "o.e.d.c.s.Settings", "cluster.name": "my-es", "node.name": "es-master-3", "message": "[discovery.zen.ping.unicast.hosts] sett

1.什么是脑裂现象？在ElasticSearch集群初始化或者主节点宕机的情况下，由候选主节点中选举其中一个作为主节点。指定候选主节点的配置为：node.master:true。当主节点负载压力过大，或者集群环境中的网络问题，导致其他节点与主节点通讯的时候，主节点没来及响应，这样的话，某些节点就认为主节点宕机，重新选择新的主节点，这样的话整个集群的工作就有问题了，比如我们集群中有10个节点，其中7个候选主节点，1个候选主节点成为了主节点，这种情况是正常的情况。但是如果现在出现了我们上面所说的主节点响应不

最近在进行大量的word合并的时候，报了一个org.dox4j.openpackaging.exceptions.Docx4JException:Error marshalling Content_types这个错误，具体报错全文如下：org.dox4j.openpackaging.exceptions.Docx4JException:Error marshalling Content_typesat org.dox4j.openpackaging.io3.stores.ZipPartStore.sav

要部署redis-cluster集群模式，先来了解redis-cluster集群模式的两种实现原理，一种是使用槽的方式进行处理，需要计算16384个槽的位置，一种是使用一致性hash来计算hash环。两种方式大同小异，都是需要计算。下面详细的来说明一下：redis集群功能的限制：redis集群相对单机来说，在功能上存在一些限制。redis集群时使用 JAVA CRC16校验算法来计算槽位1.使用槽来实现key批量操作支持有限类似mset、mget操作，目前只支持对具有相同slot值的key进行批

1.下载mysql镜像这里我们拉取官方的最新版本的镜像：docker pull mysql:latest这一步也可以省略，当没有版本的时候，会自动去远程仓库里面拉取2.创建master实例并启动docker run -p 3307:3306 --name mysql-master --privileged=true -v /mydata/mysql/master/log:/var/log/mysql -v /mydata/mysql/master/data:/var/lib/mysql -v

今天docker容器中搭建mysql主从同步的时候，发现了如下报错：[Err] 1055 - Expression #1 of ORDER BY clause is not in GROUP BY clause and contains nonaggregated问题背景：使用的mysql数据库版本为：5.7在从库中执行如下命令：start slave然后就报如上错误[Err] 1055 - Expression #1 of ORDER BY clause is not in GROUP BY

今天在搭建mysql集群的时候发现一个问题，我创建的docker master实例为下面的语句：docker run -p 3307:3306 --name mysql-master -v /mydata/mysql/master/log:/var/log/mysql -v /mydata/mysql/master/data:/var/lib/mysql -v /mydata/mysql/master/conf:/etc/mysql -e MYSQL_ROOT_PASSWORD=root -d

docker启动es命令为：docker run --name elasticsearch -p 9200:9200 -p 9300:9300 -e “discovery.type=single-node” -e ES_JAVA_OPTS="-Xms64m -Xmx128m" -v /mydata/elasticsearch/config/elasticsearch.yml:/usr/share/elasticsearch/config/elasticsearch.yml -v /mydata/e

如果容器无法启动，则Kubernetes将显示错误状态为：CrashLoopBackOff。通常，在以下情况下容器无法启动： 应用程序中存在错误，导致无法启动 你未正确配置容器 Liveness探针失败太多次 你应该尝试从该容器中检索日志以调查其失败的原因。如果由于容器重新启动太快而看不到日志，则可以使用以下命令：$ kubectl logs <pod-name> --previous这个命令打印前一个容器的错误消息。也可以参考下面的详细解析

在node节点上执行以下操作：yum installrhsmwgethttp://mirror.centos.org/centos/7/os/x86_64/Packages/python-rhsm-certificates-1.19.10-1.el7_4.x86_64.rpmrpm2cpio python-rhsm-certificates-1.19.10-1.el7_4.x86_64.rpm | cpio -iv --to-stdout ./etc/rhsm/ca/redhat-uep.p..

1.使用docker容器开发、测试、部署服务2.创建隔离的运行环境3.搭建测试环境4.构建多用户的平台即服务（PaaS）基础设施5.提供软件即服务（SaaS）应用程序6.高性能、超大规模的宿主机部署

1.提供简单轻量的建模方式2.职责的逻辑分离3.快速高效的开发生命周期4.鼓励使用面向服务的架构

基本管理： # 创建pod资源 kubectl create -f pod.yaml # 查看pods kubectl get pods pod-test # 查看pod描述 kubectl describe pod pod-test # 替换资源 kubectl replace -f pod.yaml -force # 删除资源 kubectl delete pod pod-test...

Compose是一个定义和管理多容器的工具，使用Python语言编写。使用Compose配置文件描述多个容器应用的架构，比如使用 什么镜像、数据卷、网络、映射端口等；然后一条命令管理所有服务，比如启动、停止、重启等。...