rosenlo / notes Goto Github PK

Hello Minikube

通过Minikube本地运行Kubernetes。OS X版本的Minikube实际是创建了一个Linux虚拟机，再在虚拟机上支持容器。默认驱动程序为VirtualBox，这里我使用了Hyperkit。

参考官方教程：https://kubernetes.io/docs/tutorials/hello-minikube/

Environment

• macOs 10.13.6
• ShadowsocksX-NG 1.8.2
• Docker for Mac 18.03.1-ce
• Minikube v0.25.0

Proxy Configuration

配置为：http://0.0.0.0:1087，需要注意以下问题：

• 一般代理配置默认监听127.0.0.1:1087，由于是在虚拟机内创建的容器，因为虚拟机网段的不同并不能使用127.0.0.1或localhost等地址，对于虚拟机来说localhost为虚拟机本身，并不是宿主机。所以须设置为宿主机与虚拟机网段通讯的IP地址。

Create a Minikube cluster

这里的HTT_PROXY和HTTPS_PROXY填宿主机地址192.168.64.1，这里虚拟机的网段为192.168.64.0/24

minikube start --vm-driver=hyperkit --docker-env HTTP_PROXY=http://192.168.64.1:1087  --docker-env HTTPS_PROXY=http://192.168.64.1:1087

对于已创建过的集群，可以通过配置文件修改~/.minikube/machines/minikube/config.json

  "Env": [
    "HTTP_PROXY=http://192.168.64.1:1087",
    "HTTPS_PROXY=http://192.168.64.1:1087"
  ],

以上设置完后，虚拟机中的容器也可以愉快的访问外面的世界了！

JVM

JVM对ElasticSearch集群的稳定性有很大的影响。

Java是一个垃圾收集语言，意思是这个程序不会手动管理分配和释放内存。程序员只需要编写代码，jvm管理根据需要管理分配内存的处理，然后在不需要的时候清理。

• Young (or Eden)
  当新实例一个对象的时候分配的空间，新生代的空间一般比较小，通常是100MB-500MB，新生代也包含了2个幸存(survivor)空间。

• Old
  存储较老的对象空间。这些对象预期是长久的并且持续了很长时间。老年代一般比新生代空间大得多，在ElasticSearch节点中最大可以设置为30GB。

当一个对象被实例化，它将被放到新生代。当新生代空间快满的时候，开始新生代垃圾收集(GC)，仍然”活着“的对象移到survivor空间，不再用的对象被移除，如果一个对象在几次新生代GC中survived下来，它将被永远被放在老年代。

类似的情况发生在老年代，当空间快满时，开始GC移除不再用的对象。

对于空间比较小的新生代GC执行很快，但对于老年代来说就比较慢了，一个缓慢的GC可能有1s甚至15s以上，这对于服务是不可接受的。

JVM中的GC是非常复杂的算法，可以最小化停顿。ElasticSearch非常努力的试图使GC变得友好，通过智能重用内部对象、网络缓存区并默认启用文档值，但最终，GC 的次数和持续的时间是需要观察的指标，因为它是集群不稳定性的第一个罪归祸首。

一个频繁长时间GC的集群是重负载并且没有足够的内存的。这些长时间GC将使节点短暂的离开集群。在elasticsearch中为了保持集群的稳定和可用的副本，这种不稳定因素经常导致重新迁移分片。当你的集群尝试服务正常的索引和查询时，这反过来增加了网络流量和磁盘I/O负载。

简而言之，长时间GC是危险的，需要尽可能的减少它的时间。

node-stats API:

"jvm": {
  "timestamp": 1483246917484,
  "uptime_in_millis": 679408297,
  "mem": {
    "heap_used_in_bytes": 17235461384,
    "heap_used_percent": 55,
    "heap_committed_in_bytes": 30780620800,
    "heap_max_in_bytes": 30780620800,
    "non_heap_used_in_bytes": 137928872,
    "non_heap_committed_in_bytes": 141455360,
    
  }
}

• heap_committed_in_bytes应该和heap_max_in_bytes相同，如果这个committed大小更小，JVM将会重新调整堆栈，这是个非常昂贵的过程。如果你的数字不一样，参考Heap: Sizing and Swapping如何正确配置。
• heap_used_percent这个指标是非常有用的，当heap达到75%时启动GC。如果节点一直大于75%，节点内存将有压力，这是一个警告信号，表示缓慢的GC将会在不久发生。
  如果heap使用一直大于85%，你将有麻烦来了，超过90-95%伴随着GC时间达到10-30s将面临性能风险，并有可能引发一个异常out-of-memory(OOM)

 "pools": {
  "young": {
    "used_in_bytes": 3525862600,
    "max_in_bytes": 5726666752,
    "peak_used_in_bytes": 5726666752,
    "peak_max_in_bytes": 5726666752
  },
  "survivor": {
    "used_in_bytes": 77053512,
    "max_in_bytes": 1431633920,
    "peak_used_in_bytes": 618333600,
    "peak_max_in_bytes": 1431633920
  },
  "old": {
    "used_in_bytes": 13631010160,
    "max_in_bytes": 23622320128,
    "peak_used_in_bytes": 17722183576,
    "peak_max_in_bytes": 23622320128
  }
}

• 这个young、survivor和old部分提供在GC中每个代的内存使用情况。这些统计数据方便你查看相对大小，但在调试问题时通常不太重要。

"gc": {
  "collectors": {
    "young": {
      "collection_count": 35879,
      "collection_time_in_millis": 1954077
    },
    "old": {
      "collection_count": 6,
      "collection_time_in_millis": 4782
    }
  }
}

• gc部分展示了young和old垃圾收集的数量和累积的时间。大部分可以安全的忽略young的数量。数量是非常大的，这是完全正常的。
  相反，old垃圾收集数量应该是非常少的，同时collection_time_in_millis 也会比较小。这是个累计数，所以很难给出一个具体的数字代表它出现了问题。（例如：一个运行了一年的节点将具有非常大的计数，即使它是正常的）。
  花在GC上的时间也非常重要。（例如：在索引一个文档时将生成一些垃圾）。这些GC几乎总是快速并且对节点几乎没有影响。young需要1ms或2ms，而old需要几百毫秒，这和需要10s的GC截然不同。
  启用slow-GC日志

线程池

ElasticSearch在内部管理线程池，这些线程池合作完成任务，根据需要在彼此传递工作。通常不需要配置或调整线程池，但是有时候查看这些统计信息是非常有益的，可以了解集群的状态。
有大约十二个线程池，但都是一样的格式：

"bulk": {
  "threads": 0,
  "queue": 0,
  "active": 0,
  "rejected": 0,
  "largest": 0,
  "completed": 0
}

• 每个线程池列出了配置的线程数(threads)，有多少个活动的线程正在工作(active)，有多少个工作单位在一个队列(queue)。
• 如果一个队列被填满到限制，新的工作单位将被拒绝(rejected)，这通常是一个信号，表示集群上资源到了一定瓶颈。一旦队列满了意味着节点/集群正在以最大的速度处理但跟不上涌入的请求。

Bulk Rejections

• 如果遇到队列拒绝，很有可能是批量索引请求。
• 通常每个集群都有其跟不上涌入请求的某些限制，一旦超过阀值，这个队列将被填满，然后新的批量请求将被拒绝。
• 这是一件好事，对减缓压力，队列拒绝是非常有用。这能让你知道你的集群的最大容量。这比粘贴数据到内存队列好得多。更多的队列大小并不能提高性能，只是隐藏了这个问题。如果你的集群只能处理10k/s的文档，无论队列是100或10万，你的集群仍然只能处理10k/s的文档。
• 队列简单的隐藏的性能问题，同时它将带来数据丢失的风险。任何东西在队列中被定义为将被处理，如果节点宕机，所有请求永远丢失。此外，队列吃了很多内存，这不是一个好主意。
• 优雅的处理积压的队列对你的应用来说是更好的。当时接收到批量拒绝时，你应该尝试以下操作：
  1. 暂停线程3-5秒。
  2. 提取被拒绝的批量请求。
  3. 发送被拒绝的批量请求。
  4. 如果继续被拒绝请重复第1步。
• 使用次过程，你的代码自然会适应集群的负载，然后正常的退出。
• 拒绝并不是错误，只是意味着你应该晚点重试:)
• 有十几个线程池。但大部分可以忽略，仅有几个需要我们关注：
  1. indexing
     • 正常的索引请求
  2. bulk
     • 批量请求，和零散的索引请求完全不同
  3. get
     • Get-by-ID 操作
  4. search
     • 所有的搜索和查询请求
  5. merging
     • 专注于管理lucene合并