2014年つまり9年前のスコアは725点でした。
先月(2023年6月)に久しぶりにTOEICのListening&Readingのやつを受けました。今回のスコアは755でした。9年で30点アップしました。
ここで計算してみましょう。このままいくといつ満点に到達できるのでしょう。
(990-755)÷30=7.8
9年に一度のペースで受けて毎回30点アップしていたら、あと8回で満点に至るそうです。
今34歳なので、34+(9×8)=106
106歳まで生きていられる気がしませんが、ギリギリ生きててもおかしくない数字ですね。106歳でTOEIC受けにいく元気はなさそう。
このままだと全然点数上がらないことや、受験ペースも上げる必要がありそうなことがわかりました。良かったですね
に行ってきました。 前日に新幹線で長崎入りし、仕事の関係でDay3は参加せず帰ってきました。
これまではプログラミング関係や、情シス関係のイベントへの参加がメインでしたが、ネットワークまわりに強くなりたいので参加してきました。
直近でInteropとJANOG両方に参加したので、分からない話題はだいぶ減った印象があります。しかし利用したことのない技術が多いので、完全にわかったとは言えない程度だなと感じています。手を動かすことで理解を深めていきたいです。
観光の話になりますが、グラバー園や長崎原爆資料館、平和公園、爆心地公園、崇福寺に行けたのでまあまあ回れました。稲佐山や、軍艦島、美術館はまた今度の課題としたいと思います。
こちらの勉強会です。
コロナ禍により発表機会が失われていましたが、大きな仕事をしたので発表機会を作ってもらいました。テーマは、コーディングやIaCでした。Google Workspaceまわりでのコーディングに関して話しました。また、イベントの飲食スポンサーをしました。
発表資料は以下をご覧ください。
完全にベストなタイミングで上記記事が公開されまして、よい反響があったのではないかと思います。
会社Webページも作りましたので、今回の発表内容のようなお困りごとがある方はお問い合わせいただければと思います。
以下の記事にあるように、"1.22 クラスターは 2023 年 6 月 4 日にサポートが終了"する。
https://aws.amazon.com/jp/blogs/news/amazon-eks-now-supports-kubernetes-version-1-26/
そして仕事で1.22をまさに使っているので、6/4までにアップグレードを終える必要がある。
これまでは自分が1人でアップグレード作業をしていたのだが、自分がやり続けることで他のメンバーの成長機会を奪うことにつながると考え、アップグレード作業を手放し他のメンバーにやってもらうことにした。
タイミングがいいのか悪いのか、これまでスムーズにいっていたアップグレード作業でいくつもどハマりしたので、未来の自分を助けるためにもメモを残しておく。
eksctlでnodegroupを使っていて、アップグレード作業の際にはnodegroupをもう一つ作り、古いnodeをdrainして、drainが完了したら古いnodegroupを削除するというのがアップグレード作業のおおまかな流れだ。
まず、eksctlで新しいバージョンのnodegroupを作ろうとしたが失敗した。
amiFamilyの指定が必要になってたことと、Amazon VPC CNI plugin for Kubernetes Amazon EKS アドオン(以下、CNIと表記)が古く新しく作ったnodeがhealthyにならなかったことが原因だった。
CNIのバージョンアップして、新しいバージョンのnodegroupを作れるようになり、古いnodeをdrainしようとしたときに、Throttlingが起きてdrainできない事象が発生した。詳細としてはkubectl get podしたときに、cronjobが作成するpodが大量に残っていたことでdrain起因の新たなpod作成に失敗していたことが原因のようだった。この時にすでにkube-proxyがうまく動いてなかったのだろう。
これは作業前の検証環境の状態確認が甘かったというか適当だったところなので反省しかない。
pod全て消してもdrainに失敗するので調べたところ、kube-systemのpodたちもうまく動いてなかった。aws-nodeはReadinessやLivenessのprobeでエラーがでていた。よく見ると、probeでgRPC通信が失敗していた
Readiness probe failed: {"level":"info","ts":"2020-06-16T15:34:23.817Z","caller":"/usr/local/go/src/runtime/proc.go:203","msg":"timeout: failed to connect service \":50051\" within 1s"}
aws-node Readiness probe errored: rpc error: code = Unknown desc = failed to exec in container: container is in CONTAINER_EXITED state
ここまでやって、kube-proxyが落ちていることに問題があるのでは？と気がついた。
kube-proxyは、ImagePullbackoffで落ちていた
ECRからImage取ってくるときに、no such hostと出ていたので通信がおかしいことがわかった
AWS公式のトラブルシューティングガイドを見ても全部正常だった
https://repost.aws/ja/knowledge-center/eks-ecr-troubleshooting
eksctl utils update-kube-proxy -c <cluster-name> --approve
をしたら、container imageのURLに、 region-code って入ってたせいでDNS名前解決に失敗していて、ImagePullできていないことがわかった。こんな感じのimageになっていた。ap-northeast-1が入るべきところにregion-codeという文字列が入ってしまったら名前解決できないのは、それはそうだねという感じ。
--region を渡さなかったからこうなった？まだよくわかっていないところ。
image: xxxxxxxxx.dkr.ecr.region-code.amazonaws.com/eks/kube-proxy:v1.23.17-eksbuild.1
daemonsetをyamlに吐き出して、region-codeをap-northeast-1に書き換えたらkube-proxyがうまく動いた。
kube-proxyがうまく動いたら、aws-nodeやcodednsもうまく動くようになった。
一度のアップグレード作業でいくつバージョンをあげるのがいいのだろう。
ECSでつくらないの？というのはもっともな質問であると思う。しかし、このサービスのインフラを作る時にパッと手が動くのがEKSであった。このような苦労があるならECS化したい気持ちが芽生えつつあるが、そこまでの工数割けるのか？というところはまだ具体的に考えられていない。
他の人に運用を渡そうとした途端にこのようなことになった。たくさんの失敗を経験できたので、まあよかったのではないだろうか。検証環境があって本当に良かった。
出張帰りの電車の中で、スマホで一気に書いた記事なので、前提条件などいろいろ雑になっているかもしれない。間違った認識により適当なことを書いているところがあるかもしれない。そのようなところを見つけたらご指摘ください。
