Istio 学习地图 - 玩 Istio，而不是被 Istio 玩（友情预览版）

容器内存限制是个矛盾而重要的选择，给多了浪费资源，给少了服务随机崩溃。CGroup 内存控制是容器资源控制的核心。她是个规律严明的看守者，在应用超限时狠心地 OOM Klll。她同时也有宽容的一面，在应用资源不足时，调配和释放 Cache 给应用使用。而其内心的记账算法却耐人寻味。要观察和监控她的状态和行为，更是千条万绪。本文尝试用作分析和梳理。

在未引入 Istio 前正常 HTTP 200 的请求，引入后变为 HTTP 400 。出现问题的流量均带有不合 HTTP 规范的 HTTP Header。于是尝试开发 Envoy WASM Filter 修正错误的 HTTP Header 。

大背景 滾滾長江東逝水，浪花淘盡英雄。 作为一个一直在底层苦苦挣扎多年程序员，保持一分学习的好奇心，对技术时势的感知，由为重要。因为这最终决定了

把大象装入货柜里——Java容器内存拆解

图片来自：https://getboulder.com/boulder-artist-rocks-the-world/ 引 话说，在很长一段时间

小众 iSCSI 简介

为何要调优 如果说，引入一个技术需要兴趣和冲劲，那么，让这个技术上线需要的是坚持和执着。 Cloud Native 如是， Istio 如是。 在上线前的性能测试中，Istio 的使

Custom Resource 的入口 请求是这样分发到 api 扩展点的： 例如我们有 （Custom Resource）CR 1 2 3 4 5 6 7 8 apiVersion:cnat.programming-kubernetes.info/v1alpha1kind:Atmetadata:name:example-atspec:schedule:"2019-07-03T02:00:00Z"status:phase:"pending" 相应的 CustomResourceDefinition (CRD) 会是这样： 1 2 3 4 5 6 7 8 9

API 入口 Client Sets 接收变更通知和缓存（Informers and Caching） Client Sets可以 watch 变更，但一般我们用更高级的 Informers，因为它有缓存

Concept umbrella chart you can also create a chart with dependencies to other charts (a.k.a. umbrella chart) which are completely external using the requirements.yaml file. versioning Simple 1-1 versioning Chart versus application versioning 参考 https://codefresh.io/docs/docs/new-helm/helm-best-practices/

前言 最近由于工作需要，重新系统回顾 Kubernetes 的编程。发现《Programming Kubernetes》这书写得比较系统。于是边学，边记录一些重点。 Controller

本文状态：草稿 配置例子 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 apiVersion:autoscaling/v2beta2kind:HorizontalPodAutoscalermetadata:name:php-apachespec:scaleTargetRef:apiVersion:apps/v1kind:Deploymentname:php-apacheminReplicas:1maxReplicas:10metrics:- type:Resourceresource:name:cputarget:type:UtilizationaverageUtilization:50 算法 desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricValue )] currentMetricValue 为相关 pod 的 metric 平均数。 If multiple metrics are specified in a HorizontalPodAutoscaler, this calculation is done for each metric, and then