Okd: OKD support for Azure provider

Created on 29 Nov 2019  路  10Comments  路  Source: openshift/okd

We would like to keep this master issue to link new issues which are related to Azure deployment so we can keep track as well as letting community know if a specific provider deployment is supported or has known issues etc

lifecyclfrozen platforazure

Most helpful comment

Azure images are now being built by the FCOS pipeline. They're not uploaded to Azure automatically, yet, though and users would still have to do that manually at the moment.

refs https://github.com/coreos/fedora-coreos-tracker/issues/148#issuecomment-564622757

All 10 comments

Azure images are now being built by the FCOS pipeline. They're not uploaded to Azure automatically, yet, though and users would still have to do that manually at the moment.

refs https://github.com/coreos/fedora-coreos-tracker/issues/148#issuecomment-564622757

It's here: https://builds.coreos.fedoraproject.org/prod/streams/testing-devel/builds/31.20191213.dev.0/x86_64/fedora-coreos-31.20191213.dev.0-azure.x86_64.vhd.xz

Currently I'm uploading the decompressed VHD file to my Storage Account in Azure

  • Upload to storage account with "Microsoft Azure Storage Explorer"
    -> Doesn't work. The VHD file has dynamic size. Azure VMs require fixed VHD size.
  • TODO: Resize VHD to 50 GByte so OKD4 has enough space for images, ...
  • Upload VHD file with azure-vhd-utils (https://github.com/microsoft/azure-vhd-utils)
    ```
    mkdir -p ~/go/src/github.com/microsoft
    cd ~/go/src/github.com/microsoft
    git clone https://github.com/microsoft/azure-vhd-utils.git
    cd azure-vhd-utils
    go get github.com/Microsoft/azure-vhd-utils
    go build -o azure-vhd-utils

./azure-vhd-utils upload --localvhdpath fedora-coreos-31.20191213.dev.0-azure.x86_64.vhd --stgaccountname --stgaccountkey --blobname fcos-azure --parallelism 32
```

  • Create Linux Disk Image from the VHD uploaded to my storage account
  • Create a simple install-config.yaml with platform: none, put your public ssh key into it so you can ssh into the VMs
  • Create ignition files with openshift-installer
  • Upload bootstrap.ign to storage account, make it public (don't know how to provide credentials for it to ignition files)
  • Create append_bootstrap.ign file and point its source to the blob container with bootstrap.ign
  • Create VM from this disk image:
    az vm create --name node-1 --resource-group group-1 --admin-username core --custom-data "$(cat append_bootstrap.ign)" --image fcos-azure
  • Open Serial console to watch the VM booting -> It appends the bootstrap.ign and tries to setup the cluster

It seems that it works. I'll setup DNS and load balancers and try to get the installation running.

Because Azure support is stripped out in the openshift-installer for the moment (hopefully only affecting the automated creation of infrastructure components through Terraform) I hope that I can configure the Azure cloud provider in OKD nevertheless after the installation :-)

It seems as if the bootstrap VM requires a reboot before it gets the DNS servers provided in the Azure VNET and is able to pull the initial okd image from quay.io.

If Azure support comes back to the openshift-installer (maybe in preview 2 ?) I'm eager to test Azure disk and Azure file support.

Official FCOS on Azure is still not progressing. We have a workaround for that, so we won't be blocking GA on this

Any news regarding this? Many problems trying to install this on Azure, at least with the last Nightly build I was able to install everything BUT only the Bootstrap node is online, master nodes are always offline.

Always getting ERROR Attempted to gather ClusterOperator status after installation failure: listing ClusterOperator objects timeout

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

/remove-lifecycle stale

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

/lifecycle frozen

Was this page helpful?
0 / 5 - 0 ratings