这是从《正见-佛陀的证悟》这书中，摘出来的句子，我认为有意义，或者对四法印中的诸行无常有理解的部分， 一直放在QQ空间中， 前两天拿出来看了一下， 觉得还是有不少的体会，所以把它搬过来了， 后续的内容是不是会更新还是要看我懒不懒了。 只是对老与死的厌恶，并不足以让太子离开王宫而踏入未知的世界；悉达多会采取这么激烈的行动，是因为他实在无法合理地解释所有已生和将出生的一切众生命运就是如此而已。如果所有生者都必须衰朽死亡，那么花园中的孔雀、珍宝、华盖、熏香、音乐，放拖鞋的金质拖盘、进口的玻璃水瓶、他与耶输陀罗和罗睺罗的感情、家庭、国家，都变得毫无意义。这一切的目的到底是什么？ 完全不凭借任何科学工具，悉达多太子以吉祥草为垫，坐在一棵菩提树下，探索人类的本性。经过了长时间的思维，他终于了悟到一切万有，包括我们的血肉、我们所有的情绪和我们所有的觉受，都是由两个以上的元素组合而成。当两种或多种元素和合在一起，新的现象就会产生；钉子和木头产生了桌子；水和叶子产生了茶；而恐惧、虔诚和救世主，就产生了神。这些最终的产物，并没有独立于其各别元素的存在。相信它真实独立存在，是最大的骗局。而在和合的同时，各个元素也起了变化。只因接触和合，它们的性质也随之改变了。 一切万有，没有一样是以独立、恒常、纯粹的状态存在。你手上的书不是，原子不是，甚至神祇也不是。 因此悉达多发现，无常并不像一般人以为的就是意味死亡，而是意味变化。任何事物和另一个事物之间的位置或关系转变了，即使是非常细微的变动，都要依循无常的法则。 如果没有盲目的期待，就不会有失望。如果能了解一切都是无常，不会攀缘执著；如果不攀缘执著，就不会患得患失，也才能真正完完全全地活着。 悉达多从恒常的幻相中觉醒，因此我们称他为佛陀、觉者。到现在还是没有人可以长生不老，每个人终究会死，而且每天大概有二十五万人死亡。我们亲近的人不是已经死亡就是将会死亡。然而当亲人死去的时候，我们还是会震惊和悲伤；我们还是继续寻找青春之泉，或是长寿的秘方。 悉达多太子不再需要或渴求长生不老药了。由于了悟到一切事物皆是和合而成，解构无止境，而且一切万有的各个成分，没有一项是以独立、恒常与纯粹的状态存在的，他因此获得解脱。一切和合之物(现在我们知道这是指一切事物)与其无常的本质是合而为一、不可分割的。 当悉达多看到一个人走过，即使他很健康，悉达多所看到的是此人的生与灭同时发生。你也许会认为这样的人生观不太有趣，但在生命的旅程中能够同时看到一体的两面，可以是非常奇妙，而且可能会有很大的满足感。 也就表示现在有个“假设者”，悉达多会同意，只要有假设者，就会有上帝存在；但如果没有假设者，就不会有上帝存在。如果没有纸，就不会有书。如果没有水，就不会有冰。如果没有开始，就不会有结束。一件事物的存在，亟需依赖其它事物的存在，因此没有什么是真正独立的。尽管我们以为可以控制变化，但事实上大多是不可能的，因为无法察觉的影响因素太多了。也因为这种相互依存性，一切事物不可避免地会从目前或原始状态中解体。每一个变化中都蕴藏着死亡的因素。今日就是昨日之死。 大部分的人都接受一切生者终将死亡。然而我们对“一切”与“死亡”的定义或许不太一样。对悉达多来说，生指的是一切万有，不仅仅是花朵、蘑菇、人类，而是一切生成或和合的事物。而死亡指的是任何的解体或是解构。无常纯粹是一个简单实在的事实。不可能有一天，某个突发的和合事物会突然变得恒常，更难想象我们能证明这样的事。但是在今天，我们不是将佛陀奉为神明，就是想用科技证明自己比佛陀更高明。 佛陀教导我们，至少我们心中要保持着无常的概念，不要故意去隐藏它。我们借着不断地觉察和合的现象，便会了知因缘相依。认识因缘相依，我们就会认识无常。而当我们知道一切事物皆无常，才不会被种种假设、僵化的信条(不论宗教的或世俗的)、价值体系和盲目信仰所奴役。我们的觉察力可以让我们免于受限于个人的、政治的和感情的戏码之中。我们还可以将这种觉察力导向大至想象之极，小至次原子层次。 由于我们对自己的道德原则感到自豪，而且常强加于别人身上，因此道德观还是具有少许价值。然而，在整个人类历史当中，道德的定义也随着时代精神而一直在改变。美国人度量政治正确性或不正确性的仪表起伏不定，令人迷惑。不管如何称呼种族或文化群体，总是有人会被冒犯，游戏规则一直在改变。 当悉达多提到“一切和合的事物”，他所指的不只是像DNA、你的狗、艾菲尔铁塔、卵子和精子等具体可认知的现象而已。心、时间、记忆和上帝，也是和合而成。而每一和合的成分，又依赖更多不同层次的和合而成。 当悉达多教导无常时，他也超越了一般“结束”的想法，像是那种认为死亡只发生一次就完了的概念。死亡从生、从创造的那一刻开始，就没有停过。每一个变化，都是死亡的一种形式，因此每一个生都包含了另一个事物的死亡。 拿煮鸡蛋来做例子。如果没有不断的变化，蛋就煮不熟；煮好蛋的这个结果，需要某些基本的因缘。很显然的，你要有一颗蛋、一锅水，和一些加热的元素。另外有些非必要的因和缘，像是厨房、灯光、计时器，还有一只把蛋放进锅子的手。另外一个重要的条件，就是没有像是电力中断或是山羊跟进来打翻锅子之类的干扰。此外，每一个条件，例如母鸡，都需要有另一套具足的因缘条件。需要有另一只母鸡生下蛋才能孵出它，还要有安全的地方，有食物才能让它成长。鸡的食物也要有适合的地方生长，并且要能让它吃进去才行。我们可以将非必要和必要条件一直分析到小于原子的程度，而在这个分析的过程中，各种形态、形状、功能和标签也会不断地增加。 当无数的因缘和合在一起，而且没有障碍与干扰，结果是必然的。许多人误以为这是注定的或是运气所致。然而，到了一个程度以后，即使我们祈求蛋不要煮熟，它还是会熟的。 就像蛋一样，所有的现象是由无数的成分所组成，因此它们是可变的。这些无数的成分几乎都不是我们所能控制的，所以会让我们的期待落空。这种不可预料性，遍在于所有的物质、感受、想象、传统、爱情、信任、不信任、怀疑论，甚至上师和弟子以及人与神之间的关系。 信仰，怀疑论以及所有和合的现象一样，都是无常的。 有些人到现在还认为马克·查普曼(Mark Chapman)是谋杀约翰·蓝侬(John Lennon)唯一的罪犯。当我们能了解一个病态而饱受折磨的心是如何形成，并且知道它是在什么样的情况下运作，就比较能够理解并宽恕世界上众多的马克”查普曼。当条件成熟，就像蛋煮熟了一样，即使我们祈祷暗杀事件不要发生，它还是避免不了。超过了某个时间点，我们要改变条件的企图和行为就会徒劳无功了。 恐惧和焦虑是人类心智中主要的心理状态。恐惧的背后是对确定性不断的渴求。我们对未知感到恐惧。人心对肯定的渴望，是根植于我们对无常的恐惧。 但我们常常忘记自己的来日一直都是有限的。即使理智上知道有生必有死，一切和合终将分散，我们的情绪状态还是常常会回到相信恒常的模式，完全忘记相互依存性。这种习气会造成各种负面的情况，像是偏执、寂寞、罪恶感等等。我们会觉得被欺骗、被威胁、被虐待、被冷落，仿佛这个世界只对我们不公平。 佛陀不是一个悲观者、也不是末日论者，他是重视实际者，而我们却多是逃避现实者。当他说一切和合皆是无常，他并不认为那是坏消息，而是简单、科学的事实。我们能认清因缘的不稳定，就会了解自己有力量转化障碍，并且完成不可能的任务。生活中的各个层面都是如此。如果你现在没有一台法拉利，你完全有可能创造出因缘而拥有一台。只要世上有法拉利，你就有机会去拥有它。同样的，如果你想活久一点，可以选择不抽烟和多运动。合理的希望是存在的。而绝望，和它的反面—模一样，都是相信恒常的结果。

在华为的月度报告中， 发现了奇怪的问题，有一台机器在每天都会内存使用率飙到100%，偶尔的几次还会出现OOM的记录。在追踪问题的过程中，发现机器上每天的2，4，6，8点会自动运行处理日志的脚本，并统计关键字的数量。 这个脚本的过滤日志思路是， 使用 less 命令打开昨天的所有日志文件，并且读取内容，过滤其中的关键字，命令类似如下： less yesterday*.log.gz | grep -e "xxxxx" -e "xxxxx" | sort | uniq | wc -l 关于Less, More, Cat, Zcat这个四个命令可以分成两组: less / more 的命令是为了个人类查看文件的内容设计的程序； cat / zcat 是一次性输出内容到屏幕的； 两组命令的唯一区别是是否提供前后反复查看的功能。但是就是这个功能，导致了命令执行的逻辑其实是完全不同的。 less命令的执行方式将查看到的数据放入内存中（USED），所以 如果是一个10G的日志，就会占用10G的内存， 如果不够，系统就会进行交换和将旧数据换出的操作。cat的执行模式是将数据直接输出到/dev/stdout，同时操作系统会将数据存储到Cache中，不会触发内存的告警， 由于日志中的数据其实只是进行一次过滤， 所以不需要长期的保留， 这也提高了bash处理日志文本的速度。 补充一下， Vim也是一样的， Vim会尽可能的将文件载入到内存里， 所以日志类的文件是不需要， 也不能使用Vim的. 结论由于两个命令的处理方式不同,因此直接将命令中输出gz日志的命令换成了zcat，即可保证内存的使用不会变多, 这里同时提高的处理文本命令的效率，这个机器专门用来做这一件事情， 所以不需要考虑其他进程会影响日志处理， 造成数据的不一致。所以在脚本中一定一定使用正确的命令和方式处理数据，才能保障性能和效率的兼顾。 最后，优化过的命令为： zcat yesterday*.log.gz | grep -e "xxxx" -e "xxxx" | sort -u | wc -l 最后的执行时间，从原来的半个小时起步，变成了10分钟即完成。 后续的处理已知我们的问题是不需要系统自动cache住我们过滤的日志数据，我们可以手动释放一下已经无用的cache内容： sync && echo 3 > /proc/sys/vm/drop_caches 后面还添加了并行执行的处理命令， 但是这个并行执行的脚本确实写的非常的垃圾。 另外添加了使用python 自动填写过滤的结果到 Excel 表格。

Kubernetes的Dashboard 和 分级认证权限。 Dashboard的简介Dashboard算是k8s的一个管理的web界面。不做具体的操作，登录的时候使用的是K8S提供的用户名和密码。 Dashboard的部署只需要从github进行apply资源清单即可。 Dashboard的登录使用Token登录 获取系统中默认的admin的token，或者创建一个需要登录和管理的ServiceAccount，然后Binding到Role或者 ClusterRole,进行权限的控制 查看集群中自动创建的dashboard的secret， 系统部署完成之后自动创建了一个可管理全部集群的secret ~]$ kubectl get secret -n kube-system | grep dashboard dashboard-admin-token-g85h7 kubernetes.io/service-account-token 3 109d 在这个secret中有Token相关的信息 ~]$ kubectl describe secret dashboard-admin-token-g85h7 -n kube-system 其中的Token字段的内容就是可以用来登录的令牌。复制到dashboard中粘贴即可 使用config文件登录 创建ServiceAccount，Binding到role 获取Secret，然后查看他的token 制作config文件 使用config文件登录 Kubernetes的管理方式 命令 create , run ,expose , delete ,edit …. 命令式配置文件 create -f , delete -f , replace -f 声明式配置文件 apply -f , patch 一般不混合使用，1.2 使用的是替换，但是3是立刻修改，立刻生效，所以还是比较危险的。

K8S的认证部分， ServiceAccount以及RBAC 。 授权插件 Node ABAC RBAC Webhook 常用的授权插件就是RBAC 基于角色的授权和访问控制基于角色的访问控制，就是将权限授予Role，而不是User。 将权限的控制授予Role， 将User分配到Role。默认的是拒绝全部， 无法也无需定义拒绝权限，定义的Permission是许可访问的权限。 角色，User Accouts OR Service Accounts. 许可， Permission分为两个部分：Operation 以及 Object. 角色以及角色绑定Role – RoleBinding Role 和 RoleBinding 是建立和控制 NameSpace 级别的权限。 集群角色以及集群角色绑定ClusterRole – ClusterRoleBinding Cluster 和 ClusterBinding 是建立和控制 Cluster 级别的权限。 NOTE： 特殊的情况，可以对名称空间级别的 特殊的绑定方式ClusterRole – RoleBinding 可以使用 RoleBinding 绑定 ClusterRole， 那么这种情况下，Role只是具有NameSpace的权限。解释一下：雷在同一个Cluster中有多个不同的NameSpace，我需要对每个NameSpace都授权相同的权限，这种场景下: 如果使用RoleBinding 去绑定一个Role，那么每一个NameSpace都需要建立各自的 RoleBinding，并且都要各自绑定到Role。 如果建立一个ClusterRole, 使用RoleBinding绑定到ClusterRole上面，那么我只需要定义一个即可在全部集群范围内生效这个权限。这样的就相当于批量的进行Role的授权。 相关命令命令不做过多的解释，所有的资源可以通过explain获取，主要是记录逻辑和思路。 ~]$ kubectl create role testrole --verb=get,list,watch --resources=pods -o yaml ~]$ kubectl get role ~]$ kubectl describe role pods-reader ~]$ kubectl create rolebinding test-rolebinding --role=testrole --user=testuser -o yaml ~]$ kubectl explain rolebinding ~]$ kubectl config use-context USERNAME@kubernetes ~]$ kubectl create clusterrole test-clusterrole --verb=get,list,watch --resource=pods -o yaml ~]$ kubectl explain clusterrole ~]$ kubectl get clusterrole ~]$ 其他补充在RBAC中可以存在三类组件： user group service account 创建Pod的过程中可以指定一个值叫做ServiceAccountName，如果授权ServiceAccount高等级的权限，那么，Pod会以这个Account运行，那么Pod中的应用程序也会有ServiceAccount的权限。也就是提高了Pod应用程序的等级，使得Pod可以对K8S的相关资源进行管理和配置。

将自己的桌面环境迁移到了i3。Gnome好用是好用的，但是体量还是有点儿大了，吃资源有点多。 这个现在已经更新到 DWM 上面了， 对于这里面还有其他的工具是一直在用的， 比如 picom 等等。 安装i3-gaps安装的过程比较简单,pacman 就完事儿了。 pacman -Syyu pacman -S i3-gaps 这里有两个可以选择，一个是i3-wm, 还有一个是i3-gaps, 我用了i3gaps， 好看一些。 pacman -S alacritty pacman -S polybar pacman -S compton (最新的软件改名了，叫picom,但是安装的方式不变的。) pacman -S picom pacman -S dmenu pacman -S rofi pacman -S feh pacman -S variety pacman -S unzip-natspec #unzip-natspec貌似是在archlinuxcn里面的，可以处理zip解压的时候乱码的问题，不用考虑手动指定解压的-O了。 配置i3在已经有Gnome环境的条件下，i3 的配置还是比较轻松的。 I3的使用说明i3默认的操作是使用Windows/Super/Mod这个按键(或者随便怎么叫吧，后面都说Super，和Gnome的口径一致)，简单列举一下频率较高的使用方式 先说重载配置文件，使用 Super + Shift + r 退出到DM，使用Super + Shift + e， DM就是你的登录界面。 i3提供了10个虚拟桌面，切换虚拟桌面方式是可以通过Super + 1 - 10 快速切换 在默认的Tiling排列模式中切换排列位置Vertical和Horizontal. 通过Super V 或者 Super H 调整容器布局： 使用Stacking – Super + s 所有的标签堆叠显示最上方提供标签进行切换 使用Tabbed – Super + w 标签页方式显示所有窗口 使用Toggle – Super + e 平铺窗口模式，可切换不同的布局方式 打开程序可以通过terminal开启，或者Super + d 使用dmenu开启（可将 dmenu 替换成 rofi） 关闭程序可以通过Super + Shift + q关闭，或者鼠标点击x，不是所有的窗口都有x 在窗口间移动可使用 Super + {jkl;}四个按键；或者使用Super + {up,down,left,right}的arrowkey 可将窗口变更为Floating， 使用Super + Shift + Space Floating窗口调整位置可长按Super 使用鼠标拖动调整位置 全屏程序使用 Super + f i3的自定义配置配置文件的位置配置文件的路径： $HOME/.config/i3/config,所有的配置在这个文件下修改 自定义界面的设置默认的i3启动的时候还是挺丑的，我有四个设置： gaps inner 5 # 设置i3窗口间的空隙大小，单位是像素。 new_window 1pixel # 设置新的窗口的边界宽度，效果是不显示窗口的title。 new_float 1pixel # 新的浮动窗口的边界宽度，同上。 smart_borders on # 在只有一个窗口的情况下自动最大化当前的窗口，不处理窗口的Gap。 默认terminal程序更改设置默认使用 Super + Enter 打开alacritty bindsym $mod+Return exec --no-startup-id alacritty alacritty 是一个使用GPU进行渲染的terminal模拟器，它有自己的配置文件，我的配置文件路径在:$HOME/.config/alacritty/alacritty.conf *NOTE： 关于Alacritty的问题目前已经解决的差不多了。 还有还有一个问题是关于ssh过去之后不能正确的识别终端类型的问题，解决方案在后面。 默认打开Firefox我的设置是Super + p bindsym $mod+p exec --no-startup-id firefox 开机启动一些程序我的开机启动了 Compton, Variety, Remmina,Aria2c, Polybar, ibus-daemon，剩下的看自己喜欢什么就安装什么就OK了。 exec_always --no-startup-id compton --config /home/liarlee/.config/compton/compton.conf -b exec_always --no-startup-id variety exec_always --no-startup-id remmina exec_always --no-startup-id aria2c --conf-path=/home/liarlee/.aria2/aria2.conf exec_always --no-startup-id sh /home/liarlee/.config/polybar/polybar_startup.sh exec_always --no-startup-id ibus-daemon -dr 截屏功能快捷键默认的i3不能用PrintScreen我觉得有点儿难受，所以自己添加了快捷键和保存位置 bindsym --release Print exec "scrot -b -m /home/liarlee/Pictures/Scort_ScreenShot/screenshot.png" 更新： 之前的这个方式可以作为截图的快捷方式，但是当你需要连续的截图的时候就会特别的难受，因为新截图会自动覆盖掉旧的截图。更新一下新的方式，写一个脚本，当我们按下PrintSc的时候触发这个脚本，就可以对文件重命名了。 也许脚本名称可以叫 - screenshot.sh #!/bin/bash snapdate=`date "+%Y%m%d_%H%M%S"` gnome-screenshot -f /home/hayden/screenshot/Screenshot-$snapdate.png 更新i3的配置文件，添加快捷键的管理。 bindsym --release Print exec "/home/liarlee/Scripts/System/screenshot.sh" 这样再截图就会保存到指定的位置，并且用时间命名区分开不同的截图，不会覆盖了。 调节音量快捷键由于已经有了PulseAudio， 所以i3自动增加了笔记本Func-key的调整，但是如果没有功能键的话，还是要按照如下自定义的。我调整音量用的Super + F2/F3, 也可以改其他的 # Use pactl to adjust volume in PulseAudio. bindsym XF86AudioRaiseVolume exec --no-startup-id pactl set-sink-volume @DEFAULT_SINK@ +10% && $refresh_i3status bindsym $mod+F3 exec --no-startup-id pactl set-sink-volume @DEFAULT_SINK@ +10% && $refresh_i3status bindsym $mod+F2 exec --no-startup-id pactl set-sink-volume @DEFAULT_SINK@ -10% && $refresh_i3status bindsym XF86AudioLowerVolume exec --no-startup-id pactl set-sink-volume @DEFAULT_SINK@ -10% && $refresh_i3status bindsym XF86AudioMute exec --no-startup-id pactl set-sink-mute @DEFAULT_SINK@ toggle && $refresh_i3status bindsym XF86AudioMicMute exec --no-startup-id pactl set-source-mute @DEFAULT_SOURCE@ toggle && $refresh_i3status 拼音输入法我在Gnome下使用的是Ibus-rime框架的小鹤双拼，Gnome下开箱即用，但是i3需要做一些简单的配置，更改一些环境变量。 在自己的家目录 : touch .xprofile 添加内容如下： export GTK_IM_MODULE=ibus export QT_IM_MODULE=ibus export XMODIFIERS=@im=ibus 使用source读取配置文件中的环境变量，使环境变量生效。尝试输出echo $XMODIFIER查看是否已经生效，输出空值的话ibus还是无法使用。 结合上面的i3配置文件，使用ibus-daemon -dr启动，不要XIM。如果你使用了-x启动，在浮动的输入法工具栏中会显示一个禁止的标志，说明拼音未正常工作。 配置Polybar我基本上使用的是默认的Bar配置文件，还比较方便。 复制一个配置文件的模板到家目录的文件夹下： cp -p /usr/share/doc/ploybar/config .config/polybar/config 编辑一个启动脚本 touch polybar_startup.sh 写入如下内容 #!/bin/bash ## kill all old process of ploybar killall -q polybar while pgrep -u $UID -x polybar > /dev/null; do sleep 1; done echo "---" | tee -a /tmp/polybar.log polybar example & /tmp/polybar.log 2>&1 & echo "Polybar launched" 结合上面的i3配置进行开机自动运行即可。我觉得默认的这个还行，可以日常使用了，不调整了，太费劲了。 目前还未解决的问题无法在terminal中输入中文目前中文的输入法还是有些问题，无法在alacritty中输入中文，可能和ibus的关系比较大，我尝试使用fctix完全没有任何问题，所有的地方都可以输入中文，所以选择什么方式输入中文，各有所好吧。但是，Gnome环境和i3的环境是会冲突的，所以同时安装ibus和fcitx要考虑一下。 Alacritty中无法输入中文的问题已经解决了！ 那么解决的方法如下： ​ 在/etc/profile文件中（或者.zshrc中），添加如下的环境变量 export GTK_IM_MODULE=ibus export XMODIFIERS=@im=ibus export QT_IM_MODULES=ibus 之后 ， source /etc/profile source ~/.zshrc 重新启动alacritty就可以使用了。 我想root cause是 ...

K8S集群的存储卷笔记。 整体的存储卷调用结构： 在k8s的集群中，Pod声明自己需要存储卷资源，同时创建自己的PVC，PVC绑定到集群中已经注册的PV资源，例如 已经建立的NFS网络空间。PV资源通过存储系统的分配，直接提供给Pod来使用。 PVC属于名称空间级别，PV属于集群资源。 存储卷的类型 EmptyDir：只在Node上存在的存储卷，Pod删除的时候存储卷也会被移除，无法持久存储，叫做EmptyDir，做临时存储和缓存使用，可以使用Node的内存。 HostPath： Docker的存储卷类型，Node节点上的目录。 网络存储： SAN， NAS; 分布式存储(Glusterfs，Cephfs，rbd); 云存储(EBS， Azure Disk，特定的托管在云上的服务) kubectl explain pod.spec.volumes 可以查看支持那些存储。 PVC对于用户来说，无法掌握所有的存储系统的知识和技能，因此，创建了PVC的逻辑层，在定义需要使用存储卷的Pod中只需定义需要的空间以及存储的类型，不需要详细的考虑后端存储的信息和配置。 PVC被定义在Pods的配置中，一个 PVC可以被多个Pod同时访问。 PV存储类： Gold Storage Class, Sliver Storage Class, Bronze Stroage Class.三个不同级别的存储类。存储类直接接受PVC的内容并对PVC定义的容量等信息进行分配。 PV与存储服务的提供者直接绑定且需要在存储服务提供方配置完成。PV与PVC具有一一对应的关系。 PersistentVolumegitRepo仓库的使用： gitRepo存储卷建立在EmptyDir的基础上，在Pod内建立空目录，同步Git的内容到空目录，Pod运行的过程中不会更改存储卷上的内容。也就是说，git同步是pod建立的时候同步的数据，不会对git项目的数据进行更改。Pod更改了存储卷中的数据不会自动推送到Git上（可以使用Sidecar进行推送和配置）。 PV资源的定义--- apiVersion: v1 kind: PersistentVolume metadata: name: pv001 labels: name: pv001 spec: nfs: path: /data/volumes/v1 server: storage1.liarlee.com accessModes: ["ReadWriteMany","ReadWriteOnce"] capacity: storage: 20Gi 使用apply命令进行应用即可。 查看所有的PV使用： kubectl get pv ， 其中显示了PV的名称，大小，访问模式，回收策略，状态，建立时间等。 PersistentVolumeClaim使用的过程中，在Pod中定义PVC；PVC和PV是一一对应的，但是PVC可以被多个Pod调用和挂载。一个PV会Binding一个PVC，PVC在Pod中被定义。 PVC以及PV的状态，未绑定的状态叫做Pending，绑定后叫做Bound。 PVC的定义--- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: pvc001 namespace: default spec: accessModes: ["ReadWriteMany"] resource: request: storage: 6Gi ConfigMap资源configmap是明文资源，secret是base64的编码资源，因此安全程度提高了。configmap相当于外挂的配置文件，当Pods启动的时候直接挂载Configmap读取自己需要的配置内容。 配置应用容器化的方式 自定义命令行参数 配置文件直接放入镜像中 通过环境变量进行配置 存储卷 Cloud Native应用通过环境变量直接配置 通过EntryPoint脚本预处理环境变量作为配置问文件中的信息 docker config命令行方式 Configmap的创建configmap为了将配置文件中镜像中解耦，configmap可以直接注入到容器中直接使用，注入的方式可以使用存储卷，或者使用EntryPoint来处理。 通过命令直接传递键值： kubectl create configmap cm-nginx --from-literal=nginx_server_name=nginx.liarlee.com --from-literal=nginx_server_port=80 kubectl create configmap cm-nginx --from-file=./nginx.conf # 直接传递文件到ConfigMap kubectl get cm cm-nginx -o yaml # 用YAML的格式查看ConfigMap 通过YAML文件： --- apiVersion: v1 kind: ConfigMap data: nginx.conf................................ metadata: name: cm-nginx namespace: default 创建Pod时ConfigMap使用环境变量方式： --- apiVersion: v1 kind: Pod metadata: name: pod-nginx namespace: default labels: app: pods-nginx tier: frontend annotations: liarlee.com/created-by: "cluster admin" spec: containers: - name: pod-nginx image: nginx:latest ports: - name: http containerPort: 80 env: - name: NGINX_SERVER_PORT valueFrom: configMapKeyRef: name: cm-nginx key: nginx_port env: - name: NGINX_SERVER_NAME valueFrom: configMapKeyRef: name: cm-nginx key: nginx_server_name 创建Pod的时候使用挂载卷的方式： 通过挂载的方式可以通过修改configmap的方式，同步修改容器内部的配置。 --- apiVersion: v1 kind: Pod metadata: name: pod-nginx namespace: default labels: app: pods-nginx tier: frontend annotations: liarlee.com/created-by: "cluster admin" spec: containers: - name: pod-nginx image: nginx:latest ports: - name: http containerPort: 80 volumeMounts: - name: nginxconf mountPath: /etc/nginx/conf.d/ readOnly: true Volumes: - name: nginxconf configMap: name: cm-nginx 创建Secret的类型kubectl create secret –help docker-registry – 连接到Docker私有仓库的密钥 generic – 通用的服务密钥 tls – 创建证书 StatefulSet的建立和使用在一定程度上实现了有状态的管理，但是依旧需要写成管理脚本，注入到Pod中。 CoreOS – 提供了 Operator相关的功能用来完善有状态的应用的部署。 两类不同的Pod Cattle Pet 最早叫做PetSet， 后面改成StatefulSet。 StatefulSet一般用于管理以下特性的组件： 稳定且有唯一的网络标识符；必须保持Pod的名称和地址稳定持久有效； 稳定且持久的存储； 有序平滑(Graceful)的部署及扩展；启动的时候Pod1 - Pod8； 有序平滑(Graceful)的终止和删除；关闭的时候Pod8 - Pod1； 有序的滚动更新；有顺序的进行Pod的更新； 有三个主要的部分； 1. Headless Service - 类似于Redis，提供一个headless的服务，来确保每一个请求直达后端的pod，可保持pod的接入点稳定且不发生变化。 2. StatefulSet Controller - 需要一个控制器来进行Pod的管理和控制，保持Pod的生命周期，即使Pod被终止也需要在启动后保持和之前一样的Pod信息。 3. Volume Claim Template - 由于有状态的服务不能同时使用同一个PV，所有的节点存储的数据各不相同，所以不能提供一个PVC&PV。因此提供了申请PV的模板，每个Pod提供一个独立的存储卷用来做独立存储。 对于StatefulSet来说，确保所有的Pod名称稳定有效不可变动。大多数有状态的副本都会使用持久存储，多个Pod能不能共用同一个存储？ 不能，每个Pod必须使用不同的存储。 所以，需要定义PV，定义PVC模板，定义Pod，定义Stateful控制器，定义headless服务这几种。 定义StatefulSet的YAML文件--- apiVersion: v1 kind: Service metadata: name: sts-headless-svc labels: Service: sts-headless-svc spec: ports: - port: 80 name: sts-headless-svc clusterIP: None selector: service: sts-headless-svc --- apiVersion: app/v1 kind: StatufulSet metadata: name: sts spec: serviceName: sts replicas: 3 selector: matchlabels: service: sts-headless-svc template: metadata: labels: service: sts-headless-svc spec: containers: - name: sts-container image: ikubernetes/SOMEIMAGE'SNAME ports: ...

K8S Service资源的笔记以及Ingress资源的笔记。 k8s的serviceservice的模型： userspace(kube-proxy), iptables, ipvs Service的类型请求发送的过程： Client –> Node’s IP:Node’s Port –> Cluster’s IP:ServicePort –> PodIP: ContainerPort Service的类型： ClusterIP是将提供服务的Pods统一建立一个集群内部的可访问接口，为集群内部的服务提供入口，PodsPort to ClusterIP:Port. NodePort是将Node的端口映射出去的方式，每个节点各自对外提供一组IP:Port用来对外提供服务 - PodsPort to NodePort. LoadBalancer使用LBaaS的方式对外提供服务，共有云环境可用，例如阿里云。 Externalname可将外部的服务引入到集群的内部，需要提供的字段是外部网络的真正的DNS服务的CNAME（FQDN）。 HeadlessService是不提供ClusterIP，可将ServiceName直接解析到PodsIP。 上面的每一个类型的服务都是顺序增强的，也就是说，基础的模式是 ClusterIP 。 HTTPS的处理和思路 启动一个Pod对HTTPS进行卸载和LB 如果需要对HTTPS进行配置，Kubernetes本身提供的Service不能提供7层协议的卸载(将HTTPS卸载为HTTP与后端做通信以及数据交换),那么可行的方案是，建立一个新的Pod，例如nginx，由nginx-pod进行HTTPS的代理和卸载操作，但是这样的话就会有如下的流程： User Request –> LBaaS(LB) –> Service - NodePort(LB) –> Pod - nginx proxy(LB) –> BackendPods PROBLEM: 在这种情况下，用户的请求需要进行两次负载的转换才可以到达Pod，开销太大。 将Nginx的Pod与Node的Net名称空间进行共享 使得Nginx的Pod直接工作在Node的网卡级别上。免去了K8S的Service中间的一次转发。为了避免单点的故障，可将DeamonSet将Pod运行在一部分节点上。 Ingress Controller可以用于处理和卸载HTTPS协议的负载均衡器Pod控制器。 K8S四个附件： DNS， DashBoard， Ingress Controller, heasper。 如上的那种NginxPod，衍生为Ingress Controller， 独立运行的应用程序组成，不属于Controller Manager。通常由4种选择：HAProxy，Nginx，Envoy，Traefik。微服务使用更多的是Envoy。 Ingress资源定义IngressController如何建立一个期望的前端（Nginx URL Rewrite），同时定义了期望的后端(Upstream servers)，更新后端负载Pod的信息。 Ingress类型Ingress资源的定义格式使用NginxServer的方式进行配置IngressPod apiVersion: Extensions/v1beta1 kind: Ingress metadata: name: ingress-nginx namespace: default annotations: kubernetes.io/ingress.class: "nginx" spec: rules: - host: nginx.test.local http: paths: - path: backend: serviceName: svc-nginx servicePort: 80

集群无法删除Namespace解决方式。 Namespace 无法删除 始终处于Teminating强制删除的方法，临时方案。 将名称空间的配置文件导出。kubectl get namespace testtest -o json > tmp.json 编辑这个临时文件。vim tmp.json 删除spec字段中的值。 "spec" : { "finalizers" : [ # delete this line. "kubernetes" # delete this line. ] # delete this line. } ``` 使用另一个terminal， 运行本地的proxy， 连接到API server。 kubectl proxy --port=8888 通过ApiServer进行删除 curl -k -H "Content-Type: application/json" -X PUT --data-binary @tmp.json http://127.0.0.1:8001/api/v1/namespaces/[NEEDTODELETENS]/finalize; 这里面http的调用路径在 ： tmp.json的 api 字段中。 运行结果返回NameSpace的相关信息应该就是删除了。 Namespace删除卡住的原因 Solution From Github: https://github.com/kubernetes/kubernetes/issues/60807 是某些服务的问题导致了无法删除掉相关的NS kubectl get apiservice | grep False kubectl api-resources –verbs=list –namespaced -o name | xargs -n 1 kubectl get -n [NEEDTODELETENS] kubectl delete apiservice v1alpha3.kubevirt.io 其实是这个apiservice影响的，他的状态不正常导致的NS删除的时候卡住，删除这个apiservice就可以了。

昨天晚上尝试使用阿里云的时候出现问题 ，阿里云的k8s源安装的时候报错，无法正常通过yum安装。内网正好放了一台Cobbler，所以直接从Cobbler同步阿里的repo过来放到内网，防止这个事情再次发生。 Cobbler是什么 Cobbler是一个免费开源系统安装部署软件，用于自动化网络安装操作系统。 Cobbler 集成了 DNS, DHCP,软件包更新， 带外管理以及配置管理， 方便操作系统安装自动化。Cobbler 可以支持PXE启动, 操作系统重新安装, 以及虚拟化客户机创建，包括Xen, KVM or VMware. Cobbler透过koan程序以支持虚拟化客户机安装。Cobbler 可以支持管理复杂网路环境，如创建在链路聚合以太网的桥接环境。 FROM Wikipedia Cobbler Repo的建立k8s的源，Cobbler直接建立的同步不可以是因为k8s的目录结构和一般软件源的结构不同。（开始以为阿里云会一直保持带有Pool文件夹的那个结构， 今天早上看到结构已经和普通的yumrepo一样了，记录一下出现这种问题怎么办好了。）其实解决的方案就是手动同步，使用Cobbler进行源的发布。其实也就是httpd发布出去。 建立阿里云的源[root@cobbler /]# cat <<EOF > /etc/yum.repos.d/kubernetes.repo [kubernetes] name=Kubernetes baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/ enabled=1 gpgcheck=1 repo_gpgcheck=1 gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg EOF [root@cobbler /]# mv kubernetes.repo /etc/yum.repos.d/kubernetes.repo [root@cobbler /]# yum clean all [root@cobbler /]# yum makecache [root@cobbler /]# yum repolist # 在repolist中记录repoid 手动同步源[root@cobbler /]# reposync -n --repoid=kubernetes -p /var/www/cobbler/repo_mirror/ --allow-path-traversal 手动将已经同步好的目录创建为repo[root@cobbler /]# createrepo /var/www/cobbler/repo_mirror/kubernetes/ 最后编辑一下自己的kubernetes.repo源文件，只指向本地的源就可以了。

k8s笔记YAML格式定义资源。 通过YAML定义PodsapiVersionkubectl api-versions查看所有可用的组名apiVersion:[Group/Version] Kind 资源类别Metadata 元数据 name: uniq Key namespace labels Key-Value annotations SelfLink: 资源引用的链接API格式：/api/group/verison/namespaces/namespace/type/name Speckubectl explain pods.spec可使用命令查看：定义用户期望的目标状态。 Status自动维护即可 ，不需要更改。 简单的YAML实例apiVersion: v1 kind: Pod metadata: name: myapp-pod labels: app: myapp version: v1 spec: containers: - name: app image: nginx - name: php-fpm image: php-fpm 对Pods进行标签操作 查看标签kubectl get pods –show-labelskubectl get pods -l LABEL_NAME –show-labels 增加标签kubectl label pods pod-demo KEY VALUE 修改标签kubectl label pods pod-demo KEY VALUE –overwirte 指定selector选择标签 - 等值关系， 集合关系的标签选择器。kubectl get pods -l release=stablekubectl get pods -l release!=stablekubectl get pods -l “release in (v1, v2, v3)”kubectl get pods -l “release notin (v1, v2, v3)” 许多资源支持内嵌字段，matchLabels(直接给定键值) ， matchExporession(基于给出的表达式进行选择)。常用的操作符号，In ; Notin ； Exists；NotExists； Pod的生命周期 初始化容器init c(初始化主容器的执行环境)，可以有多个，串行执行，直到最后一个init c执行结束。 main c在所有的初始化完成之后开始启动，在容器的运行时间与main c的执行时间基本一致；main c刚刚启动之后，可以手动执行Poststart；结束之前可以进行Prestop； 在Pod运行的过程中，提供Pod的Liveness probe； 提供Pod的Readiness probe。 常见的Pod状态： Pending： 挂起，调度尚未完成； Running： 运行状态； Failed： 失败； Succeeded： 成功； Unknown: kubelet失去联络或者无法获取Pod信息时； 创建Pod的阶段： 创建提交请求给API server，目标状态保存到etcd; API Server 请求 Schduler 进行Pod的调度； API取得Pod的调度结果后，将信息记录到etcd； Node节点获取到API server上的Pod状态更新后，开始按照调度的信息进行Pod的建立。 Pod生命周期中的重要行为： 初始化容器： init container ; 容器探测： liveness ,readiness; 容器的重启策略： restartPolicyAlways, OnFailure, Never; 三种策略中默认的设置时Always. Pod的终止过程： 发送term信号， 默认等待30s，如果30s还未终止就强制终止。 存活检测可通过三种类型进行探测： ExecAction, TCPSocketAction, HTTPGetAction;