在yarn-site.xml属性：

• yarn.scheduler.fair.allow-undeclared-pools

• 如果这是true，新的队列可以在提交申请时被创建，无论是因为它们是由提交者指定为应用程序的队列中，或者因为它们是由用户的默认队列属性放在那里。如果此为假，任何时间的应用程序将被放置在一个未在该分配文件中指定一个队列，它被放置在“默认”的队列来代替。默认为true。如果队列放置策略中给出了配置文件，则忽略此属性。

• 配置文件格式

  配置文件必须是XML格式。该格式包含了五种类型的元素：

• 队列中的元素，它们代表的队列。每一个都可以包含下面的属性：

• minResources：最少的资源队列有权在形式的“X MB，Y vcores”。对于单资源公平性的政策，在vcores值将被忽略。如果一个队列的最低份额不满意，将根据之前同一母公司提供可用资源的任何其他队列。当下资源的公平策略队列被认为是不满意的，如果它的内存使用量低于其最低内存份额。就失去优势资源公平性，一个队列被认为是不满意的，如果它的使用，它的相对于所述簇的容量优势资源低于它的最低份额该资源。如果多个队列不满意在这种情况下，资源进入队列有关的资源使用情况和最小值之间的最小比率。注意，有可能是一个队列，即低于其最小可能不会立即起床到最小，当它提交的申请，因为已经运行的作业可以利用这些资源。

• maxResources：最大的资源队列是允许的，在形式的“X MB，Y vcores”。对于单资源公平性的政策，在vcores值将被忽略。队列永远不会被分配一个容器，将其放在总使用量超过此限制。

• maxRunningApps：从队列限制的应用程序的数量，同时运行

• 重量：与其他队列非按比例分担集群。权值默认为1，而与体重2队列应收取约两倍的资源作为一个与默认权重队列。

• schedulingPolicy：设置任何队列的调度策略。允许的值是“先进先出”/“公平”/“DRF”或 ??扩展任何类org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.SchedulingPolicy。默认为“公平”。如果“先进先出”，应用程序与先前提交时间以偏爱的容器，但后来提交的应用程序可以同时运行，如果有剩余的空间集群在满足前面的应用程序的请求后。

• aclSubmitApps：用户和/或可以提交应用程序的队列组的列表。请参考下面的ACL部分在此列表的格式和队列是如何工作的ACL的详细信息。

• aclAdministerApps：用户和/或组可管理一个队列的列表。目前唯一的行政行为是杀一个应用程序。请参考下面的ACL部分在此列表的格式和队列是如何工作的ACL的详细信息。

• minSharePreemptionTimeout：秒数队列是根据它的最小份额的时候，才试图抢占容器，以使资源从其他队列。

• 用户元件，它代表设置管用户个性化的行为。它们可以包含一个属性：maxRunningApps上运行的应用程序对特定用户数量的限制。

• 一个userMaxAppsDefault元素，它设置默认运行的应用程序的限制是不是另有规定的限制的任何用户。

• 一个fairSharePreemptionTimeout元素，几秒钟的队列号是其公平份额下的时候，才尝试抢占容器，以使资源从其他队列。

• 一个defaultQueueSchedulingPolicy元素，它设置为队列默认的调度策略; 如果所指定的每个队列的schedulingPolicy元素覆盖。默认为“公平”。

• 一个queuePlacementPolicy元素，其中包含告诉调度程序如何进入的应用程序放置到队列规则元素的列表。规则的应用，因为它们列出的顺序。规则可能需要的参数。所有规则接受“创造”的说法，这表示规则是否可以创建一个新的队列。“创建”默认为true; 如果设置为false，该规则将放在未在配置文件中配置一个队列的应用程序，我们继续到下一个规则。最后一条规则必须是一个永远无法发出继续。有效的规则是：

  这里有一个例子配置文件中给出：

• 规定：应用程序被放置到它要求队列中。如果应用程序要求没有队列，也就是说，它指定了“default”，我们继续。

• 用户：应用程序被放置到一个与谁提交它的用户的名称队列。

• primaryGroup：应用程序被放置到一个队列，谁提交它的用户的主组的名称。

• secondaryGroupExistingQueue：应用程序被放置到一个有一个与谁提交了用户的次要组名的队列。符合配置的队列中的第一次要组将被选中。

• 默认：应用程序被放置到一个名为“默认”的队列。

• 拒绝：应用程序被拒绝。

• <?xml version="1.0"?>
  <allocations>
    <queue name="sample_queue">
      <minResources>10000 mb,0vcores</minResources>
      <maxResources>90000 mb,0vcores</maxResources>
      <maxRunningApps>50</maxRunningApps>
      <weight>2.0</weight>
      <schedulingPolicy>fair</schedulingPolicy>
      <queue name="sample_sub_queue">
        <aclSubmitApps>charlie</aclSubmitApps>
        <minResources>5000 mb,0vcores</minResources>
      </queue>
    </queue>
    
    <user name="sample_user">
      <maxRunningApps>30</maxRunningApps>
    </user>
    <userMaxAppsDefault>5</userMaxAppsDefault>
    
    <queuePlacementPolicy>
      <rule name="specified" />
      <rule name="primaryGroup" create="false" />
      <rule name="default" />
    </queuePlacementPolicy>
  </allocations>
  

请注意，为了与原来的FairScheduler兼容性，“ queue”元素可以代替其命名为“pool”的元素。

队列的访问控制列表（ACL）

队列的访问控制列表（ACL）允许管理员控制谁可以采取行动，特别是队列。它们被配置成与aclSubmitApps和aclAdministerApps特性，这可以为每个队列被设置。目前只支持行政行为被杀死的应用程序。谁可以管理一个队列中任何人也可以提交申请了。这些属性需要像“用户1，用户2组1，组2”或“组1，组2”的格式值。如果它的用户或组是在该队列的访问控制列表或任何该队列的祖先ACL在一个队列动作将被允许。所以，如果队列2是内部队列1，而user1的队列1的ACL，和user2是在队列2的ACL，那么这两个用户可以向队列2。

根队列的ACL是“*”，其中，因为ACL是传下来的默认值，也就是说，每个人都可以提出来，并从每个队列杀应用程序。要开始限制访问，修改root队列的ACL来的东西比“*”等。