Kubernetes的Kube Proxy的转发规则分析
概要
filter表
nat表
Chain KUBE-SERVICES
Chain KUBE-NODEPORTS (1 references)
Chain KUBE-POSTROUTING (1 references)
报文处理流程图
发送到Node的报文的处理过程
Node发出的报文的处理过程概要
kube-proxy是kubernetes中设置转发规则的组件，通过iptables修改报文的流向。
以下是在一台kubernetes node节点上观察到的结果，kube-proxy是一个独立的组件，下面的观察结果适用于运行在其它地方的kube-proxy。
$kube-proxy --version
kubernetes v1.5.2
通过iptables -L -t [iptables表名]可以看到，kube-proxy只修改了filter和nat表。五个检查点:
INPUT OUPUT
. |
/_\ +------ ...
使用 CLI 创建 Azure VM 的自定义映像
自定义映像类似于应用商店映像，不同的是自定义映像的创建者是你自己。 自定义映像可用于启动配置，例如预加载应用程序、应用程序配置和其他 OS 配置。 在本教程中，你将创建自己的 Azure 虚拟机自定义映像。 你将学习如何执行以下操作：
取消预配和通用化 VM
创建自定义映像
从自定义映像创建 VM
列出订阅中的所有映像
删除映像
在 Azure 中国区使用 Azure CLI 2.0 之前，请先运行 az cloud set -n AzureChinaCloud 来改变云环境。如果想切回国际版 Azure，请再次运行 az cloud set -n AzureCloud。如果选择在本地安装并使用 CLI，本教程要求运行 Azure CLI 2.0.4 或更高版本。 运行 az --version 即可查找版本。 如果需要进行安装或升级，请参阅安装 Azure CLI 2.0。
开始之前下列步骤详细说明了如何将现有 VM 转换为可重用自定义映像，用于创建新的 VM 实例。若要完成本教程中的示例，必须现有一个虚拟机。 如果需要，此脚本示例可为你创建一个虚拟机。 按照教程进行操作时，请根 ...
发布Azure资源管理（ARM）模板
以下为代码模板，根据自己情况修改{
"$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"virtualMachineName": {
"type": "string",
"metadata": {
"description": "虚拟机名称"
}
},
"virtualMachineSize": {
"type": " ...
Kubernetes 滚动升级
run test deploy
[root@k8s-master ~]# kubectl run --image=nginx --port=80 --replicas=2 test-nginx
scale replica
[root@k8s-master ~]# kubectl scale --replicas=1 deploy/test-nginx
[root@k8s-master ~]# kubectl get deploy
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
busybox 2 2 2 2 39d
busybox1 1 1 1 1 39d
test-nginx 1 1 1 1 2h
update image
[roo ...
K8s容器一直重启问题排查
问题昨天有个客户反馈服务不可访问，查看服务日志发现dns无法解析，通过kubectl查看kube-dns 这个pod一直在重启，客户只反馈了这一个问题，如图：
过了一会后发现kube-dns灾厄已经恢复，但是kube-flannel这个pod又开始一直重启。根据自己以往的经验还以为是路由出了什么问题，所以在排查路由方面浪费了一些时间，
排查一段时间路由后未发现异常，随后想到查看有问题机器的kubelet日志，如下
describe node的Events如下：
解决通过日志可以发现是磁盘满导致的原因，但在当时看到问题时只是根据经验以为是路由有问题（只能说是学艺不精），但是我还没来得及查看磁盘，就补客户给清理过，而且客户还顺手把机器给重启了，机器启动后一切就恢复正常
排查后来上网搜索相关错误字段，随后阅读相关文章以及查看k8s代码，发现k8s有一个Eviction Manager的机制，如下图：
如果在启动k8s时没有设置Eviction Thresholds（驱逐阈值)，k8s将按代码里（上图）默认的值执行
但是通过可看kubelet日志发现，前一天的时候就已经发现有相关报错，那 ...
Kubernetes Eviction Manager工作机制分析
摘要为了极限的压榨资源，很多时候Kubernetes集群会运行一些Best-Effort Task，这样就会存在资源超配的情况，Kubernetes是如何控制Node上资源的使用，在压榨资源使用的同时又能保证Node的稳定性？本文就为你介绍其背后运行机制。我的下一篇博文，会对Kubelet Eviction Manager进行源码分析，感兴趣的同学可以关注。
研究过Kubernetes Resource QoS的同学，肯定会有一个疑问：QoS中会通过Pod QoS和OOM Killer进行资源的回收，当发生资源紧缺的时候。那为什么Kubernetes会再搞一个Kubelet Eviction机制，来做几乎同样的事呢？
首先，我们来谈一下kubelet通过OOM Killer来回收资源的缺点：
System OOM events本来就是对资源敏感的，它会stall这个Node直到完成了OOM Killing Process。
当OOM Killer干掉某些containers之后，kubernetes Scheduler可能很快又会调度一个新的Pod到该Node上或者container ...
Kubernetes的使用技巧
1. bash针对kubectl命令的自动补充这可能是在使用Kubernetes过程中最容易做的事，但它也是其中一个最有用的。要添加自动补充功能，如果使用bash，只需执行以下命令：
echo "source <(kubectl completion bash)" >> ~/.bashrc
它将添加自动补全命令到你的.bashrc文件。因此每个你打开的shell窗口都支持该功能。我发现自动补全对一些长的参数，比如–all-namespaces特别有用。
2. 给每个namespace添加默认的内存和CPU限额是人就会犯错。我们假定某人写了个应用，他每秒就会打开一个数据库连接，但是不会关闭。这样集群中就有了一个内存泄漏的应用。假定我们把该应用部署到了没有限额设置的集群，那么该应用就会crash掉一个节点。为了避免这种情况，Kubernetes允许为每个namespace设置默认的限额。要做到这很简单，我们只需创建一个limit range 的 yaml 并应用到特定namespace。以下是一个例子：
apiVersion: v1
kind: ...
K8S的 QoS策略
QoSk8s中对容器的资源分配有三种策略：
Guaranteed 。该策略下，pod.spec.containers[].resources中会存在cpu或memory的request和limit。顾名思义是该容器对资源的最低要求和最高使用量限制。如果我们配置了limit，没有配置request，默认会以limit的值来定义request。具体的配置可以参考以前的这篇笔记。
BestEffort。当pod的描述文件中没有resource.limit、resource.request相关的配置时，意味着这个容器想跑多少资源就跑多少资源，其资源使用上限实际上即所在node的capacity。
Burstable。当resource.limit和resource.request以上述两种方式以外的形式配置的时候，就会采用本模式。QoS目前只用cpu和memory来描述，其中cpu可压缩资源，当一个容器的cpu使用率超过limit时会被进行流控，而当内存超过limit时则会被oom_kill。这里kubelet是通过自己计算容器的oom_score，确认相应的linux进程的oom_adj， ...
K8s的一次路由故障
问题今天有个客户三台master上有两台的kube-dns一直起不来，如图：
排查
查看pod的日志：
看到报错后首先想到的就是rount有问题，然后通过查看路由发现，有问题的两台机器多了一条路由：
通过以下命令查看本机应该对应的flannel的路由：
[root@node-dev-3 ~]# cat /run/flannel/subnet.env
FLANNEL_NETWORK=10.5.0.0/16
FLANNEL_SUBNET=10.5.2.1/24
FLANNEL_MTU=1450
FLANNEL_IPMASQ=true
解决方法
删除多余的路由规则：
[root@node-dev-3 ~]# route del -net 10.5.2.0 gw 172.26.7.12 netmask 255.255.255.0
删除之前的旧dns pod
[root@node-dev-3 ~]# kubectl delete pod -n kube-system kube-dns-xxx
最后查看dns pod 已经正常运行
Hung_task_timeout_secs参数
问题客户有一台服务器，安装了VMW软件做了虚拟化，在其上搭建了一台readhat虚拟机，起初给的内存为16G，在添加了12G的内存后，将虚拟机的内存调整到了20G调整完后主机这边就一直报错：
Nov 5 13:05:41 RedHat5 kernel: INFO: task oracle:22439 blocked for more than 120 seconds.
Nov 5 13:05:41 RedHat5 kernel: “echo 0 > /proc/sys/kernel/hung_task_timeout_secs” disables this message.
解决方法从以上的报错信息也给出了简单的解决方案，就是禁止该120秒的超时：
echo 0 > /proc/sys/kernel/hung_task_timeout_secs
原因查询了资料后对于该参数的了解为后台对进行的任务由于超时而挂起
随后询问了主机工程师：给出方案是按照告警里的提示将该提醒disable后续询问后给出如下解释：
This is a know bug. By default Linu ...