digitalocean cloud controller manager
v0.1.56
digitalocean-cloud-controller-manager DigitalOcean向けのKubernetesクラウドコントローラーマネージャーの実装です。クラウドコントローラーマネージャーの詳細については、こちらをご覧ください。 digitalocean-cloud-controller-manager実行すると、KubernetesクラスターでDigitalOceanが提供する多くのクラウドプロバイダー機能を活用できます。
クラウドコントローラーマネージャーは、セマンティックバージョンに従います。バージョンはまだV1を下回っていますが、プロジェクトは生産対応と見なされます。
Kubernetesリリースサイクルが高速であるため、CCM（Cloud Controller Manager）は、Digitalocean Kubernetes製品でもサポートされているバージョンのみをサポートします。その他のリリースは、当社によって公式にサポートされていません。
DigitalOcean Cloud Controller Managerの実行の詳細については、こちらをご覧ください！
このCCMはデフォルトでDoks（DigitalOcean Managed Kubernetes）にインストールされていることに注意してください。自分で行う必要はありません。
digitalocean-cloud-controller-manager活用する方法の例をいくつか紹介します。
CCMを介してロードバランサーを作成している場合（ LoadBalancerタイプのサービスを介して）、 DO Load-Balancer構成を手動で変更しないことが非常に重要です。このような変更は、CCMに組み込まれた調整ループによって最終的に戻ります。 Load-Balancer Nameには変更できる例外が1つあります（Load-Balancer ID Annotationsのドキュメントも参照）。
それ以外に、負荷バランサーの構成変更を行うための唯一の安全な場所は、サービスオブジェクトを使用することです。
技術的な理由から、ポート50053、50054、および50055は、ロードバランサーの入力ポート（つまり、負荷バランサーがリクエストのために耳を傾けるポート）として使用することはできません。影響を受けるポートのいずれかをサービスポートとして使用しようとすると、422のエントリポートがDO APIによって返されます（およびKubernetesイベントとして表面化されます）。
解決策は、サービスポートを別の、非紛争のあるものに変更することです。
v1.17.xこのプロジェクトは、依存関係管理にGOモジュールを使用し、ベンダーを採用しています。依存関係の変更後にmake vendorを実行することを確認してください。
コードを変更した後、テストとCIチェックを実行します。
make cidigitalocean-cloud-controller-manager特定のクラスターに対してローカルに実行したい場合は、Kubeconfigを準備し、メインパッケージホストのディレクトリでバイナリを起動します。
cd cloud-controller-manager/cmd/digitalocean-cloud-controller-manager
REGION=fra1 DO_ACCESS_TOKEN=your_access_token go run main.go
--kubeconfig < path to your kubeconfig file >
--leader-elect=false --v=5 --cloud-provider=digitalocean REGION環境変数は、有効なDigitalOcean地域を取ります。 digitalocean-cloud-controller-manager液滴でのみ利用可能なDigitalOcean Metadataサービスにアクセスしようとしないように設定できます。領域変数が設定されている場合、DO領域サービスを使用して、指定された領域を検証します。また、現地の開発目的で設定することもできます。全体として、選択する地域は、それを選ぶ限り、それほど重要ではないはずです。
また、 DO_ACCESS_TOKEN環境変数でDigitalOceanアクセストークンを提供する必要があるかもしれません。トークンは、クラウドコントローラーが起動するために有効である必要はありませんが、その場合、DigitalOcean APIとの統合を検証することはできません。
DigitalOceanで作成されたKubernetesクラスターを使用する場合、クラスターで既にクラウドコントローラーマネージャーが実行されるため、ローカルのマネージャーがAPIアクセスを競うことに注意してください。
digitalocean-cloud-controller-manager NodePortにアクセスするためのルールを動的に調整するDigitalOceanファイアウォールを管理することができます。タイプNodePortのサービスが作成されると、ファイアウォールコントローラーはファイアウォールを公開に更新します。同様に、サービスが削除されたり、別のタイプに変更されたりすると、アクセスが自動的に撤回されます。
例の例：
cd cloud-controller-manager/cmd/digitalocean-cloud-controller-manager
DO_ACCESS_TOKEN= < your_access_token >
PUBLIC_ACCESS_FIREWALL_NAME=firewall_name
PUBLIC_ACCESS_FIREWALL_TAGS=worker-droplet
digitalocean-cloud-controller-manager
--kubeconfig < path to your kubeconfig file >
--leader-elect=false --v=5 --cloud-provider=digitalocean PUBLIC_ACCESS_FIREWALL_NAME環境変数は、ファイアウォールの名前を定義します。ファイアウォールは、その名前でファイアウォールが見つからない場合に作成されます。
PUBLIC_ACCESS_FIREWALL_TAGS環境変数は、ファイアウォールが適用する液滴に関連付けられたタグを指します。通常、これはワーカーノードドロップレットに接続されたタグです。複数のタグが論理またはファッションで適用されます。
場合によっては、特定のサービスのファイアウォール管理が望ましくない場合があります。 1つの例は、nodeportにVPCのみでアクセスできることになっていることです。そのような場合、サービスアノテーションkubernetes.digitalocean.com/firewall-managedを使用して、特定のサービスをファイアウォール管理から選択的に除外することができます。 "false"に設定されている場合、サービス用のインバウンドルールは作成されず、ノードポートへのパブリックアクセスを効果的に無効にします。 （「ブール」注釈値に含まれなければならない引用に注意してください。）デフォルトの動作は、注釈が省略されている場合、 "true 」に設定されている場合、または無効な値を含む場合に適用されます。
環境変数が欠落しているか、空のままになっている場合、ファイアウォールは管理されません。ファイアウォールが作成されると、ノードポート以外の公開アクセスは許可されません。ユーザーは、アクセスをさらに拡張するために追加のファイアウォールを作成する必要があります。
Prometheusメトリックの公開に興味がある場合は、それらを公開するメトリックエンドポイントに渡すことができます。コマンドはこれに似ています。
cd cloud-controller-manager/cmd/digitalocean-cloud-controller-manager
DO_ACCESS_TOKEN=your_access_token
METRICS_ADDR= < host > : < port >
digitalocean-cloud-controller-manager
--kubeconfig < path to your kubeconfig file >
--leader-elect=false --v=5 --cloud-provider=digitalocean METRICS_ADDR環境変数は、プロメテウスメトリックを提供するために使用したい有効なエンドポイントを取得します。有効であるためには、 <host>:<port>形式である必要があります。
digitalocean-cloud-controller-manager起動した後、次のCurlコマンドを実行してPrometheusメトリック出力を表示します。
curl < host > : < port > /metricsAndimint Serverは、DOマネージドオブジェクト（LBSなど）の不良設定の変更を減らすことを目的としたオプションのコンポーネントです。それについてもっと知りたい場合は、ドキュメントをお読みください。
DO API使用は特定のレート制限の対象となります。非常に重い定期的な使用または病理学的ケース（干渉サードパーティコントローラーによるバグやAPIスラッシングなど）のクォータの不足から保護するために、 DO_API_RATE_LIMIT_QPS環境変数を介してカスタムレート制限を構成できます。 API使用量を1秒あたり3.5クエリに制限するために、 DO_API_RATE_LIMIT_QPS=3.5などのフロート値を受け入れます。
コンテナ化された環境で変更をテストする場合は、 devに設定されたバージョンを使用して新しい画像を作成します。
VERSION=dev make publishこれによりdigitalocean/digitalocean-cloud-controller-manager:devにプッシュされたバージョンdevとDockerイメージを使用してバイナリが作成されます。
go get -u ./...
go mod tidy
go mod vendor Dockerイメージを作成してマニフェストを生成するには、GitHubのアクションページに移動し、[ワークフローの実行]をクリックします。作成するgithub <tag>指定し、 vが付いていることを確認します。ワークフローを実行するには、マスターブランチ保護ルールの設定で設定を設定する前に「プルリクエストが必要」という一時的にオフにする必要があります。リリースが完了したら、それをオンにすることを忘れないでください！
ワークフローは次のことを行います。
<tag>でmake bump-version<tag>.yamlとして作成しますreleases/ディレクトリの下でマニフェストファイルをコミットします<tag>で新しいコミットにタグを付けますdigitalocean/digitalocean-cloud-controller-manager:<tag>を構築しますdigitalocean/digitalocean-cloud-controller-manager:<tag> dockerHubに注：このワークフローは非推奨です。上記のGitHubアクションワークフローをお勧めします。
新しいバージョンを手動でリリースするには、最初にバージョンをバンプします。
make NEW_VERSION=v1.0.0 bump-versionすべてが良く見えることを確認してください。すべての変更を伴う新しいブランチを作成します。
git checkout -b release- < new version > origin/master
git commit -a -v
git push origin release- < new version >マスターに合併した後、コミットにタグを付けてプッシュします。
git checkout master
git pull
git tag < new version >
git push origin < new version >最後に、新しいバージョンを使用してMasterからGitHubリリースを作成し、それを公開します。
make publishこれにより、 digitalocean/digitalocean-cloud-controller-manager:<new version>
DigitalOceanでは、私たちのコミュニティを大切にし、愛しています！問題がある場合、または貢献したい場合は、以下のメンテナーの問題/PRとCCを自由に開いてください。
