<p>I created a Docker image based on microsoft/dotnet-framework of a C#.NET console application built for Windows containers, then ensured I can run the image in a container locally. I successfully pushed the image to our Azure Container registry. Now I'm trying to create a deployment in our Azure Kubernetes service, but I'm getting an error: </p>

<blockquote>
  <p>Failed to pull image "container-registry/image:tag": rpc error: code = Unknown desc = unknown blob</p>
</blockquote>

<p>I see this error on my deployment, pods, and replica sets in the Kubernetes dashboard.</p>

<p>We already have a secret that works with the azure-vote app, so I wouldn't think this is related to secrets, but I could be wrong.</p>

<p>So far, I've tried to create this deployment by pasting the following YAML into the Kubernetes dashboard Create dialog:</p>

<pre><code>apiVersion:
kind: Deployment
metadata:
  name: somename
spec:
  selector:
    matchLabels:
      app: somename
      tier: backend
  replicas: 2
  template:
    metadata:
      labels:
        app: somename
        tier: backend
    spec:
      containers:
      - name: somename
        image: container-registry/image:tag
        ports:
        - containerPort: 9376
</code></pre>

<p>And I also tried running variations of this kubectl command:</p>

<pre><code>kubectl run deploymentname --image=container-registry/image:tag
</code></pre>

<p>In my investigation so far, I've tried reading about different parts of k8s to understand what may be going wrong, but it's all fairly new to me. I think it may have to do with this being a Windows Server 2016 based image. A team member successfully added the azure-vote tutorial code to our AKS, so I'm wondering if there is a restriction on a single AKS service running deployments for both Windows and Linux based containers. I see by running <code>az aks list</code> that the AKS has an agentPoolProfile with "osType": "Linux", but I don't know if that means simply that the orchestrator is in Linux or if the containers in the pods have to be Linux based. I have found stackoverflow questions about the "unknown blob" error, and it seems <a href="https://stackoverflow.com/questions/45138558/pull-image-from-and-connect-to-the-acs-engine-kubernetes-cluster/45141031#45141031">the answer to this question</a> might support my hypothesis, but I can't tell if that question is related to my questions.</p>

<p>Since the error has to do with failing to pull an image, I don't think this has to do with configuring a service for this deployment. Adding a service didn't change anything. I've tried rebuilding my app under the suspicion that the image was corrupted, but rebuilding and re-registering had no effect. Another thing that doesn't seem relevant that I read about is <a href="https://stackoverflow.com/questions/48765821/unable-to-pull-public-images-with-kubernetes-using-kubectl">this question and answer</a> regarding a manifest mismatch (which I don't completely understand yet).</p>

<p>I have not tried creating a local Kubernetes. I don't know if that's something folks typically do. </p>

<p>Summary of questions:</p>

<ol>
<li>What causes this unknown blob error? Does it have to do with a Windows container/Linux container mismatch?</li>
<li>Does the agent pool profile affect all the nodes in the cluster, or just the "master" nodes? </li>
</ol>

<p>Let me know if you need more information. Thanks.</p>

<p><strong>1. What causes this unknown blob error? Does it have to do with a Windows container/Linux container mismatch?</strong>
It's because you're trying to run a Windows-based Docker container on a Linux host. It has nothing directly to do with Kubernetes or AKS. Currently AKS is in preview and supports only Linux environments. To be more precise, when you provision your AKS cluster (<code>az aks create</code>), all your k8s minions (worker nodes) will be Linux boxes and thus will not be able to run Windows-based containers.</p>

<p><strong>2. Does the agent pool profile affect all the nodes in the cluster, or just the "master" nodes?</strong>
It affects the worker nodes and is used to group them together logically so you can better manage workload distribution. In the future, when AKS supports both Linux and Windows, you will be able to i.e. create agent pools based on OS type and instruct k8s to deploy your Windows-based services only to the Windows-based hosts (agents).</p>
