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/v1alpha1 kind: At metadata: name: example-at spec: schedule: "2019-07-03T02:00:00Z" status: phase: "pending" 相应的 CustomResourceDefinition (CRD) 会是

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/v2beta2 kind: HorizontalPodAutoscaler metadata: name: php-apache spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: php-apache minReplicas: 1 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 50 算法 desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricValue