以下の記事にあるように、"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化したい気持ちが芽生えつつあるが、そこまでの工数割けるのか？というところはまだ具体的に考えられていない。
他の人に運用を渡そうとした途端にこのようなことになった。たくさんの失敗を経験できたので、まあよかったのではないだろうか。検証環境があって本当に良かった。
出張帰りの電車の中で、スマホで一気に書いた記事なので、前提条件などいろいろ雑になっているかもしれない。間違った認識により適当なことを書いているところがあるかもしれない。そのようなところを見つけたらご指摘ください。
RubyKaigiに行った自分は気持ちやモチベーションが高まっており、日々の開発や勉強といった研鑽をやっていくぞというモードになっている。
しかし、同僚たちとの日々の開発や勉強にも良い影響を与えようと考えると難しくなる。そして、たぶんそれはおこがましいことのようにも思う。自分しか変えられないだろうという気持ちがあるからだ。
技術者文化をつくり、育てるのは難しい。一朝一夕ではどうにもならない。自分がやっていっている姿や、自分が楽しんでる姿を見せつつ巻き込んでいけば、どうにか良くなっていってほしい。
長野県松本市で開催されたRubyKaigi 2023に参加してきました。
技術を学び、人と話すことはこんなにも楽しいのだったな。と思い返すことができました。COVID-19により失われた数々の体験を取り戻していく旅だったように思います。
以下の記事に良いことが書いてあって完全同意です。技術カンファレンスで摂取できる栄養素は大変貴重だと思います。しかもこれはオンラインでは摂取もしくは吸収の効率が落ちるように思います。
技術はやっぱり面白いし，この界隈にいる人たちの熱量からしか得られない栄養素があるなと思う
自分は最近 "コードを書く情シス"をキャッチコピーにして仕事をしています。プログラミング言語のカンファレンスに参加することは自分にとって意味のあることですし、読み書きしやすいRubyであることにも、会社での教育上の意味を見出しやすいものと思っています。何か、情シスへの支援をする仕事の中で共通する問題について、解決策を提示できそうなところがあればコードを書いてOSSにしたいなという気持ちはあります。
体力気力と、スマホのバッテリー残量を見つつ無理そうだったらホテルで休む。ホテルで配信を見る。元気になったら会場に戻る。という繰り返しでした。 まさに以下の記事で書かれている "廊下" を楽しむためには体力気力が満ちていることがとても重要ですね。
RubyKaigi 2023はとてもいいイベントでした。しかし楽しい、面白い、いいイベントで済ませて良いのでしょうか。自分は今そこを今考えているところです。自分はこれまでRubyKaigiの当日スタッフ、レポート班をやってきました。その流れで、るびまの編集にも関わっていた時期がありました。
【十周年記念企画】 Rubyist Magazine へのたより
https://blade.ruby-lang.org/ruby-list/49732
そしてありがたいことに地域RubyKaigiのオーガナイザーも経験することができました。
http://tokyo10.rubykaigi.info/
なにもわからないけど、子育てがもう少し落ち着いたらRubyコミュニティで何かできたらいいなと思っています。
これを読んでいる方はRubyKaigiという場、コミュニティ、技術のどれに興味があるのでしょうか。自分は場とコミュニティです。昔から変わっていません。 もし今回RubyKaigiに参加してみていいイベントだなと思ったなら、当日スタッフとかをやってみるとよいでしょう。一般参加者のときとは、違った見え方があるし、いろいろな方と仲良くなりやすいです。Deep Diveしたほうが圧倒的に楽しいと思います。るびまや、日本Rubyの会の活動を知り、今活動されている方々とお話するのもよいでしょう。
自分のことになりますが会社の経営層になり、一般社団法人LOCALの理事をしています。
こうした背景からか、"一般社団法人の運営と継続" というテーマに対しては人よりも気持ちがあるように思いました。今回のRubyKaigiでこの気持ちに気がつく事ができました。組織を存続させていくのは大変ですし、ボランティアベースの組織運営は特定の人が頑張る形になりがちです。いつだって誰かの助けを欲していると思います。 あなたがRubyに対してお客さん以上の気持ちを持っているなら、何かできるかもしれませんね。知らんけど。
運営に関わられたみなさま、現地でお会いしたみなさまありがとうございました。大変楽しいKaigiでした。また行きます。
さて、RubyKaigi自体の話はここまでで、ここからは観光などの話になります。
今回はAttendeeとして参加しました。すべてのセッションを聞ける体力気力理解力すべてが足りていないので、合間合間で観光することで癒やされていました。 松本市美術館、松本城、川、レストラン鯛萬、草庵、あがたの森公園、信州大学の松本キャンパスあたりに行ったのですがどれもよかったです。松本市とてもいいところでした。いくつか行けなかったところがあるので、次回以降の宿題としたいと思います。
鯛萬というレストランに行きました。大満足でした。もともと、鯛萬という料亭だったそうです。フランス料理店でなぜ "鯛" という文字が入っているのか不思議と思いお店の方に聞いてみたところ教えてもらいました。
シェアサイクルがあることに気がついたので、こちらのサービスを使いました。大変便利でした。 www.hellocycling.jp
知っている内容が多かった。教科書という名前の通り、リモートワークを初めて取り入れるときとかに読むのがいいのかもしれない。今の自分に最適な本という印象ではなかった。読書メモも短めだった。
ワークライフバランスから、ワークインライフへの移行によってリモートでのマネジメントには 「生活の中で仕事に集中できる環境をつくるという、メンバーの新たな負荷を理解すること」 という要素が加わった
自組織における生産性や成果を定義し、把握できる状態にするとよい
メンバーはルーティンの業務が問題なくできていれば良いと考えがちです。一方で経営層やマネージャーは新規顧客の開拓や、改善提案など、新たなチャレンジを行ったり、現状をレベルアップする動きが鈍っていると仕事が順調に進んでいないと考えることがある オフィスワークで感じていた会社や組織とのつながりを別の方法で感じてもらう リモートワークでメンバーが何をすべきか、方向性や成果をしっかり伝え、確認する 今の会社でなくても活躍できると感じているメンバーに、会社やマネージャーとして何を提供できるかを考える
リモートワークによって生活の中に仕事が取り込まれたことによって、働きやすい環境を整えることが、働きがいにつながるという関係性に変化した
1周囲を安心させる責任とは、上司や周囲が見守ってなくても仕事を進め、成果を上げてくれるであろうという安心感を抱けるようにすること。成果を上げることと、ほうれんそうに大別される 2仕事環境をデザインする責任 自分を理解し、一番能力を発揮できる仕事の組み立て方と一日の過ごし方を設計することも含まれます 3心身の健やかさを維持する責任
良い本だと感じた。タイトルの通りの内容だったと思う。アジャイルまわりの前提知識があると読みやすくなるのは言うまでもないだろう。
"最適化という名の呪縛"という言葉と考え方を得られたのが、本書を読んで一番良かったことかもしれない。
他の本に寄り道する必要があったので、読了までかなりの時間を要してしまった。本当なら一気に読んでしまいたいテーマだったのだが。
以下は読書中のメモだが、冗長な表現と思ったところをバッサリとシンプルに書き直したりしているので、本から一言一句コピーした文言ではなく、オリジナルと乖離してる可能性があることに注意されたい。また、本の全てをメモしているわけではなく、自分が必要だとか、良さそうと思った部分を抜粋している。
組織は顧客の状況や置かれている前提が変容している可能性を常に検知しようとしなければならない。この探索に時間を投じていない組織は顧客からやがて相手にされなくなる。いつまで経ってもサービスの質が変わらない、変化に取り残された業界。(になってしまう
自分たちの組織を取り巻く環境、社会に対して立ち遅れていると感じることは何か？
デジタル利活用を前提とした社会や環境に適した組織、組織活動とはどのようなものか？
あなたの組織で探索しなければならないこととは何だろうか？
新たな取り組みを始めようとしたときに、真っ先にぶつかる組織の制約とは何か？また、それはなぜ起こると考えられるか？
思考や判断、行動を縛り付ける呪縛の本質は最適化
方法の最適化が減点主義路線となるのは自明だ。
方法の最適化
標準からの逸脱は許されない。誰がやってもアウトプットが同じになるので外部へ委託できるようになる。最適化は外部の組織にまで広がり硬直していく。外部へプロセスを委託すると自組織から、その分の理解を切り離し、消失させることになる。仕事全体への理解が分断されるので、やってることの中身がわからないことが増える。仕事の説明は厚く長くなっていく。この時点で探索の志向性とは完全に直交する
関係間で間違いを起こさないようにするには、情報の受け渡しが少なく済むようにすればいい。チームを超えた絡みが減るようにきっちり分業に徹するようになる。独立した状態を作っていくと、仕事が増えた場合にどう対処するかが問題になる。そして兼務が増える。兼務により仕事の仕掛りが増え、一人の人間がさばける仕事量は相対的に減り、組織全体としての速度を落としていく。
間違わないためには、迷わないようにしなければならない。使うツールも標準で定めておくべきだ。道具の最適化とは固定化ではない。常に状況に適した道具とは何かと見直し、より効果と効率の良いものにアップデートしていくことである。方法や体制に比べてツールはさらに足が速い。時とともに時代遅れになり、自組織の効率性を知らぬ間に落としているということがざらにある。
3つの最適化で鍛え上げてきたプロセスは、何が正解かわからない問題には手も足も出ない。得られたインプットから期待するアウトプットまでいかに正確に早くたどり着くかの手順でしかないのだから。目指す方向性がわからない中で、標準を守り抜いたところで「間違ったこと（役に立たない、意味がないこと）を正しくやる」域を出ることはない。こうした事態に直面して、極めて芳しくない結果を評価するのだから、当然仕事の進め方自体を見直す必要に迫られる。しかし「間違わない」ための強化が取られる。「やっていることがそもそも正しいのか？」という問い直しではなく、「やっていることが正しくなるための改善」が選択される。評価基準も評価者のメンタリティも変わらないとしたら、結果の評価も変わらないことになる。
組織は戦略に従い、戦略は意図に従う
意図とは組織が存在する意義に値する。組織が自ら定義するだけでは成り立たない。社会や環境と適合した意図でなければ、その存在が受け入れられないことになる。ゆえに、意図に立ち返り、どうあるべきなのか、どうありたいのか、「われわれは何者なのか？」を自ら問い直す必要がある。もちろん、組織の意図は社会や環境とのキャッチボールとなるから、継続的に立ち返らなければならない。これまで、誰も意図や方針の根本まで問い直す機会がなかったとしたら。組織の芯を捉え直す力が弱く、存在さえしない可能性がある。かくして組織は不思議な状態を現し始める。芯（これからの意図、それに即した方針）がなく、外周の現場活動のみが問題を抱えて右往左往する、まるでドーナツのような組織。
厄介なのは標準をただ書き換えればよいというわけではないということだ。言語化された表記を超えて、時間とともに組織の中で育まれてきた方針、戦略は紙ではなく人に宿る。人と人の間の「認識」として形成され、組織の「意図」をさえ塗り固めていく。私たちは、人の「意識」の更新に挑まねばならない。ある意味で「遺産」とも言える。組織の「今」を背負った者たちには存在しない「記憶」が、時を超えて私たちを方向づけ続ける。これまでの「方針」では直面する状況に勝ち目がないことを、もっというとこれまでの意図も組織を取り巻く社会環境ともはや合致していないことを、誰もがほぼ気づいているというのにだ。
この不本意な旅を続けているのは、「標準」と「最適化」に代わるものを持ち合わせていないからである。
目の前の現実を正しく解釈し、適した意思決定と行動をとる。そのためのすべを1つのチームや部署にとどめるのではなく、経営から現場にいたるまで新たに宿さなくてはならない。
アジャイルはソフトウェア開発の文脈において、「探索」と「適応」のために確認され育まれてきた智慧なのである。
ソフトウェア開発のアジャイルが、組織運営に適用できるのか？実はそのままではうまくフィットしないところがある。運用の仕組みレベルでの工夫が必要であり、「最適化」のメンタリティが行く手を阻む。
個々人が分断された状態で、アジャイルのタイムボックスを回しても欠落感を感じることになる。自分の手元の仕事を超えて他者とともにあろうとする理由がないのだ。共通の目標などがない。「われわれはなぜここにいるのか」への回答がないのだ。
ソフトウェア開発は共通の目標を作りやすい。なぜ目標設定の方法であるOKRがもてはやされるのか。自分たちのあいだで認識し、作用できるObjectivesが存在しなかったからではないか。
・方法について過度な最適化が起きていないか？遵守するのが目的になっている標準は存在しないか？
・体制について過度な最適化が起きていないか？分業により同僚が何をしているのかまったくわからないということはないか？
・道具について過度な最適化が起きていないか？
・組織の意図と方針は社会や環境に適したものになっているか？
・組織の中で当たり前の認識になっていることに何があるだろうか？
探索と適応を繰り返し、そこから効率良く勝てる道筋を見極め、最適化へと進む。大事なのは最適化から再び探索へと戻るルートを開拓することだ。
ふりかえりだけでは、目先に焦点が向く。
むきなおりで意図的に目線を上げて遠くを見るようにし、到達したいところと現状との比較を行うようにする
むきなおりこそ、最適化への最適化から道を外すための最初のきっかけになる
それぞれの仕事の前提に共通の意図をおかねばならぬ
関心は意図によって近接しうる
関心は組織をめぐる血液となる
私たちは何もなくとも定期的にお互いの状況を同期し、共に目指す方向性を確かめることをしなければ、ともにあるという状況を、つくることができない
