はてなブックマーク

面倒なAthenaのパーティション更新作業が不要になる、パーティションプロジェクションという機能が静かにそして力強くリリース(2020年5月21日)されました。 今まで Athenaは新しいパーティションを認識させるための作業が必要で、 定期的にALTER TABLE ADD PARTITIONやMSCK REPAIR TABLEを実行したり、Glueクローラーを実行させる必要がありました。 ALTER TABLE ADD PARTITIONやMSCK REPAIR TABLEを定期的に実行させるためには、Lambdaを使ったり自前の仕組みを用意する必要があり面倒です。 Glueクローラーは手軽ですが、料金が高いです。(1分しか動かなくても10分の料金が取られるので1時間に1回動かすと、 0.44USD/h * 1/6 * 24 * 31 で クローラー1個に月$54.56かかる) 「パー

Pod QoSクラスとは Resource LimitはNodeのCapacityを超えて指定することができる。 もし、pod AがNodeのメモリ90%を使用していて、pod Bがメモリ50%を使用しようとした場合、どっちのコンテナをkillすべきだろうか？ メモリを確保できないからpod Bをkillすべきか？それともpod Aをkillしてpod Bを動かせるようにすべきか？ それは言うまでもなく状況による。 Kubernetesにはどのpodをkillするかを判断するために、Podに優先度をつける仕組みがあり、Quality of Service(QoS)クラスと呼ばれる。 優先度が低いQoSクラスをもったpodからkillされる。 Kubernetesは3つのQoSクラスを提供する。QoSはpodに対して自動的に付与される(人が手動で指定するものではない)。 BestEffort

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Resource Requests Resource Requests とは podをデプロイする時に必要とするリソース(CPU/メモリ)を指定することができる仕組み。 ただしpodは指定したresource requests以上のリソースを使うことができる。(リソース使用量の制限はlimitを使う) またその指定したリソースがそのpod用に確保されるわけではない。 あくまでpodをデプロイ時にそのリソース量が空いているかをチェックするためのもの。 ポイントとしてはpodをデプロイするときに、nodeのリソース使用量は見ないで、resource requestsをみてデプロイが行われる。 なので、nodeのリソース(CPUやメモリ)の使用率が100%でも、resource requestsに空きがあればデプロイされる。空きがないnodeにはデプロイされない。 たとえばメモリ1Gのnodeが

TaintsとTolerationsについて Kubernetesには最初、特定のnodeに特定のpodをscheduleする方法としてnode selectorを使う方法があった。(node selectorの他にも特定のnodeに特定のpodをscheduleするための仕組みとしてNode Affinityがある) しかし後からもっと柔軟にscheduleするためのメカニズムが導入された。 それがTaintsとTolerations。 (taintは"汚れ"という意味。tolerationは"容認"という意味。つまり"汚れ"を"容認"できるならscheduleできる仕組み) TaintsとTolerationsはNode SelectorやNode Affinityと似ているが性質は正反対で、 Node SelectorやNode Affinityが特定のnodeに特定のpodをsch

PodのHorizontal Pod Autoscaling(水平podオートスケーリング) podのHorizontal pod autoscaling(水平podオートスケーリング)とは、podの負荷に応じて自動的にpodの数を増減させることを指す。 HorizontalPodAutoscalerリソースを定義することで水平オートスケーリングが可能になる。 まずDeployment, ReplicaSet, ReplicationController, StatefulSetはscaled resource objectと呼ばれる。 これらがauto scalingが可能なリソース。 HorizontalPodAutoscalerリソースの定義例: apiVersion: autoscaling/v2beta1 kind: HorizontalPodAutoscaler metadat

Node Affinity taints/tolerations(参考)は特定のNodeにPodをscheduleされるのを避けるための仕組み。 それに対してNode Affinityという仕組みは、Podを特定のNode集合へscheduleするための仕組みだ。 特定のNodeにPodをscheduleするための仕組みとしてはnode selectorがある。Node Affinityはnode selectorよりももっとパワフル。 Node AffinityはNodeのlabelとして設定する。 そして(node selectorはpodにselectorを設定したが、同様に)Node Affinity ruleはpodに設定する。 podのNode Affinity ruleにnodeのlabelのNode Affinityがマッチした場合、そのnodeへpodがscheduleさ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

RBACとは RBAC(Role-based access control)とは、役割ベースのアクセス制御機能。 RBACリソースは4つのリソースがある。RoleリソースとClusterRoleリソースとRoleBindingリソースとClusterRoleBindingリソース。 RoleとClusterRoleは、どのリソースにどんな操作を許可するかを定義するためのリソース RoleBindingとClusterRoleBindingはどのRole/ClusterRoleをどのUserやServiceAcctountに紐付けるかを定義するためのリソース。 ユーザは以下のようにkubectl config set-credentialsを使って作成できる kubectl config set-credentials alice --username=alice --password=pa

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

APIを作る機会が増えてきている 例えばマイクロサービス間はAPIでやりとりすることが多い。 外部のサービスもだいたいAPIでやりとりする。 社内APIもいくつかあるが、いざ使おうとなるとどんなリクエストを送るべきなのか、またどんなリクエストが返ってくるのかを調べるのが面倒。 API ドキュメントを書くのは大変 フォーマットは？ Markdown? HTML? Text? エンジニア間で書き方がバラバラにならない？ そのドキュメントの内容は今も正しい？ そもそも書くのが面倒… ということで、いい感じのAPIドキュメントツールがほしい API ドキュメントツールに求めること その1 ドキュメントが書きやすい ドキュメントが読みやすい ドキュメントがGitで管理しやすい リクエスト情報、レスポンス情報が見やすい curlですぐに試せるようにサンプルがほしい ドキュメントとコードに乖離がないよう

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

メール本文のデコード まずgmailの"メッセージのソースを表示する"をクリックする。そしてメール本文をコピーする。 encodingがbase64でcharsetがUTF-8の場合