{"id":3148,"date":"2022-02-01T13:02:09","date_gmt":"2022-02-01T01:02:09","guid":{"rendered":"https:\/\/www.deltics.co.nz\/blog\/?p=3148"},"modified":"2022-02-02T09:56:48","modified_gmt":"2022-02-01T21:56:48","slug":"kubernetes-home-powershell-vms","status":"publish","type":"post","link":"https:\/\/www.deltics.co.nz\/blog\/posts\/3148\/","title":{"rendered":"Kubernetes @ Home: PowerShell VM’s"},"content":{"rendered":"[Estimated Reading Time: <\/span> 10<\/span> minutes]<\/span><\/span>\n

Following the Vagrant experiment<\/a> (reminding me of a Bill Bailey metaphor… “a long walk down a windy beach to a cafe that was closed<\/a><\/em>“) I next set about automating my VM creation using PowerShell<\/strong>, with greater success. Though still not perfect, the final gap to full automation is something I could<\/em> close, if I wished. And we get to install kubernetes<\/strong> itself!<\/p>\n\n\n\n\n\n\n\n

The PowerShell Solution<\/h2>\n\n\n\n

Reasoning that anything the Hyper-V<\/strong> provider for Vagrant<\/strong><\/a> was able to do must be possible via some other means, my first thought was to explore the Hyper-V<\/strong> module for PowerShell<\/strong><\/a>. Sure enough, it had everything I needed.<\/p>\n\n\n\n

Far more quickly than I achieved with Vagrant<\/strong>, I soon had a simple script to create all my VM’s:<\/p>\n\n\n\n

\"\"<\/a>
create-vms.ps1<\/figcaption><\/figure>\n\n\n\n

NOTE:<\/strong> Unfortunately I have had to resort to posting the scripts as screen-shots due to an issue with WordPress. Something about these scripts made the post editor unable to save my post.

I tried with a variety of plugins as well as using a plain preformatted, unhighlighted block, without success. Trying to resolve this issue is what has delayed this post!

I can only hope whatever issue is behind this isn’t causing problems with code posted in historic posts! If you encounter any, please let me know.<\/p>\n\n\n\n

This straight-forward script declares a function (lines 1-39) that does all the heavy lifting which is then called 4 times, once for each VM that I want.<\/p>\n\n\n\n

With default values defined for most parameters to the function, each call only has to name the VM being created and provide the desired MAC address (again, the values in the script here are illustrative only).<\/p>\n\n\n\n

The function prepares each VM. The initial new-vm<\/mark> command (line 18) creates the VM with a (virtual) HDD. Immediately a benefit over Vagrant<\/strong> is apparent in that the required network switch is also specified in this command.<\/p>\n\n\n\n

Further tweaks to the VM are then applied, including setting the RAM and CPU resources, disabling secure boot and applying the required properties to the network adapter of the VM (VLAN ID and MAC address).<\/p>\n\n\n\n

Then follows the most complicated part of the script (lines 24-35). This section:<\/p>\n\n\n\n

  1. Adds a virtual DVD drive with the Ubuntu Server installation iso mounted<\/li>
  2. Removes the network from the boot device list<\/li>
  3. Sets the virtual DVD as the first boot device<\/li><\/ol>\n\n\n\n

    None of this is strictly necessary but is a convenience for what follows. <\/p>\n\n\n\n

    Finally, auto-checkpoints are disabled since I intend to create specific checkpoints myself at various points in the process that follows and don’t want these conflated and confused with automatic ones.<\/p>\n\n\n\n

    OS Installation<\/h2>\n\n\n\n

    Actual installation of the Ubuntu Server OS in each VM remains a manual step in this approach.<\/p>\n\n\n\n

    This is the automation gap I mentioned, that I could close in the future if I wished<\/a> by creating fully unattended installs for my Ubuntu machines.<\/p>\n\n\n\n

    For now, I install the OS “manually” in each VM. The PowerShell<\/strong> script to ensure that each new VM is configured to initially boot straight into the installation process provides enough convenience for the time being.<\/p>\n\n\n\n

    Although it (currently) has to be repeated for each VM, installation is far more straightforward with these VM’s. Installation for use as a Kubernetes node is almost “vanilla”, with defaults accepted for almost all installation options other than network hostname, my preferred user account name and formatting the full capacity of the virtual HDD since, for some reason, the installation intends to format only half the capacity by default. This may be related to the virtual and dynamic nature of the “disk”, though I’m not sure.<\/p>\n\n\n\n

    A good sign that the diminutive Asus PC is more than capable of supporting these 4 VM’s was that I was able to launch all 4 newly created VM’s and go through the installation of each in parallel, without any sign of the platform straining under the load or even triggering the cooling fans on the host – an increasingly common measure of system load. \ud83d\ude42<\/p>\n\n\n\n

    One slight concession to the scripted steps that were to follow, was to copy my ssh<\/strong> key to each VM and to make my user account capable of password-less sudo<\/strong>, making it possible to run subsequent bash scripts entirely remotely using ssh<\/strong>.<\/p>\n\n\n\n

    Onward, To Kubernetes!<\/h2>\n\n\n\n

    Apologies. bash scripts in this section are by necessity all reproduced as screen-shots to avoid the WordPress issue mentioned above.<\/p>\n\n\n\n

    With the VM’s ready to go, I then had just 3 scripts left to run to create my cluster. They had to be run in a particular order, which was:<\/p>\n\n\n\n

    1. main.sh<\/li>
    2. master.sh<\/li>
    3. workers.sh<\/li><\/ol>\n\n\n\n

      Each of these is a script that runs another<\/em> script in one, some or all of each of my 4 VMs. As an example, let’s look at main.sh<\/mark> which runs a node-install.sh<\/mark> script on all 4<\/strong> of the VM’s:<\/p>\n\n\n\n

      \"\"<\/a>
      main.sh<\/figcaption><\/figure>\n\n\n\n

      For anyone with scripting over ssh<\/strong>, this should be familiar (if somewhat naive in places, as I am still an egg when it comes to this stuff).<\/p>\n\n\n\n

      The node-install.sh<\/mark> script itself is the largest of all of the scripts, but although it does a fair amount of work it is all very straight-forward:<\/p>\n\n\n\n

      \"\"<\/a>
      node-install.sh<\/figcaption><\/figure>\n\n\n\n

      Tasks 1 thru 5 in this script (lines 1-42) are all about preparing the system for Kubernetes.<\/p>\n\n\n\n

      After some initial housekeeping to elevate the script to sudo<\/strong> and ensure all apt packages are up to date, the system swap file and firewall are turned off.<\/p>\n\n\n\n

      Tasks 3 thru 5 then configure Kubernetes to use the containerd<\/strong> runtime.<\/p>\n\n\n\n

      Kubernetes itself is then installed by first (Task 6, lines 44-46) adding the kubernetes repo and the key for it, before finally (Task 7, lines 48-49) installing kubeadm<\/strong>, kubelet<\/strong> and kubectl<\/strong>.<\/p>\n\n\n\n

      To recap on those three packages:<\/p>\n\n\n\n

      kubeadm<\/strong><\/td>Command-line utility for performing Kubernetes administrative operations such as initialising a cluster or joining a node to an existing cluster.<\/td><\/tr>
      kubelet<\/strong><\/td>The process that runs on a Kubernetes node to communicate with other nodes in the cluster (this process is fundamentally what turns a machine into a node).<\/td><\/tr>
      kubectl<\/strong><\/td>Command-line utility that provides the primary means of interacting with a Kubernetes cluster. It is used to add, remove and query the status of objects within the cluster, among other things.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

      Now is a good time for a brief diversion, to talk about containerd<\/strong>.<\/p>\n\n\n\n

      Docker vs containerd<\/h2>\n\n\n\n

      Some time ago, the Kubernetes<\/strong> developers announced their intention to remove support for Docker<\/a>. This did not mean that Kubernetes<\/strong> would be unable to “run Docker containers<\/em>” only that it would no longer support “using<\/strong> Docker to run containers<\/em>“, i.e. using Docker as the container runtime.<\/p>\n\n\n\n

      A subtle but important difference.<\/p>\n\n\n\n

      The alternative is to use a container runtime called containerd<\/strong>.<\/p>\n\n\n\n

      Containers themselves are a standardised commodity. Indeed, they were already a “thing” before Docker<\/strong> made them popular.<\/p>\n\n\n\n

      A “Docker container<\/em>” is just “a container<\/em>” that can be run on any standards-compliant container platform. Whilst Docker<\/strong> does indeed use a standards-compliant platform to run its containers, that platform lives inside a Docker-ish<\/em> environment. For Kubernetes<\/strong> to work with the underlying platform, it has to use a compatibility layer to get through the Docker-ish<\/em> layers in-between.<\/p>\n\n\n\n

      And the standards-compliant runtime that Docker<\/strong> employs is, in fact, … containerd<\/strong>.<\/p>\n\n\n\n

      You may already be thinking that this all sounds a bit… messy. The Kubernetes<\/strong> team agrees with you.<\/p>\n\n\n\n

      The prior support for this was only ever intended as a temporary compatibility concession. It introduces additional “layers” between Kubernetes<\/strong> and the container runtime itself and ideally Kubernetes<\/strong> would work directly with the underlying container platform (containerd<\/strong>). Arguably that’s the whole point of deprecating Docker<\/strong> support in Kubernetes<\/strong>… to wean people off of the Docker<\/strong> compatibility layer and switch over to running directly on containerd<\/strong>.<\/p>\n\n\n\n

      It is more efficient and involves one less thing (the Docker<\/strong> compatibility layer) to have to maintain and which could go wrong.<\/p>\n\n\n\n

      When I first manually installed Kubernetes<\/strong> I went down the docker<\/strong> route since this is what the instructions I was following did. Although that didn’t require any configuration (beyond installing the docker.io<\/strong> package itself), it also didn’t initially work and although the configuration tweak required to get it working was fairly small, it had a bad “smell” about it, like I was changing something that wasn’t intended to be changed (well, it was deprecated after all).<\/p>\n\n\n\n

      Ultimately I decided that since Docker<\/strong> support was going away I should get used to not using it sooner rather than later and found a more current guide that provided the containerd<\/strong> configuration steps that I have now incorporated in my scripts.<\/p>\n\n\n\n

      What About Kubernetes in Docker?<\/h2>\n\n\n\n

      If you use Docker Desktop<\/strong>, you may be familiar with the fact that you can in fact create yourself a Kubernetes cluster with a single click by simply Enabling Kubernetes<\/em><\/mark><\/strong> in Docker Desktop<\/strong> itself.<\/p>\n\n\n\n

      \"\"<\/a><\/figure>\n\n\n\n

      This is unrelated to the “Kubernetes support for Docker” issue and is purely a convenient means of standing up a single-node<\/em> Kubernetes<\/strong> cluster on a machine that already has Docker Desktop<\/strong> installed.<\/p>\n\n\n\n

      Why didn’t I just use that<\/em> to learn about Kubernetes?<\/strong><\/p>\n\n\n\n

      As a way of learning to work with Kubernetes it is indeed a great place to start, but being a single-node cluster it doesn’t provide scope for more learning about aspects of Kubernetes that arise in more complex – i.e. realistic – scenarios. Besides, I suspected that toggling a check-box was perhaps not representative of what was involved in establishing a “proper” cluster. \ud83d\ude42<\/p>\n\n\n\n

      Back to Installing Kubernetes<\/h2>\n\n\n\n

      So, back to the business of installing Kubernetes<\/strong>.<\/p>\n\n\n\n

      With node-install.sh<\/mark> having been run on each on my machine, I now had 4 VM’s capable<\/em> of being Kubernetes<\/strong> nodes but which were not yet actual nodes.<\/p>\n\n\n\n

      Three steps remain:<\/p>\n\n\n\n

      1. Initialise (create) a cluster<\/li>
      2. Configure the master<\/strong> node and install a container network<\/li>
      3. Join the worker<\/strong> nodes to the cluster <\/li><\/ol>\n\n\n\n

        This of course was the purpose of the remaining scripts, although the first step is manual.<\/p>\n\n\n\n

        Creating the Cluster<\/h2>\n\n\n\n

        To initialise the cluster itself, all that is required is to ssh<\/strong> to the node that is to be the master<\/strong> node and run the following command:<\/p>\n\n\n\n

        sudo kubeadm init<\/pre>\n\n\n\n
        If all goes well, this creates the cluster with a swathe of diagnostic output, before finally providing some information that is critical for the steps that follow.  This is one reason it remains a manual step (that and the fact that it is trivially simple and not worth scripting).<\/p>\n\n\n\n
        The output you get after successfully initialising a cluster should be similar to this: <\/p>\n\n\n\n
        \"\"<\/a>
        Successful output from kubeadm init<\/figcaption><\/figure>\n\n\n\n
        The three critical pieces of information are highlighted red<\/mark>, blue<\/mark> and green<\/mark>.<\/p>\n\n\n\n
        The red<\/mark> instruction is easily automated as indeed is the blue<\/mark> instruction, to install a pod network.  This is what establishes the internal network within the cluster over which the pods in that cluster communicate with each other.  There are numerous options available in this space, all described at the Url provided in the output<\/a>.<\/p>\n\n\n\n
        I did a little research and chose Weave<\/a>, attracted by the observation that it provided a plug-and-play option with simple installation and no configuration required.<\/p>\n\n\n\n
        The two steps to configure the master<\/strong> and install the Weave<\/strong> network add-on were incorporated into a master-config.sh<\/mark> script:<\/p>\n\n\n\n
        \"\"<\/a>
        master-config.sh<\/figcaption><\/figure>\n\n\n\n
        This is the first demonstration of installing something into Kubernetes<\/strong>.  The command:<\/p>\n\n\n\n
        kubectl apply -f <filename><\/pre>\n\n\n\n
        asks Kubernetes<\/strong> to apply the file identified.  Within the specified file is a description of services and other objects that Kubernetes should ensure are available.  If those services need container images, then Kubernetes will pull those images as required.<\/p>\n\n\n\n
        In this case, the file describes the Weave<\/strong> addon and is referenced by URL, with a bit of bash<\/strong> magic to ensure that the version of the file is used that is appropriate to the version of Kubernetes<\/strong> installed.<\/p>\n\n\n\n
        I then created a master.sh<\/mark> script which runs that config script on the master<\/strong> node over ssh<\/strong> and then downloads the configuration required to enable kubectl<\/strong> running on my workstation to communicate with the cluster:<\/p>\n\n\n\n
        \"\"<\/a>
        master.sh<\/figcaption><\/figure>\n\n\n\n
        The configuration file downloaded is simply placed in the current folder.  On a “fresh” workstation it can then be simply moved and renamed as ~\/.kube\/config<\/mark>.  This isn’t done automatically since if a machine already has Kubernetes<\/strong> configuration for working with other clusters, then the contents need to be incorporated into that existing<\/em> configuration.<\/p>\n\n\n\n
        The final green<\/mark> instruction provided the command to run on each of the worker<\/strong> nodes that wish to join the cluster.<\/p>\n\n\n\n
        I created a script to do this (node-join.sh<\/mark>) which contained the command as provided in the output from kubeadm<\/strong> above, then created a further (workers.sh<\/mark>) script to run that<\/em> script on each of my worker<\/strong> nodes:<\/p>\n\n\n\n
        \"\"<\/a>
        workers.sh<\/figcaption><\/figure>\n\n\n\n
        Testing the Cluster<\/h2>\n\n\n\n
        All being well, I now had a Kubernetes<\/strong> cluster up and running!<\/p>\n\n\n\n
        To test that, all that remained was to install Kubernetes<\/strong> command-line tools on my workstation and configure them.<\/p>\n\n\n\n
        Since I already had Docker Desktop<\/strong> installed, the Kubernetes<\/strong> CLI tools (specifically, kubectl<\/strong>) was already available as part of that.  Indeed, after installing the Kubernetes<\/strong> CLI with homebrew<\/strong>, my system was still using the Docker Desktop<\/strong> tools, which was undesirable since they were older.  Homebrew<\/strong> Doctor<\/strong> helps identify such problems and suggest fixes, which in this case meant removing a symlink<\/em> that was pointing kubectl<\/strong> at the Docker Desktop<\/strong> version.<\/p>\n\n\n\n
        Since I had no other Kubernetes<\/strong> cluster configuration to worry about, I then simply moved and renamed the kube-config<\/mark> file downloaded from my master<\/strong> node to ~\/.kube\/config<\/mark> and I was all set!<\/p>\n\n\n\n
        As a simple test, I could ask Kubernetes to list all of the nodes in my default cluster by issuing the command:<\/p>\n\n\n\n
        kubectl get nodes<\/pre>\n\n\n\n
        If everything has gone smoothly, the result should resemble:<\/p>\n\n\n\n
        \"\"<\/a>
        Nodes in the cluster<\/figcaption><\/figure>\n\n\n\n
        Success!<\/p>\n\n\n\n
        The “12d” age of my nodes reflects the fact that this screenshot was taken 12 days after having done all this.<\/p>\n\n\n\n
        But what are the nodes doing<\/em>?<\/p>\n\n\n\n
        We can find out by asking Kubernetes<\/strong> to list all of the services<\/em> that are running in the cluster, with this command:<\/p>\n\n\n\n
        kubectl get services -A<\/pre>\n\n\n\n
        The -A<\/mark> option directs Kubernetes to list all services in all namespaces<\/em>, and we should get something resembling:<\/p>\n\n\n\n
        \"\"<\/a>
        Services in the cluster<\/figcaption><\/figure>\n\n\n\n
        Well, actually, you won’t.<\/p>\n\n\n\n
        In a fresh cluster, you will have a default<\/strong> namespace and a kube-system<\/strong> namespace, and that’s it.<\/p>\n\n\n\n
        The Kubernetes Dashboard<\/strong> service is not something that is installed by default.  And the fact that this service is of type LoadBalancer<\/strong> is also not something that a cluster is capable of providing out of the box.<\/p>\n\n\n\n
        Next: Dashboard, LoadBalancers and Namespaces<\/h2>\n\n\n\n
        Next time we’ll look at how we establish these things, why and what they do for us, as well as looking at the concept of namespaces.<\/p>\n","protected":false},"excerpt":{"rendered":"
        [Estimated Reading Time: <\/span> 10<\/span> minutes]<\/span><\/span> Following the Vagrant experiment (reminding me of a Bill Bailey metaphor… “a long walk down a windy beach to a cafe that was closed“) I next set about automating my VM creation using PowerShell, with greater success. Though still not perfect, the final gap to full automation is something I could close, if I wished. […]<\/p>\n","protected":false},"author":2,"featured_media":3111,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"jetpack_publicize_message":"After a delay caused by a Wordpress problem with incorporating script source in my post, the third instalment in my journey to establish a Kubernetes cluster at home.\n\nUsing PowerShell to create my VM's and some home-grown bash to provision the cluster!","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":[]},"categories":[324,4,321],"tags":[357,358,352,338],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/kubernetes-banner.png?fit=1171%2C416&ssl=1","jetpack_shortlink":"https:\/\/wp.me\/p1TKYv-OM","jetpack_sharing_enabled":true,"jetpack-related-posts":[{"id":3099,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/3099\/","url_meta":{"origin":3148,"position":0},"title":"Kubernetes @ Home: Vagrant Nodes","date":"27 Jan 2022","format":false,"excerpt":"The first significant practical step in establishing my Bare Metal Kubernetes cluster was to provision 4 VM's. At this point it is worth mentioning that actually installing Kubernetes is almost trivial once you have the necessary hardware in place. Since my 'hardware' was going to be virtual, this meant that\u2026","rel":"","context":"In "automation"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/kubernetes-banner.png?fit=1171%2C416&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":3076,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/3076\/","url_meta":{"origin":3148,"position":1},"title":"A Kubernetes Cluster @ Home","date":"26 Jan 2022","format":false,"excerpt":"I set myself a new challenge for the New Year: Stand Up a Kubernetes cluster of my own. At home. I have reasons (long term costs being [potentially] lower than cloud-hosted alternatives being just one of them) but honestly since Kubernetes is a dominant presence in my day-to-day work these\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/kubernetes-banner.png?fit=1171%2C416&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":3233,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/3233\/","url_meta":{"origin":3148,"position":2},"title":"Kubernetes @ Home: Dashboard","date":"07 Feb 2022","format":false,"excerpt":"At the end of the previous post in this series, we reached the point where I had my Kubernetes cluster up and running, including a Dashboard service. As I mentioned, this Dashboard is not part of a default installation. Taking a look at how I got this up and running\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/kubernetes-banner.png?fit=1171%2C416&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":3291,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/3291\/","url_meta":{"origin":3148,"position":3},"title":"Kubernetes @ Home: Load Balancer","date":"11 Feb 2022","format":false,"excerpt":"In the previous post we installed the Kubernetes Dashboard and saw how we could access the dashboard service which itself runs in the Kubernetes cluster. We also saw how clunky that was and I promised a better way, which we turn to now. Kubernetes Services and IP Addresses To this\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/kubernetes-banner.png?fit=1171%2C416&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":2861,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2861\/","url_meta":{"origin":3148,"position":4},"title":"Azure DevOps – Building Some Code","date":"09 Sep 2019","format":false,"excerpt":"In this post we create a (very!) simple project, build it using Delphi (7) and run it. All with Azure DevOps.","rel":"","context":"In "automation"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/pipelines-hero-code-1024x256.jpg?fit=1024%2C256&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":2919,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2919\/","url_meta":{"origin":3148,"position":5},"title":"Azure DevOps – Now You Too Can Use My Template(s)","date":"14 Sep 2019","format":false,"excerpt":"Learn how you too can use my Delphi build template in your own Azure DevOps pipelines, and a sneak preview of something special coming soon...","rel":"","context":"In "automation"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/github-512.png?fit=512%2C512&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]}],"_links":{"self":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/3148"}],"collection":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/comments?post=3148"}],"version-history":[{"count":72,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/3148\/revisions"}],"predecessor-version":[{"id":3251,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/3148\/revisions\/3251"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/media\/3111"}],"wp:attachment":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/media?parent=3148"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/categories?post=3148"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/tags?post=3148"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}