gashirar's blog

ウイスキーがすき/美味しいものがすき/k8sがすき

Red Hat 認定スペシャリスト試験 - OpenShift Administration -

受験記 技術 技術-Kubernetes

はじめに

Red Hat 認定スペシャリスト試験 - OpenShift Administration -をリモート試験で受験し合格しました。
その時の忘備録です。

試験の詳細についてはこちらをどうぞ。

www.redhat.com

リモート試験環境の準備

下記に日本語ガイダンス資料があるので、こちらを確認してください。

https://www.redhat.com/cms/managed-files/Remote-Exam-Pilot-Windows-jp.pdf

リモート試験のLive USBの作成

ガイダンス通りの手順を実施すればハマるようなポイントはないと思います。
Live DVDにできないかと試してみましたがFedoraMediaWriterでは作成ができませんでした。

利用した端末

自分の場合は下記のような構成でした。

  • ノートPC（内臓カメラ付き）
    • CPU: Core i5 3210M 2.5GHz/2コア
    • Memory: DDR3 PC3-10600 8GB
    • Display: WXGA(1366 x 768)
  • 外付けカメラ（ケーブル長が1m以上）
  • 有線のマウス（無線はNG！）

セキュリティ等諸般の事情により社用ノートPCを使うことができなかったため、かなり古い私用ノートPCを使いました。
一応上記で受験はできましたが、画面の解像度が低いため文字が読みづらかったです。

デスクトップPCで受けることも考えたのですが、筐体を机の上に置く、または360度から確認できる状態にしておくなどの条件があったためやむなく上記環境で実施しています。

机の上には試験に関係するもの以外は何も置けませんのでキレイにしておきましょう。
普段利用している机の上にはいろいろなケーブルが固定されていたりして整理するのが大変だったため、余っていた机を使って環境を整えました。

要綱に書いてありますが、無線のマウスは利用できず有線のマウスのみ可能です。また有線のキーボードも利用できますが、その場合はノートPCの画面を閉じて別のディスプレイを使う必要があります。（何故？）

試験前の確認

Live USBで起動後、言語設定やキーボード設定をしたのちにCompatibility Checkが行えます。
試験の再スケジュールは24時間まえであれば可能なので、それよりも前にチェックを済ませておくことをお勧めします。

EX280

出題範囲は下記の通りです。

www.redhat.com

  • OpenShift Container Platform の管理
  • ユーザーとポリシーの管理
    • 認証用に HTPasswd ID プロバイダーを構成する
    • ユーザーを作成して削除する
    • ユーザーのパスワードを変更する
    • ユーザーおよびグループの権限を変更する
    • グループを作成して管理する
  • リソースへのアクセスの制御
    • ロールベースのアクセス制御を定義する
    • ユーザーにアクセス許可を適用する
    • 機密情報を管理するためのシークレットを作成して適用する
    • セキュリティコンテキストの制約を使用してサービスアカウントを作成し、アクセス許可を適用する
  • ネットワークコンポーネントの構成
  • ポッドスケジューリングの構成
    • リソース使用量を制限する
    • 増加する要求に合わせてアプリケーションを拡張する
    • クラスタノードへの Pod 配置を制御する
  • クラスタスケーリングの設定
    • クラスタワーカー数を手動で制御する
    • クラスタワーカー数を自動的にスケーリングする

出題された問題については言及しませんが、DO280のコースを一通り流しておけば受かる難易度かと思います。
試験中はOpenShiftのドキュメントも確認できますのでそちらも参考に進めましょう。

CKAやCKADではYAMLをｺﾞﾘｺﾞﾘ書くことが多いですが、EX280はそこまでYAMLを書くことはなかった気がします。
OAuth ResourceなどのOpenShiftならではのManifestはある程度覚えておいたほうが良いですが、ドキュメントも利用できますしoc explainである程度確認できると思うので問題ないかと思います。

受験結果

受験後に3日以内にメールで結果が来ます。自分の場合は受験後2時間くらいで来ました。
スコアは下記で、225/300と合格ライン210点をギリギリ超えた感じです。

項目 スコア
Manage OpenShift Container Platform 83%
Manage users and policies 100%
Control access to resources 100%
Configure networking components 33%
Configure pod scheduling 57%

もう少しとれているとは思っていたのですが、Configure networking componentsとConfigure pod schedulingがあまり良くなかったようです。
問題の意図を読み取れないものがいくつかあり「解決手段はいくつかあるけど、なにをやってほしいのかわからん」という状況になったのでそれが結果に出ているのかもしれません。英文にしても正直何を言いたいのかよくわからないものもありました。

おわりに

RedHatの試験ははじめてうけたのですが、EX280についてはCKS/CKADに比べると意図が読み取りづらい問題が多かったように思います。
次はRHCSAあたりを取得しておこうかなと思います。

ウイスキーテイスティング - グレンドロナックとアラン-

ウイスキー-グレンドロナック ウイスキー-アラン ウイスキー

今日のウイスキー

グレンドロナック トラディショナリーピーテッド

グレンドロナック | アサヒビール

スコッチウイスキー「グレンドロナック トラディショナリーピーテッド」発売 | WHISKY Magazine Japan

アルコール度数は48%

以下はアサヒビールの公式サイトからの引用

昔ながらの伝統的なハイランドのピートテッド麦芽を原料に、グレンドロナックの特徴である、シェリー樽熟成の芳醇な香りと味わいを組み合わせることで、非常に珍しいピーテッドウイスキーへと仕上がっています。

アランシェリーカスク

アラン シェリーカスク | Explore our craft philosophy

アルコール度数は55.8%

以下はウィスク・イーの公式サイトからの引用

項目 説明
香り チョコレート、レーズン、マンダリンオレンジ、スパイス
味 完熟イチジク、チェリー、ヘーゼルナッツ、トーストしたオーク

テイスティング

1回目

まずは上記のテイスティングノート等を見ずにやってみました。
2つのグラス（A、B）にウイスキーを注ぎ、銘柄がわからない状態にしてから飲みます。

Aのウイスキー

やわらかい香り立ち。ツンとするような感じはしません。
シェリー樽由来の香りに加えて、焦げた木材のような香り。
味わいではピートが先にきて、ビターな感じが余韻として残っています。

Bのウイスキー

アルコールのツンとする感じが先に来ました。
味わいももう一本と比べるとかなりアルコール感が出ています。
飲んだ瞬間は結構刺激が強いのですが、それ以降は爽やかな感じも。

1回目まとめ

Bのウイスキーのアルコール感がかなり強いので香りの時点で多分Bがアランシェリーカスクかなと。
飲んだ時にAのウイスキーから煙たい感じがしたので改めてAをグレンドロナック、Bをアランと判断しました。（正解）

アルコール度数が結構違うので割とわかりやすい2本だった気がします。

余談

上記の2本はシェリー樽なのですが、先日開封したボウモア10年インスパイアードデビルズカスクもシェリー樽（とワイン樽）だったので軽く飲み比べ。

このボウモアはかなりシェリー樽由来の香りが出ています。若干硫黄のような香りも。
これはワイン樽由来かもしれませんが、味わいもスパイシーで舌がピリピリするような感じが結構出ています。
この一本とくらべると刺激が強いと感じていたアランも割と優しい味わいなのではないかと思ってしまうほど。

2回目

色々な方のテイスティングノートを見つつ飲んでみます。

グレンドロナックの方は蜂蜜などのねっとりとした甘さを指摘している人が多いのに対して、アランはオレンジや柑橘類といった爽やかさがあると指摘している方が多い印象を受けます。
改めて香りを確認してみると、アランの方がすっきりとした感じはしますね。

グレンドロナックの方は時間が立ってくると和風の出汁のような香りも。

感想

主観ですが、どっしりしているのがグレンドロナックトラディショナリーピーテッド、はつらつとしているのがアランシェリーカスクでした。 途中で飲んだボウモアのパンチがかなり強かったので個別にじっくり味わいを確認したいところです。

ウイスキーテイスティング - 新竹鶴NAとNIKKA session -

ウイスキー ウイスキー-竹鶴 ウイスキー-NIKKA session

はじめに

www.whiskylover-diary.com

実際にやってみようともったのでやってみます。

今回のウイスキー

竹鶴NA

竹鶴ピュアモルト｜商品紹介｜NIKKA WHISKY

公式テイスティングノートより

項目 説明
香り りんごや杏のようなフレッシュで甘酸っぱい果実香、トーストやバニラを思わせる甘くやわらかな樽香。
味わい バナナやネーブルオレンジのようなフルーティーさ、軽快でありながらしっかりとしたモルトの厚みやピートのコクが感じられる味わい。
余　韻 ビターチョコのような甘くほろ苦い余韻が、穏やかな樽香やピート香を伴い心地よく続く。

NIKKA session

ニッカ セッション｜商品紹介｜NIKKA WHISKY

公式テイスティングノートより

項目 説明
香り オレンジやりんごのような爽やかな香りとモルトの甘さと香ばしさ。樽由来のおだやかで心地よいバニラ香。
味わい なめらかでクリーミーな口当たり。オークの甘さと調和したフルーティーで軽やかな味わい。
余韻 ほのかにビターな味わいとピートの余韻がゆっくりと広がる。

共通項と差分

  • 共通項
    • 余市原酒と宮城峡原酒で構成されている
    • アルコール度数が43%である
  • 差分
    • sessionにはベンネヴィスなどの海外原酒も含まれている
    • 余市原酒と宮城峡原酒の構成比率の違い（もあるとおもう）

テイスティング

香り

竹鶴、sessionともにりんごのような果物の香りは感じられました。
公式テイスティングノート上では、竹鶴とsessionの香りに大きな差はなく、実際にこれを区別するのは難しそうですね。
香りを嗅いだ瞬間のツンとした感じは若干sessionの方が強い印象。

味わい

竹鶴の方のバナナ感は若干あるようなないような。
sessionは「なめらかでクリーミー」とあるが、竹鶴とくらべると口に入れてからの数秒間にアルコールのピリピリした感じがありますね。

ブラインド

香りではほぼ判別は難しかったです。 味わいがピリピリしていたという点で選んだら正解しましたが、事前に飲まずテイスティングノートベースで考えたら逆を選びそうです。

3/22 追記

初めからブラインドで確認。
香りの時点でピリピリするイメージからある程度判別できました。味わいの方はセッションの方が若干余韻のビターな感じ。
セッションの方が若干アルコールからくる刺激があったのでそれも合わせて判別して正解できました。

改めてですが新竹鶴もsessionも美味しいですね。定価で買えるならかなりオススメしやすい。

Expandersで複数NodeGroupをもつEKSのClusterAutoscalerを制御する

技術 技術-Kubernetes

はじめに

Self-Managed NodeGroupをもったEKSクラスタにおいて、クラスタのオートスケールが起きたときのどのNodeGroupが拡張されるのだろうと疑問に思ったので調査した忘備録になります。

Expandersを使って解決する

下記ドキュメントのPrioritizing a node group or Auto Scaling groupにあるように、ある程度はコントロールできるようです。

docs.aws.amazon.com

Expandersの説明はGithubにあります。オプションは下記記載があるのですが、priceはGKEでしか使えないとのこと。
EKSのドキュメントで提示されていたのはpriorityとleast-wasteですね。

Option 説明
random ランダムに選択（デフォルト）
most-pods スケールアップ時に最も多くのポッドをスケジュールできるNodeGroupを選択
least-waste スケールアップ後のアイドル CPUが最も少なくなるNodeGroupを選択
price コストが最も低く、かつクラスタサイズと一致するマシンを持つNodeGroupを選択(2021/02 GKEのみ)
priority ユーザによって割り当てられた優先度が高いNodeGroupを選択

github.com

こういった部分のチューニングをやる機会は今のところなさそうですが、コスト最適化を考えた場合には選択肢として覚えておいた方が良いかもしれないですね。

テレワーク環境のCO2濃度をGrafanaで見える化する

技術

はじめに

本記事は

  • CO2モニタを使って、
  • GrafanaCloudのGraphiteに情報を送り、
  • テレワーク環境のCO2濃度を「見える化」した

記事になります。

CO2モニタ

今回利用するCO2モニタはこちら、CUSTOMの「CO2モニター CO2-mini」です。

www.kk-custom.co.jp

CO2濃度計と温度計の機能がついているのですが、USBでPCと接続することでデータの取得が可能です。

Graphite

データの蓄積先としてはGrafanaCloudが提供するGrafiteを利用しています。データの閲覧はもちろんGrafanaです。
GrafanaCloudですが、先日Free Tierが発表されており今回のような用途であれば無料の枠で収まります。

www.zdnet.com

構築

Graphiteのアクセス情報を得る

GrafanaCloudにログイン後、トップページからGraphiteのSend Metricsをクリックすると

が表示されます。Basic認証のパスワードは「Generate now」のところからAPI Keyを作成して取得しましょう。

f:id:gashirar:20210201202146j:plain

Graphiteにデータを送る

下記にソースが置いてあります。
main.goの認証情報を書き換えてください。

github.com

Grafanaで可視化する

左側のメニューから Create（+のアイコン） →Dashboard 　→Add new panel を選択し、Datasourceをdefaultからからgrafanacloud-xxxxxx-graphiteを選択し、QueryのSeriesからco2mini/co2を選択したら完了です。

f:id:gashirar:20210201202843j:plain

おわりに

CO2モニタとGrafanaCloudの無料枠を使ってデータの蓄積と「見える化」ができました。

ちなみに、下記はテレワーク環境のAM8時からPM8時の二酸化炭素濃度の様子です。
13時前後に窓をあけて換気をしているのでppmが大きく下がっているのがわかります。

f:id:gashirar:20210201203151p:plain

下記サイトによると学校環境衛生基準には「換気の基準としてCO2は1,500ppm以下であることが望ましい。」とのこと。
自分の部屋はすぐに高めになっているのでこまめに換気した方がよさそうです。

CO2濃度について ：東京都地球温暖化防止活動推進センター

まだまだテレワークは続きそうなので、快適な仕事環境にしていきたいですね。

ウイスキーニュース&最近飲んだもの 20201103号

ウイスキー

ウイスキー関連ニュース

ボウモア30年が毎年数量限定でリリース！

www.thespiritsbusiness.com

2020年リリースは2580本限定で、1本$1850とのこと。

「カードシリーズ」が香港のオークションに登場！

www.whiskyintelligence.com

有名オークションハウスの「ボナムズ」にてカードシリーズの競売が行われます。
2015年と2019年に54本フルセットのオークションが行われたとのことですが、今回は個別ボトルで54本出る模様。

ちなみにボナムズではウイスキーのカテゴリで3つの世界記録を持っているようです。

グレンモーレンジィ12年 マラガウッドフィニッシュ

www.whisky.com

8年バーボン樽熟成で残り4年がマラガウッド熟成とのこと。
日本には入ってくるのでしょうか。ぜひ飲みたい逸品。

羽生蒸留所復活か？東亜酒造、2021年に向け蒸留所建設を進める

prtimes.jp

「シーバスリーガル」の樽で熟成した日本酒が登場！

prtimes.jp

甘くて美味しい限定品「グレンモーレンジィ ケーク」登場！

prtimes.jp

最近飲んだもの

MARS WHISKY 浅葱斑(あさぎまだら)

f:id:gashirar:20201103165123j:plain

2020年9月のマルス信州蒸溜所全面リニューアルを記念して商品化されたメモリアルな1本。
8年以上のモルトとグレーンを合わせたブレンデッドウイスキーとなっています。

エドラダワー [2008] 10年 オロロソシェリーバット for SHINANOYA

f:id:gashirar:20201103164902j:plain

かなり濃厚だったので飲むタイミングは選んだ方が良いですね。樽の感じも結構出てます。

キルホーマン2012 8年 カルヴァドスカスク ウィスクイー20周年記念

f:id:gashirar:20201103164917j:plain

気持ち多めに加水するとほのかにカルヴァドス感がありました。美味。

Kubernetes Admission Webhook覚書き

Kubernetes 技術

はじめに

KubernetesのAdmission Webhookを改めて調べたので、その忘備録です。

Dynamic Admission Controlとは

下記参照

kubernetes.io

kubernetes.io

f:id:gashirar:20201031113614p:plain

上記の図にあるように、KubernetesのAPI Serverにリクエストが来た際に

  • オブジェクトの変更（Mutating）
  • オブジェクトの検証（Validating）

が行われます。Kubernetesでは、ここにユーザ独自の処理を挟むことが可能です。
IstioのEnvoy SidecarのInjectionもこのあたりの機能を利用して実装されています。

Mutating Admission Webhookの導入

GitHub - morvencao/kube-mutating-webhook-tutorial: A Kubernetes mutating webhook server that implements sidecar injection

上記リポジトリをもとにMutating Webhookの仕組みを見ていきます。

Webhookの登録

API Serverから他のWebhook Serverに処理をさせるために、API ServerにWebhookの登録を行う必要があります。
Webhookの設定のためのMutatingWebhookConfiguration Resourceが提供されているので、これを使ってをクラスタに登録しましょう。

※20201031現在、MutatingWebhookConfigurationはv1になっているので、v1beta1とはパラメータが異なる場合があります。

apiVersion: admissionregistration.k8s.io/v1beta1
kind: MutatingWebhookConfiguration
metadata:
  name: sidecar-injector-webhook-cfg
  labels:
    app: sidecar-injector
webhooks:
- name: sidecar-injector.morven.me
  clientConfig:    # 1
    service:
      name: sidecar-injector-webhook-svc
      namespace: sidecar-injector
      path: "/mutate"
    caBundle: ${CA_BUNDLE}
  rules:    # 2
  - operations: ["CREATE", "UPDATE"]
    apiGroups: [""]
    apiVersions: ["v1"]
    resources: ["pods"]
  namespaceSelector:    # 3
    matchLabels:
      sidecar-injection: enabled

主なポイントは3つです。

  1. Webhook Serverへの通信経路情報
    • sidecar-injector Namespaceに存在するsidecar-injector-webhook-svc Serviceの/mutateにリクエストを送る
  2. Webhook Serverへ送るトリガ
    • PodのCREATEとUPDATEのリクエストの場合にWebhook Serverへとリクエストを送る
  3. Webhookの対象の制御設定
    • sidecar-injection: enabledが設定されたNamespaceのPodのみ処理の対象とする

上記ではKubernetesクラスタ内のServiceに処理を送ることになりますが、外部のサーバでも可能です。
namespaceSelector以外にもobjectSelectorによるコントロールができたり、Webhookへ到達できなかったなどの想定外の障害時に後続の処理をどうするかなどのfailurePolicyなどの設定もできます。
詳しくはAPI Referenceを参考にしてください。

Webhook Serverのサーバ証明書の作成

API ServerからWebhook Serverへの通信はHTTPS通信で行う必要があるので、Webhook Serverのためのサーバ証明書を作成します。上記リポジトリではCertificateSigningRequest Resourceを利用してKubernetesのCAを使ってサーバ証明書（と鍵）を作成しているようですが、独自でつくっても問題ないです。 （余談ですが、こういった「証明書を作るためのAPI」「それを承認するためのAPI」が用意されているところがプラットフォームという感じがします）

作成したサーバ証明書と鍵はSecretにしたうえでコンテナからマウントする方式になっていますね。

Webhook Serverの処理

Webhook ServerはAPI ServerからAdmissionReviewを受け取り、その中のAdmissionResponseにpatchを格納して返却します。
下記処理でAdmissionReviewのAdmissionRequestからPodの情報を取り出して処理をしていることがわかるかと思います。

func (whsvr *WebhookServer) mutate(ar *v1beta1.AdmissionReview) *v1beta1.AdmissionResponse {
    req := ar.Request
    var pod corev1.Pod
    if err := json.Unmarshal(req.Object.Raw, &pod); err != nil {
        glog.Errorf("Could not unmarshal raw object: %v", err)
        return &v1beta1.AdmissionResponse{
            Result: &metav1.Status{
                Message: err.Error(),
            },
        }
    }

    glog.Infof("AdmissionReview for Kind=%v, Namespace=%v Name=%v (%v) UID=%v patchOperation=%v UserInfo=%v",
        req.Kind, req.Namespace, req.Name, pod.Name, req.UID, req.Operation, req.UserInfo)

    // determine whether to perform mutation
    if !mutationRequired(ignoredNamespaces, &pod.ObjectMeta) {
        glog.Infof("Skipping mutation for %s/%s due to policy check", pod.Namespace, pod.Name)
        return &v1beta1.AdmissionResponse{
            Allowed: true,
        }
    }

    // Workaround: https://github.com/kubernetes/kubernetes/issues/57982
    applyDefaultsWorkaround(whsvr.sidecarConfig.Containers, whsvr.sidecarConfig.Volumes)
    annotations := map[string]string{admissionWebhookAnnotationStatusKey: "injected"}
    patchBytes, err := createPatch(&pod, whsvr.sidecarConfig, annotations)
    if err != nil {
        return &v1beta1.AdmissionResponse{
            Result: &metav1.Status{
                Message: err.Error(),
            },
        }
    }

    glog.Infof("AdmissionResponse: patch=%v\n", string(patchBytes))
    return &v1beta1.AdmissionResponse{
        Allowed: true,
        Patch:   patchBytes,
        PatchType: func() *v1beta1.PatchType {
            pt := v1beta1.PatchTypeJSONPatch
            return &pt
        }(),
    }
}

kube-mutating-webhook-tutorial/webhook.go at master · morvencao/kube-mutating-webhook-tutorial · GitHub

f:id:gashirar:20201031140511p:plain

まとめ

  • AdmissionReviewを受け取ってAdmissionResponseを（AdmissionReviewにつめて）返却するサーバを構築し、
  • Webhookの実行ルールをMutatingWebhookConfigurationに記載する

拡張しやすい作りになっていてたすかります。