aws的各种坑-戊

太久没更新了，倒不是因为别的，而是因为有些小问题没开case后来也慢慢解决了，又没及时做记录。 这次是遇到个跟S3有关的事。背景如下： 业务那边时不时会从第三方厂商拿个固件文件，由我这边放到S3，并且每次放的时候要把这个文件的md5拿出来也放到S3，追加到一个list文件里。 传固件文件到S3 改S3上固件文件的acl设为公开可读 算固件文件的MD5 把list从S3拖到本地 把固件文件信息以及

aws s3 etag multipart_threshold

aws的各种坑-丁

翻了翻之前的case，想起原来遇到的一个问题，估计短期内也不会解决。个人觉得这种问题属于“不重要且不紧急”。 大概意思是，自己创建的eks集群，希望授权另外的IAM用户访问，默认情况下是按照这个link进行处理：管理集群的用户或 IAM 角色 – Amazon EKS 这个链接从头到尾没有特意指出跨区域（region）的注意事项，因此个人理解，这里面的用法是适用于所有区域的，比如类似 userna

eks aws aws-auth aws-iam-authenticator iam

aws的各种坑-丙

目前项目的配置文件全部托管在gitlab上，每个环境对应一个库，只使用master分支（存个配置文件而已也用不着搞那么多分支） 运维历来这么搞，历史旧债了，我不是运维所以也没动力推动变革 最开始的需求是，研发在更新了dev环境的配置文件并push之后，能在第一时间得到通知 大体思路：dev的config库被push后，gitlab的webhook去call aws的api网关，调lambda，拿到

aws python3 lambda requests

aws的各种坑-乙

发现eksctl竟然提供了指定启动模版的功能，我可高兴了，仔细一看，还能指定启动模版的版本号，相当于可以用一个模版开多个节点组，每个节点组一种实例（不一定是实例类型不同，也可以是EBS不同，key不同，详细启动信息不同） 这人啊，乐翻了天之后就容易乐极生悲。光顾着看新功能没仔细对着文档咬文嚼字，傻乎乎的去指定aws定制的eks节点ami，又在高级详细信息里手动echo了一个daemon.json文

eks aws eksctl

aws的各种坑-甲

坑太多，用甲乙丙丁戊己庚辛壬癸编号还不一定够 挨个从support里扒吧，万一哪天跑了看不到support的记录了岂不是亏了么，留在这记录着吧，希望这一举动不会给我惹事 这个case严格的讲应该跟fluentd有关，趁着还算新鲜，记一笔吧，不完全从support里拷贝： daemonset的fluentd在极个别场合（具体怎么个极其特别尚不可知），会往死里吃内存。 因为是按aws在github上的

awk eks k8s