Base64でエンコードされたイグニッションファイルが壊れます。

Base64でエンコードされたイグニッションファイルが壊れます。

現在、次の手順でESXi(非プロダクション、独自のハードウェア)にOKDクラスタを設定しています。Red Hat Webサイトの公式文書しかし、RHCOSではなくFedora CoreOSを使用しています。

これまでロードバランサを設定し、DNSエントリを作成し、火災設定を作成しました。 CentOS 8 VMでこれを作成し、バックアップ用にWindows 10ワークステーションにコピーしました。私は最初にIgnitionに触れたので、テスト環境でURLを混乱させたくなかったので、https://...URLだけを変更しました。http://...

ところでここで少し変になります。私のmaster.ignファイルの内容は次のとおりです。

"ignition": {
    "config": {
        "merge": [{
            "source": "http://api-int.openshift.<mydomain>.local:22623/config/master"
        }]
    },
    "security": {
        "tls": {
            "certificateAuthorities": [{
                "source": "data:text/plain;charset=utf-8;base64,<BASE64 ENCODED CERT>"
            }]
        }
    },
    "version": "3.0.0"
}

Base64でエンコードされた証明書をコピーしてCentOS VMでデコードすると(有効に見える)証明書が生成されます。しかし、ファイル全体をエンコードすると(必須)チュートリアルを通して)これを使用してマシンを起動すると、証明書が無効でデコードに問題があるというエラーメッセージが表示されます(後で特定のログファイルを抽出できます)。

ファイルを手動でデコードしてから証明書をデコードしようとすると、無効な文字(オブジェクト置換文字と代替文字)が原因で歪みます。

それでは、私の問題が何であるかを知っている人はいますか?私は何を逃したことがありませんか?

それともhttpを使用しているので、セキュリティ部分を省略することができますか? (まだ試したことはありませんが、この記事を書いてアイデアが思い浮かびました。)

答え1

エンコードを再試行した後、問題は自然に解決されました。

しかし、なぜこれが起こるのか疑問です。私のコンピュータにある元のファイルとダウンロードしたバージョンをハッシュ値で比較しましたが、まったく同じではありません。したがって、私がダウンロードしたバージョンが何とか破損しているという説明になる可能性があります。それ以来、問題を再現できませんでした。

また、Fedora CoreOS-VMについて詳しく調べました。有効な設定があるかignitionどうかにかかわらず、起動プロセスはほぼ同じように見えますignition。誤ったignition設定は単に無視され、設定なしで起動プロセスが続行されるようです。

関連情報